< draft-ietf-sipping-update-pai-08.txt   draft-ietf-sipping-update-pai-09.txt >
SIPPING WG J. Elwell SIPPING WG J. Elwell
Internet-Draft Siemens Enterprise Communications Internet-Draft Siemens Enterprise Communications
Updates: RFC 3325 December 16, 2008 Updates: RFC 3325 January 16, 2009
(if approved) (if approved)
Intended status: Informational Intended status: Informational
Expires: June 19, 2009 Expires: July 20, 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-08.txt draft-ietf-sipping-update-pai-09.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 June 19, 2009. This Internet-Draft will expire on July 20, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2008 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. to this document.
Abstract Abstract
skipping to change at page 2, line 34 skipping to change at page 2, line 34
3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . 5 3.2. Inclusion of P-Asserted-Identity in any request . . . . . 5
3.3. Dialog implications . . . . . . . . . . . . . . . . . . . 6 3.3. Dialog implications . . . . . . . . . . . . . . . . . . . 6
4. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. UAC Behaviour . . . . . . . . . . . . . . . . . . . . . . 7 4.1. UAC Behaviour . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Proxy Behaviour . . . . . . . . . . . . . . . . . . . . . 7 4.2. Proxy Behaviour . . . . . . . . . . . . . . . . . . . . . 7
4.3. Registrar Behaviour . . . . . . . . . . . . . . . . . . . 7 4.3. Registrar Behaviour . . . . . . . . . . . . . . . . . . . 7
4.4. UAS Behaviour . . . . . . . . . . . . . . . . . . . . . . 8 4.4. UAS Behaviour . . . . . . . . . . . . . . . . . . . . . . 8
4.5. General handling . . . . . . . . . . . . . . . . . . . . . 8 4.5. General handling . . . . . . . . . . . . . . . . . . . . . 8
5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security considerations . . . . . . . . . . . . . . . . . . . 9 6. Security considerations . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
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 8, line 48 skipping to change at page 8, line 48
o ignore a second or subsequent SIP URI, a second or subsequent SIPS o ignore a second or subsequent SIP URI, a second or subsequent SIPS
URI or a second or subsequent TEL URI; and URI or a second or subsequent TEL URI; and
o ignore a SIP URI if a SIPS URI occurred earlier in the header o ignore a SIP URI if a SIPS URI occurred earlier in the header
field and vice versa. field and vice versa.
A proxy MUST NOT forward a URI when forwarding a request if that URI A proxy MUST NOT forward a URI when forwarding a request if that URI
is to be ignored in accordance with the requirement above. is to be ignored in accordance with the requirement above.
When a UAC or a proxy sends a request containing a P-Asserted-
Identity header field to another node in the Trust Domain, if that
other node complies with RFC 3325 but not with this specification,
and if the method is not one for which RFC 3325 specifies use of the
P-Asserted-Identity header field, and if the request also contains a
Privacy header field with value 'id', as specified in RFC 3325, the
other node might not handle the Privacy header field correctly. To
prevent incorrect handling of the Privacy header field with value
'id', the Spec(T) in force for the Trust Domain SHOULD require all
nodes to comply with this specification. If this is not the case, a
UAC or a proxy SHOULD NOT include a P-Asserted-Identity header field
in a request if the method is not one for which RFC 3325 specifies
use of the P-Asserted-Identity header field and if the request also
contains a Privacy header field with value 'id'.
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.
When adding a P-Asserted-Identity header field to a message, an When adding a P-Asserted-Identity header field to a message, an
entity must have authenticated the source of the message by some entity must have authenticated the source of the message by some
means. One means is to challenge the sender of a message to provide means. One means is to challenge the sender of a message to provide
SIP digest authentication. Responses cannot be challenged, and also SIP digest authentication. Responses cannot be challenged, and also
ACK and CANCEL requests cannot be challenged. Therefore this ACK and CANCEL requests cannot be challenged. Therefore this
document limits the use of P-Asserted-Identity to requests other than document limits the use of P-Asserted-Identity to requests other than
ACK and CANCEL. ACK and CANCEL.
When sending a request containing the P-Asserted-Identity header
field and also the Privacy header field with value 'id' to a node
within the Trust Domain, special considerations apply if that node
does not support this specification. Section 4.5 makes special
provision for this case.
When receiving a request containing a P-Asserted-Identity header When receiving a request containing a P-Asserted-Identity header
field, a proxy will trust the assertion only if the source is known field, a proxy will trust the assertion only if the source is known
to be within the Trust Domain and behaves in accordance with a to be within the Trust Domain and behaves in accordance with a
Spec(T), which defines the security requirements. This applies Spec(T), which defines the security requirements. This applies
regardless of the nature of the resource (UA or proxy). One example regardless of the nature of the resource (UA or proxy). One example
where a trusted source might be a UA is a PSTN gateway. In this case where a trusted source might be a UA is a PSTN gateway. In this case
the UA can assert an identity received from the PSTN, the proxy the UA can assert an identity received from the PSTN, the proxy
itself having no means to authenticate such an identity. A SIP itself having no means to authenticate such an identity. A SIP
entity must not trust an identity asserted by a source outside the entity must not trust an identity asserted by a source outside the
Trust Domain. Typically a UA under the control of an individual user Trust Domain. Typically a UA under the control of an individual user
 End of changes. 10 change blocks. 
8 lines changed or deleted 29 lines changed or added

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