draft-ietf-sipping-update-pai-03.txt   draft-ietf-sipping-update-pai-04.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 26, 2008 (if approved) June 27, 2008
Intended status: Informational Intended status: Informational
Expires: December 28, 2008 Expires: December 29, 2008
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-03.txt draft-ietf-sipping-update-pai-04.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 28, 2008. This Internet-Draft will expire on December 29, 2008.
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
skipping to change at page 8, line 32 skipping to change at page 8, line 32
and whose identity the UAC is in a position to assert. A UAC SHOULD and whose identity the UAC is in a position to assert. A UAC SHOULD
do so only in cases where it believes it is in the same Trust Domain do so only in cases where it believes it is in the same Trust Domain
as the SIP entity to which it sends the request and is connected to as the SIP entity to which it sends the request and is connected to
that SIP entity in accordance with the security requirements of RFC that SIP entity in accordance with the security requirements of RFC
3325. A UAC SHOULD NOT do so in other circumstances and might 3325. A UAC SHOULD NOT do so in other circumstances and might
instead use the P-Preferred-Identity header field. A UAC MUST NOT instead use the P-Preferred-Identity header field. A UAC MUST NOT
include both header fields. include both header fields.
A UAC MAY include a P-Asserted-Identity or P-Preferred-Identity A UAC MAY include a P-Asserted-Identity or P-Preferred-Identity
header field in any request, i.e., not limited to the methods allowed header field in any request, i.e., not limited to the methods allowed
in RFC 3325. A UAC SHOULD include a P-Asserted-Identity header field in RFC 3325.
only in cases where it believes it is in the same Trust Domain as the
SIP entity to which it sends the request and is connected to that SIP
entity in accordance with the security requirements of RFC 3325.
4.1.2. Response handling 4.1.2. Response handling
Typically a UA renders the value of a P-Asserted-Identity header Typically a UA renders the value of a P-Asserted-Identity header
field that it receives in a response to its user. It may consider field that it receives in a response to its user. It may consider
the identity provided by a Trust Domain to be privileged, or the identity provided by a Trust Domain to be privileged, or
intrinsically more trustworthy than other information in the intrinsically more trustworthy than other information in the
response. However, any particular behaviour is specific to response. However, any particular behaviour is specific to
implementations or services. This document also does not mandate any implementations or services. This document also does not mandate any
UA handling for multiple P-Asserted-Identity header field values that UA handling for multiple P-Asserted-Identity header field values that
skipping to change at page 9, line 38 skipping to change at page 9, line 35
the rules of RFC 3325 for a proxy, even if the method is not one for the rules of RFC 3325 for a proxy, even if the method is not one for
which RFC 3325 specifies use of that header field. which RFC 3325 specifies use of that header field.
4.2.2. Response handling 4.2.2. Response handling
The proxy behaviour specified in RFC 3325 is applicable to responses The proxy behaviour specified in RFC 3325 is applicable to responses
with the following qualifications. A proxy that receives a response with the following qualifications. A proxy that receives a response
from a node outside the Trust Domain cannot directly authenticate the from a node outside the Trust Domain cannot directly authenticate the
UAS by SIP means. Therefore it MUST NOT include a P-Asserted- UAS by SIP means. Therefore it MUST NOT include a P-Asserted-
Identity header field when forwarding the response unless it has Identity header field when forwarding the response unless it has
authenticated the UAS by other means. If a proxy receives a response authenticated the UAS by other means.
from a UAS within the Trust Domain it MUST behave as for a response
from any other node within the Trust Domain, in accordance with the
rules of RFC 3325 for a proxy.
One possible circumstance in which a proxy can include a One possible circumstance in which a proxy can include a
P-Asserted-Identity header field when forwarding a response from a P-Asserted-Identity header field when forwarding a response from a
node outside the Trust Domain is when the proxy has direct TLS node outside the Trust Domain is when the proxy has direct TLS
connectivity with the UAS and has authenticated the UA by some connectivity with the UAS and has authenticated the UA by some
other means (e.g., SIP digest authentication) during that same TLS other means (e.g., SIP digest authentication) during that same TLS
session. session.
The proxy behaviour specified in RFC 3325 applies for handling a
P-Asserted-Identity header field in a response from a node within the
Trust Domain.
The proxy behaviour specified in RFC 3325 for handling a received The proxy behaviour specified in RFC 3325 for handling a received
P-Preferred-Identity header field is applicable also to responses, P-Preferred-Identity header field is applicable also to responses,
subject to the qualification above concerning authentication of the subject to the qualification above concerning authentication of the
UAS as a pre-requisite for inserting a P-Asserted-Identity header UAS as a pre-requisite for inserting a P-Asserted-Identity header
field. field.
4.3. Registrar Behaviour 4.3. Registrar Behaviour
If a registrar receives a REGISTER request containing a P-Asserted- If a registrar receives a REGISTER request containing a P-Asserted-
Identity header field, it MUST disregard the asserted identity unless Identity header field, it MUST disregard the asserted identity unless
received over a secure transport from a proxy within the Trust received over a secure transport from a node within the Trust Domain.
Domain. Otherwise it MAY use this as evidence that the registering Otherwise it MAY use this as evidence that the registering UA has
UA has been authenticated as representing the identity asserted in been authenticated as representing the identity asserted in the
the header field. header field.
4.4. UAS Behaviour 4.4. UAS Behaviour
4.4.1. Request handling 4.4.1. Request handling
If a UAS receives any request containing a P-Asserted-Identity header If a UAS receives any request containing a P-Asserted-Identity header
field, it MUST behave as for any other request in accordance with the field, it MUST behave as for any other request in accordance with the
rules of RFC 3325 for a UAS, even if the method is not one for which rules of RFC 3325 for a UAS, even if the method is not one for which
RFC 3325 specifies use of that header field. RFC 3325 specifies use of that header field.
 End of changes. 8 change blocks. 
16 lines changed or deleted 14 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/