SIP J. Rosenberg
Internet-Draft Cisco Systems
Expires: December 21, 2006 June 19, 2006
Coexistence of P-Asserted-ID and SIP Identity
draft-rosenberg-sip-identity-coexistence-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 21, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Two mechanisms have been defined to support forms of authenticated
caller identity in the Session Initiation Protocol (SIP). The first,
specified in RFC 3325, is the P-Asserted-ID header field. The
second, termed "SIP Identity", defines the Identity and Identity-Info
header fields and provides cryptographically verifiable identities.
This document discusses how to use these mechanisms together.
Rosenberg Expires December 21, 2006 [Page 1]
Internet-Draft Identity Coexistence June 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4
3. User Agent Behavior . . . . . . . . . . . . . . . . . . . . . 6
3.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Generating a Request . . . . . . . . . . . . . . . . . . . 6
3.3. Receiving a Request . . . . . . . . . . . . . . . . . . . 6
4. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Edge Proxy . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Egress Proxy . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Ingress Proxy . . . . . . . . . . . . . . . . . . . . . . 7
5. Interactions with B2BUAs . . . . . . . . . . . . . . . . . . . 8
6. Interactions with Privacy . . . . . . . . . . . . . . . . . . 8
7. P-header or not? . . . . . . . . . . . . . . . . . . . . . . . 9
8. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10.1. Option Tag . . . . . . . . . . . . . . . . . . . . . . . . 11
10.2. URI Parameter . . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Rosenberg Expires December 21, 2006 [Page 2]
Internet-Draft Identity Coexistence June 2006
1. Introduction
One of the most important security features in the Session Initiation
Protocol (SIP) [1] is the ability to convey the identity of the
initiating party of a request. This feature, sometimes known as
"secure caller ID", has been the discussion of much discussion, and
is supported by numerous specifications.
The first work in secure caller ID is within RFC 3261 itself. SIP
provides support for S/MIME. This allows for the initiator of a SIP
request to sign the request with their private key, which can then be
verified by the recipient using their public key. This mechanism,
while very secure, has seen little implementation and no deployment.
It requires an easy to use certificate enrollment system by which end
users can obtain, store, and manage certificates. To date, systems
for providing certificates for end users have proven difficult if not
impossible to deploy.
Consequently, implementations relied on the From header field in the
SIP request, unsigned, to obtain the identity of the sender. This is
easily spoofable and a clear risk. To combat it, the P-Asserted-ID
header field was developed [6]. With this mechanism, the originating
domain of the requestor authenticates them, typically using
traditional SIP digest mechanisms. Once authenticated, the SIP proxy
inserts a header field - the P-Asserted-ID header field - containing
the authenticated identity of the request originator. This header
field is not signed in any way. Instead, the header field is only
conveyed between domains that have a specific trust relationship.
Domains receiving requests with this header field from domains they
don't trust remove the header field. Furthermore, the link between
proxies in different domains is secured with SIP over TLS, allowing
domains to mutually authenticate each other.
Due to its requirement for bilateral trust agreements between
domains, RFC 3325 is only applicable to closed-knit communities of a
small number of relatively large providers. For this reason, the
P-Asserted-ID header field was granted "P-header" status [7], and was
subsequently adopted by the 3gpp for use in the Internet Multimedia
Subsystem (IMS).
However, it was recognized by IETF that this mechanism was a short-
term solution, and a longer term one was required. It consequently
developed the "SIP identity" mechanism [4]. The SIP identity
mechanism defines the Identity and Identity-Info header field. As in
RFC 3325, an originating proxy in the domain of the requestor
authenticates the user, typically using SIP digest. Once
authenticated, the originating proxy checks if the From header field
value matches the authenticated identity. If it does, it signs
Rosenberg Expires December 21, 2006 [Page 3]
Internet-Draft Identity Coexistence June 2006
certain header fields, including the From header field, and places
the result into the Identity header field. The proxy then populates
the Identity-Info header field with a URI that can be used to obtain
the certificate for the domain.
The SIP identity mechanism provides a far superior technical solution
to secure caller ID than RFC 3325. Its cryptographically verifiable
identies are the cornerstone of anti-spam mechanisms [8], which will
not work properly with RFC 3325.
Unfortunately, deployment of SIP identity appears problematic due to
several practical considerations. Firstly, RFC 3325 has enjoyed
widespread deployment. It is build into numerous proxy and
application server products, and is also widely used in end user
devices. Many IP phones or adaptors will look for the P-Asserted-ID
header field as the source for secure caller ID. To bring the SIP
identity mechanism into the mix, the caller, proxy, and
unfortunately, called party must all be upgraded to support it.
Neither the originating proxy or the calling party have any way to
know whether the called party supports RFC 3325 or SIP identity,
making it difficult to know which to use. To maximize
interoperability, it is more cost effective to use the mechanism that
is most likely to work - RFC 3325. This produces a chicken-and-egg
problem that will substantially hamper the deployment of SIP
identity.
Secondly, the SIP identity mechanism provides a signature over the
request which covers key parts of it, including the body. This means
that any elements on the request path between the originating proxy
and the terminating user agent which modify the body in any way will
invalidate the signature. Though proxies are not supposed to modify
the body, the industry has seen widespread usage of back-to-back user
agents with media (B2BUA). These components, to facilitate NAT
traversal, call admission control, and other functions, modify the
body of SIP requests. SIP identity will not function with such
elements on the request path. This adds further to the difficulties
in deploying SIP identity.
To combat this problem, this document defines a mechanism for co-
existence of SIP identity and P-Asserted-ID which greatly reduces the
barriers to deployment for SIP identity.
2. Overview of Operation
The essential idea is to use the SIP identity mechanism between
proxies, rather than P-Asserted-ID, but to retain the use of
P-Asserted-ID as the mechanism for transfer of asserted identity
Rosenberg Expires December 21, 2006 [Page 4]
Internet-Draft Identity Coexistence June 2006
within a domain. The overall architecture is shown in Figure 1.
Originating Domain Terminating Domain
............................... .................................
. . . .
. +------+ +------+ . . +------+ +------+ .
. | |--|Egress|---------|Ingres|--| | .
. /| | |Proxy | . . |Proxy | | |\ .
. / +------+ +------+ . . +------+ +------+ \ .
. / . . \ .
. +------+ . . +------+ .
. | Edge | . . | | .
. |Proxy | . . | | .
. +------+ . . +------+ .
. / . . \ .
...../......................... ........................\........
/ \
+------+ +------+
| | | |
| UAC | | UAS |
+------+ +------+
Figure 1
When a UA initiates a request, it is authenticated by the originating
edge proxy. Once the originator has been authenticated, the edge
proxy inserts the P-Asserted-ID header field, per RFC 3325. This
header field remains in the request as long as it stays within the
domain of the originator. Once the request reaches the last proxy in
the originating domain (the egress proxy), the egress proxy checks
the P-Asserted-ID header field against the From header field. If
they match, the egress proxy removes the P-Asserted-ID header field,
and adds an Identity and Identity-Info header field per [4]. This is
sent to the proxy at the edge of the terminating domain (the ingress
proxy). The ingress proxy will verify the signature, and if it
validates, insert the P-Asserted-ID header field containing the
identity in the From header field. However, the Identity and
Identity-Info header fields remain in the request.
When the request arrives at the terminating UA, it first checks for
the Identity and Identity-Info header fields. If present, the
identity in the From header field is used as the caller ID. If not
present, but P-Asserted-ID is present, the UA uses the P-Asserted-ID
header field as the caller ID.
In order for a UA to determine if its domain supports the mechanisms
in this specification, a UA will include a Supported header field in
Rosenberg Expires December 21, 2006 [Page 5]
Internet-Draft Identity Coexistence June 2006
its REGISTER request with the option tag "id-coexist". If the domain
also supports the mechanism, it will include the same option tag in
the REGISTER response.
3. User Agent Behavior
3.1. Registration
When a UA compliant to this specification generates a REGISTER
request, it SHOULD include a Supported header field in the request
with the option tag "id-coexist". When it receives a successful
response to its registration, it checks for the Supported header
field and the presence of this option tag. If present, the UA knows
that its domain supports the mechanisms of this specification. This
information is used in subsequent processing.
OPEN ISSUE: this is a little hoakey. We're using the option tag
returned from a registrar to infer the behavior of a different
element - the ingress proxy. Is that OK?
3.2. Generating a Request
When originating a request besides a REGISTER, there is no special
processing required.
3.3. Receiving a Request
When receiving an incoming request, the UA first checks for the
presence of the Identity and Identity-Info header fields. If
present, the UA verifies the signature per [4]. If it verifies, the
identity in the From header field is used as the identity of the
sender. If it does not verify, but its domain supports the
coexistence mechanism (based on presence of the id-coexist option tag
in the REGISTER response) and the request contained a P-Asserted-ID
header field, the UA interprets this as the presence of a B2BUA with
media in the terminating domain. It uses the identity in the
P-Asserted-ID header field as the identity of the sender.
If the request did not contain either the Identity or Identity-Info
header fields, but did contain the P-Asserted-ID header field, that
identity is used as the identity of the sender if the clients domain
supports the coexistence mechanism. If the domain of the client
doesn't support the co-existence mechanism, but the P-Asserted-ID
header field is present, the identity of the sender of the request
SHOULD be considered suspect. This specification makes no normative
recommendations on how to treat the request. However,
implementations should consider that, in this case, the identity
Rosenberg Expires December 21, 2006 [Page 6]
Internet-Draft Identity Coexistence June 2006
cannot be trusted unless all of the conditions in the limited scope
of applicability of RFC 3325 apply.
If the request did not contain the Identity or Identity-Info header
fields, and did not contain a P-Asserted-ID header field, the
identity of the sender of the request SHOULD be considered suspect.
The From header field, without a verified Identity header field, is
extremely susceptible to spoofing.
4. Proxy Behavior
4.1. Edge Proxy
An edge proxy is one that authenticates the originating party and
asserts their identity. An edge proxy SHOULD follow the procedures
of RFC 3325, with one addition. If there is no P-Preferred-ID header
field in the request, it SHOULD use the From header field as the
preferred ID.
4.2. Egress Proxy
An egress proxy is one that meets the following conditions:
o The next hop proxy is in a different administrative domain.
o The domain of the proxy matches the domain in the From header
field of the request.
If a request contains a P-Asserted-ID header field, and is received
from a proxy inside of its domain, an egress proxy SHOULD act as an
authentication service per [4]. It SHOULD use the P-Asserted-ID
header field as the identity of the sender, rather than attempting to
authenticate the request using SIP digest or some other mechanism.
The ingress proxy SHOULD remove the P-Asserted-ID header field before
forwarding the request.
4.3. Ingress Proxy
An ingress proxy is one whose previous hop was not in the same
administrative domain. When an ingress proxy receives a request, it
MUST remove the P-Asserted-ID header field if present. This is done
regardless of the trust relationship with the originating domain, and
is different from the procedures in RFC 3325, where the P-Asserted-ID
is retained if it comes from a trusted peer. Once removed, the
ingress proxy checks for the presence of the Identity and Identity-
Info header fields. If present, the ingress proxy SHOULD verify the
identity of the sender using the procedures in [4]. If the identity
Rosenberg Expires December 21, 2006 [Page 7]
Internet-Draft Identity Coexistence June 2006
is verified, the ingress proxy SHOULD insert a P-Asserted-ID header
field containing the identity contained in the From header field of
the request. The proxy SHOULD NOT remove the Identity and Identity-
Info header fields. This allows for SIP networks where there are
more than two administrative domains in a request path, and also
allows for a UA to verify the signature on its own if it should
desire.
5. Interactions with B2BUAs
By using the SIP identity mechanism between domains, it will continue
to work in the presence of Contact or body-modifying B2BUAs in the
request path. In particular, any B2BUA on the request path prior to
the egress proxy, and any B2BUA on the request path subsequent to the
ingress proxy in the domain of the UAS, will not cause the mechanism
described here to fail. Note that, in cases where a proxy serves as
both a B2BUA and an egress proxy, it MUST perform the B2BUA function
prior to the egress functions described here. Similarly, in cases
where a proxy serves as a B2BUA and an ingress proxy, it MUST perform
the B2BUA function after the ingress functions described here.
It is important to note that the mechanism described here will not
work properly in transit networks that contain a B2BUA. A transit
network is defined as a SIP domain that is between the domain of the
originator and the domain of the terminating UA. If a B2BUA in a
transmit network touches the fields covered by the signature,
verification will fail at the ingress proxy in the termindating case.
6. Interactions with Privacy
Privacy has always been a complicated issue with the various identity
mechanisms. The privacy specification, RFC 3323 [2] is used by RFC
3325. However, it has a significant problem in that a UAS cannot
differentiate between a private caller (where the P-Asserted-ID has
been removed from the request) and identity unavailable (where the
domain of the originator didn't support P-Asserted-ID, or where the
originating network was the PSTN and no identity could be obtained).
The interactions with SIP identity and privacy are even more
complicated. RFC 3323 does not work with SIP identity; this is
documented in detail in [5].
Combining together RFC 3325 and SIP identity requires privacy
mechanisms to be combined as well.
A UA wishing to be anonymous would include an anonymous URI in the
From header field. This specification proposes that an anonymous
Rosenberg Expires December 21, 2006 [Page 8]
Internet-Draft Identity Coexistence June 2006
identity be indicated with the "user=anonymous" URI parameter,
extending the existing "user" URI parameter with this value. A UA
can either obtain an anonymous URI from its domain with mechanisms
TBD, or merely make up a random value for the user part of the URI,
using a domain of "anonymous.invalid".
The edge proxy would authenticate the request, and insert
P-Asserted-ID as normal. This would be stripped by the egress proxy.
If the From header field contained an anonyous URI that matched the
P-Asserted-ID header field (possible only if the anonymous URI had
been obtained from its domain), the egress proxy would sign the
request using SIP identity. Otherwise, it would not.
At the ingress proxy, the signature is verified if present. If not
present, no P-Asserted-ID is inserted. At the receiving UAS, if a
P-Asserted-ID was present, the "user=anonymous" URI parameter tells
the UAS that the requestor is anonymous and verified. If a
P-Asserted-ID is not present, the presence of the "user=anonymous"
URI parameter tells the UAS that the requestor is anonymous, and that
its identity is unverified. It can then render "Anonymous" or
whatever is appropriate for the user interface.
TODO: fold in the normative recommendations here into the UA and
proxy behaviors described above.
7. P-header or not?
With the recommendations in this document, we believe that the
applicability of P-Asserted-ID is now no longer limited. It becomes
applicable within the intra-domain signaling of any SIP domain. This
begs the question of whether the header field name should now be
changed to "Asserted-ID". The answer is an emphatic no! One of the
benefits of the coexist mechanism is that it is backwards compatible
with RFC 3325, which uses the P-Asserted-ID header field. This
exposes a weakness in the concepts in RFC 3427, since we will now
have a header with the P prefix which is not actually a P-header.
Procedurally, we'd recommend that, if this document moves forward, it
be done as an update to both SIP identity and RFC 3325, and be at
proposed standard status. Indeed, it should probably be done as an
actual revision to RFC 3325.
8. Benefits
This mechanism brings many benefits:
Rosenberg Expires December 21, 2006 [Page 9]
Internet-Draft Identity Coexistence June 2006
o Does not require the originating domain to know whether the
terminating domain supports the mechanism.
o Works in the presence of B2BUAs in the originating and terminating
domains.
o Makes P-Asserted-ID applicable only in intra-domain environments,
eliminating its primary security weakness
o Provides the cryptographic strengths of SIP identity to the
terminating domain, so that mechanisms such as spam detection can
be effective.
o The proposed privacy solution clearly defines a URI as anonymous
independent of the locale and language of the terminating domain
o The proposed privacy solution clearly differentiates an anonymous
request (one whose From header field contains the user=anonymous
parameter) from one where identity could not be provided
9. Security Considerations
The combination of RFC 3325 with SIP identity provides a mechanism
that is, overall, less secure than just SIP identity alone. With SIP
identity, the signature is inserted by the first hop proxy (edge
proxy) which performs the authentication. This allows all other
proxies in the originating domain to determine the identity of the
originator by verifying the signature. With the mechanism proposed
here, proxies within the domain of the originator would use the
P-Asserted-ID header field, which lacks any cryptographic signature.
This requires a greater degree of trust within the proxies of the
domain. A rogue proxy in the domain of the originator could insert a
fake P-Asserted-ID header field, and it would not be caught by the
coexist mechanism.
In addition, the mechanism here relies on a UAS to trust its
terminating domain to follow the procedures defined here and verify
the signature in the Identity header field. If a rogue proxy in the
terminating domain should insert a fake P-Asserted-ID header field,
this would not be caught by the coexist mechanism.
Though its overall security is weaker than SIP identity, we fear that
the perfect is the enemy of the good. Without changes, SIP identity
will be undeployable, and the industry will instead stick with the
much-worse P-Asserted-ID solution. The coexist mechanism trades some
security in exchange for a mechanism that is far more deployable.
Rosenberg Expires December 21, 2006 [Page 10]
Internet-Draft Identity Coexistence June 2006
As with RFC 3325, the links over which P-Asserted-ID is transmitted
SHOULD be secured with SIP over TLS. This prevents against MITM
attacks.
10. IANA Considerations
This specification defines a new SIP option tag and a new SIP URI
parameter.
10.1. Option Tag
This specification registers a new SIP option tag, as per the
guidelines in Section 27.1 of RFC 3261.
Name: id-coexist
Description: This option tag is used to identify the ID coexist
mechanism. It is primarily used to tell a UA that its domain
supports mechanisms which allow for the coexistence of
P-Asserted-ID and SIP identity.
10.2. URI Parameter
This specification extends the value of the user URI parameter, as
per the registry created by [3].
Name of the Parameter: user
Predefined Values: anonymous
RFC Reference: RFC XXXX [[NOTE TO IANA: Please replace XXXX with the
RFC number of this specification.]]
11. References
11.1. Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[2] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November 2002.
[3] Camarillo, G., "The Internet Assigned Number Authority (IANA)
Uniform Resource Identifier (URI) Parameter Registry for the
Rosenberg Expires December 21, 2006 [Page 11]
Internet-Draft Identity Coexistence June 2006
Session Initiation Protocol (SIP)", BCP 99, RFC 3969,
December 2004.
[4] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
draft-ietf-sip-identity-06 (work in progress), October 2005.
[5] Rosenberg, J., "Identity Privacy in the Session Initiation
Protocol (SIP)", draft-rosenberg-sip-identity-privacy-00 (work
in progress), July 2005.
11.2. Informative References
[6] Jennings, C., Peterson, J., and M. Watson, "Private Extensions
to the Session Initiation Protocol (SIP) for Asserted Identity
within Trusted Networks", RFC 3325, November 2002.
[7] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B.
Rosen, "Change Process for the Session Initiation Protocol
(SIP)", BCP 67, RFC 3427, December 2002.
[8] Rosenberg, J., "The Session Initiation Protocol (SIP) and Spam",
draft-ietf-sipping-spam-02 (work in progress), March 2006.
Rosenberg Expires December 21, 2006 [Page 12]
Internet-Draft Identity Coexistence June 2006
Author's Address
Jonathan Rosenberg
Cisco Systems
600 Lanidex Plaza
Parsippany, NJ 07054
US
Phone: +1 973 952-5000
Email: jdrosen@cisco.com
URI: http://www.jdrosen.net
Rosenberg Expires December 21, 2006 [Page 13]
Internet-Draft Identity Coexistence June 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Rosenberg Expires December 21, 2006 [Page 14]