draft-ietf-sipping-update-pai-04.txt   draft-ietf-sipping-update-pai-05.txt 
SIPPING WG J. Elwell SIPPING WG J. Elwell
Internet-Draft Siemens Enterprise Communications Internet-Draft Siemens Enterprise Communications
Updates: RFC 3325 GmbH & Co KG Updates: RFC 3325 GmbH & Co KG
(if approved) June 27, 2008 (if approved) August 15, 2008
Intended status: Informational Intended status: Informational
Expires: December 29, 2008 Expires: February 16, 2009
Updates to Asserted Identity in the Session Initiation Protocol (SIP) Updates to Asserted Identity in the Session Initiation Protocol (SIP)
draft-ietf-sipping-update-pai-04.txt draft-ietf-sipping-update-pai-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 29, 2008. This Internet-Draft will expire on February 16, 2009.
Abstract Abstract
SIP has a mechanism for conveying the asserted identity of the SIP has a mechanism for conveying the asserted identity of the
originator of a request by means of the P-Asserted-Identity header originator of a request by means of the P-Asserted-Identity header
field. This header field is specified for use in requests using a field. This header field is specified for use in requests using a
number of SIP methods, in particular the INVITE method. However, RFC number of SIP methods, in particular the INVITE method. However, RFC
3325 does not specify the insertion of this header field by a trusted 3325 does not specify the insertion of this header field by a trusted
UAC, does not specify the use of this header field with certain SIP UAC, does not specify the use of this header field with certain SIP
methods such as UPDATE, REGISTER, MESSAGE, PUBLISH and ACK, and is methods such as UPDATE, REGISTER, MESSAGE, PUBLISH and ACK, and is
unclear on the use of this header field in responses. This document unclear on the use of this header field in responses. This document
extends RFC 3325 to cover these situations. extends RFC 3325 to cover these situations.
This work is being discussed on the sipping@ietf.org mailing list. This work is being discussed on the sipping@ietf.org mailing list.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Inclusion of P-Asserted-Identity by a UAC . . . . . . . . 4 3.1. Inclusion of P-Asserted-Identity by a UAC . . . . . . . . 4
3.2. Inclusion of P-Asserted-Identity in any request . . . . . 4 3.2. Inclusion of P-Asserted-Identity in any request . . . . . 5
3.3. Inclusion of P-Asserted-Identity or 3.3. Inclusion of P-Asserted-Identity or
P-Preferred-Identity in a response . . . . . . . . . . . . 6 P-Preferred-Identity in a response . . . . . . . . . . . . 6
3.4. Dialog implications . . . . . . . . . . . . . . . . . . . 7 3.4. Dialog implications . . . . . . . . . . . . . . . . . . . 8
4. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. UAC Behaviour . . . . . . . . . . . . . . . . . . . . . . 8 4.1. UAC Behaviour . . . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Request handling . . . . . . . . . . . . . . . . . . . 8 4.1.1. Request handling . . . . . . . . . . . . . . . . . . . 8
4.1.2. Response handling . . . . . . . . . . . . . . . . . . 8 4.1.2. Response handling . . . . . . . . . . . . . . . . . . 8
4.2. Proxy Behaviour . . . . . . . . . . . . . . . . . . . . . 9 4.2. Proxy Behaviour . . . . . . . . . . . . . . . . . . . . . 9
4.2.1. Request handling . . . . . . . . . . . . . . . . . . . 9 4.2.1. Request handling . . . . . . . . . . . . . . . . . . . 9
4.2.2. Response handling . . . . . . . . . . . . . . . . . . 9 4.2.2. Response handling . . . . . . . . . . . . . . . . . . 9
4.3. Registrar Behaviour . . . . . . . . . . . . . . . . . . . 10 4.3. Registrar Behaviour . . . . . . . . . . . . . . . . . . . 10
4.4. UAS Behaviour . . . . . . . . . . . . . . . . . . . . . . 10 4.4. UAS Behaviour . . . . . . . . . . . . . . . . . . . . . . 10
4.4.1. Request handling . . . . . . . . . . . . . . . . . . . 10 4.4.1. Request handling . . . . . . . . . . . . . . . . . . . 10
4.4.2. Response handling . . . . . . . . . . . . . . . . . . 10 4.4.2. Response handling . . . . . . . . . . . . . . . . . . 10
5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 4.5. General handling . . . . . . . . . . . . . . . . . . . . . 10
6. Security considerations . . . . . . . . . . . . . . . . . . . 10 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 6. Security considerations . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
1. Terminology 1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This document uses the concepts of Trust Domain and Spec(T), as This document uses the concepts of Trust Domain and Spec(T), as
specified in section 2.3 of RFC 3324 [RFC3324]. specified in section 2.3 of RFC 3324 [RFC3324].
skipping to change at page 3, line 39 skipping to change at page 3, line 39
are similar omissions concerning the P-Preferred-Identity header are similar omissions concerning the P-Preferred-Identity header
field. field.
This document extends RFC 3325 by allowing inclusion of the This document extends RFC 3325 by allowing inclusion of the
P-Asserted-Identity header field by a UAC in the same Trust Domain as P-Asserted-Identity header field by a UAC in the same Trust Domain as
the first proxy, allowing use of this header field in any request the first proxy, allowing use of this header field in any request
and, under certain conditions, allowing use of this header field in and, under certain conditions, allowing use of this header field in
SIP responses. This document also allows the use of the P-Preferred- SIP responses. This document also allows the use of the P-Preferred-
Identity header field in some of these situations. Identity header field in some of these situations.
RFC 3325 allows the P-Asserted-Identity and P-Preferred-Identity
header fields each to contain at most two URIs, where one is a SIP or
SIPS URI [RFC3261] and the other is a TEL URI [RFC3966]. This may be
unduly restrictive in future, for example if there is a need to allow
other URI schemes, if there is a need to allow both a SIP and a SIPS
URI or if there is a need to allow more than one URI with the same
scheme (e.g., a SIP URI based on a telephone number and a SIP URI
that is not based on a telephone number). This document therefore
provides forwards compatibility by mandating tolerance to the receipt
of unexpected URIs.
This document does not alter the fact that the asserted identity This document does not alter the fact that the asserted identity
mechanism has limited applicability, i.e., within a Trust Domain. mechanism has limited applicability, i.e., within a Trust Domain.
For general applicability, including operation outside a Trust Domain For general applicability, including operation outside a Trust Domain
(e.g., over the public Internet) or between different Trust Domains, (e.g., over the public Internet) or between different Trust Domains,
a different mechanism is needed. RFC 4474 [RFC4474] specifies the a different mechanism is needed. RFC 4474 [RFC4474] specifies the
Identity header field, in conjunction with the From header field, for Identity header field, in conjunction with the From header field, for
providing authenticated identity in such circumstances. providing authenticated identity in such circumstances.
3. Discussion 3. Discussion
3.1. Inclusion of P-Asserted-Identity by a UAC 3.1. Inclusion of P-Asserted-Identity by a UAC
skipping to change at page 10, line 35 skipping to change at page 10, line 45
A UAS MAY include a P-Asserted-Identity or P-Preferred-Identity A UAS MAY include a P-Asserted-Identity or P-Preferred-Identity
header field in a response to report the identity of the user on header field in a response to report the identity of the user on
behalf of which the UAS is acting and whose identity the UAS is in a behalf of which the UAS is acting and whose identity the UAS is in a
position to assert. A UAS SHOULD include a P-Asserted-Identity position to assert. A UAS SHOULD include a P-Asserted-Identity
header field only in cases where it believes it is in the same Trust header field only in cases where it believes it is in the same Trust
Domain as the SIP entity from which it received the request and is Domain as the SIP entity from which it received the request and is
connected to that SIP entity in accordance with the security connected to that SIP entity in accordance with the security
requirements of RFC 3325. requirements of RFC 3325.
4.5. General handling
If an entity receives a request or response containing a P-Asserted-
Identity or P-Preferred-Identity header field containing an
unexpected number of URIs or unexpected URI schemes it MUST act as
follows:
o ignore any URI with an unexpected URI scheme;
o ignore any URI for which the expected maximum number of URIs with
the same scheme occurred earlier in the header field; and
o ignore any URI whose scheme is not expected to occur in
combination with a scheme that occurred earlier in the header
field.
This document does not change the RFC 3325 requirement that allows
each of these header fields to contain at most two URIs, where one is
a SIP or SIPS URI and the other is a TEL URI, but future updates to
this document may relax that requirement. In the absence of such a
relaxation, the requirement above means that an entity receiving a
request or response containing a P-Asserted-Identity or P-Preferred-
Identity header field must act as follows:
o ignore any URI with a scheme other than SIP, SIPS or TEL;
o ignore a second or subsequent SIP URI, a second or subsequent SIPS
URI or a second or subsequent TEL URI; and
o ignore a SIP URI if a SIPS URI occurred earlier in the header
field and vice versa.
A proxy MUST NOT forward a URI when forwarding a message if that URI
is to be ignored in accordance with the requirement above.
5. IANA considerations 5. IANA considerations
This document requires no IANA actions. This document requires no IANA actions.
6. Security considerations 6. Security considerations
The use of asserted identity raises a number of security The use of asserted identity raises a number of security
considerations, which are discussed fully in [RFC3325]. This considerations, which are discussed fully in [RFC3325]. This
document raises the following additional security considerations. document raises the following additional security considerations.
skipping to change at page 12, line 17 skipping to change at page 13, line 14
Asserted Identity within Trusted Networks", RFC 3325, Asserted Identity within Trusted Networks", RFC 3325,
November 2002. November 2002.
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
and D. Gurle, "Session Initiation Protocol (SIP) Extension and D. Gurle, "Session Initiation Protocol (SIP) Extension
for Instant Messaging", RFC 3428, December 2002. for Instant Messaging", RFC 3428, December 2002.
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
for Event State Publication", RFC 3903, October 2004. for Event State Publication", RFC 3903, October 2004.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004.
[I-D.ietf-sipping-uri-services] [I-D.ietf-sipping-uri-services]
Camarillo, G. and A. Roach, "Framework and Security Camarillo, G. and A. Roach, "Framework and Security
Considerations for Session Initiation Protocol (SIP) Considerations for Session Initiation Protocol (SIP)
Uniform Resource Identifier (URI)-List Services", Uniform Resource Identifier (URI)-List Services",
draft-ietf-sipping-uri-services-07 (work in progress), draft-ietf-sipping-uri-services-07 (work in progress),
November 2007. November 2007.
8.2. Informative References 8.2. Informative References
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
 End of changes. 12 change blocks. 
15 lines changed or deleted 66 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/