draft-ietf-sipping-update-pai-02.txt   draft-ietf-sipping-update-pai-03.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) May 16, 2008 (if approved) June 26, 2008
Intended status: Informational Intended status: Informational
Expires: November 17, 2008 Expires: December 28, 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-02.txt draft-ietf-sipping-update-pai-03.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 November 17, 2008. This Internet-Draft will expire on December 28, 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 the SIP UAC, does not specify the use of this header field with certain SIP
UPDATE, REGISTER, MESSAGE or PUBLISH methods, and is unclear on the methods such as UPDATE, REGISTER, MESSAGE, PUBLISH and ACK, and is
use of this header field in responses. This document extends RFC unclear on the use of this header field in responses. This document
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 3
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 an UPDATE request . . 4 3.2. Inclusion of P-Asserted-Identity in any request . . . . . 4
3.3. Inclusion of P-Asserted-Identity in a REGISTER request . . 5 3.3. Inclusion of P-Asserted-Identity or
3.4. Inclusion of P-Asserted-Identity or
P-Preferred-Identity in a MESSAGE request . . . . . . . . 5
3.5. Inclusion of P-Asserted-Identity or
P-Preferred-Identity in a PUBLISH request . . . . . . . . 6
3.6. Inclusion of P-Asserted-Identity in an ACK request . . . . 6
3.7. 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
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 . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . 11 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security considerations . . . . . . . . . . . . . . . . . . . 11 6. Security considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 13
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 26 skipping to change at page 3, line 26
The Session Initiation Protocol (SIP) is specified in RFC 3261 The Session Initiation Protocol (SIP) is specified in RFC 3261
[RFC3261]. RFC 3325 [RFC3325] specifies a mechanism for conveying [RFC3261]. RFC 3325 [RFC3325] specifies a mechanism for conveying
within a Trust Domain the asserted identity of the originator of a within a Trust Domain the asserted identity of the originator of a
SIP request. This is achieved by means of the P-Asserted-Identity SIP request. This is achieved by means of the P-Asserted-Identity
header field, which is specified for use in requests using a number header field, which is specified for use in requests using a number
of SIP methods, in particular the INVITE method. of SIP methods, in particular the INVITE method.
RFC 3325 does not specify the insertion of the P-Asserted-Identity RFC 3325 does not specify the insertion of the P-Asserted-Identity
header field by a UAC in the same Trust Domain as the first proxy. header field by a UAC in the same Trust Domain as the first proxy.
Also RFC 3325 does not specify the use of the P-Asserted-Identity Also RFC 3325 does not specify the use of the P-Asserted-Identity
header field with the SIP UPDATE method [RFC3311], the SIP REGISTER header field with certain SIP methods such as UPDATE [RFC3311],
method, the SIP MESSAGE method [RFC3428], the SIP PUBLISH method REGISTER, MESSAGE [RFC3428], PUBLISH [RFC3903] and ACK. Finally, RFC
[RFC3903] or the SIP ACK method, and is unclear on the use of this 3325 is unclear on the use of this header field in responses. There
header field in responses. There are similar omissions concerning are similar omissions concerning the P-Preferred-Identity header
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 UPDATE, the first proxy, allowing use of this header field in any request
REGISTER, MESSAGE, PUBLISH and ACK requests and, under certain and, under certain conditions, allowing use of this header field in
conditions, allowing use of this header field in SIP responses. This SIP responses. This document also allows the use of the P-Preferred-
document also allows the use of the P-Preferred-Identity header field Identity header field in some of these situations.
in some of these situations.
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
skipping to change at page 4, line 42 skipping to change at page 4, line 42
in accordance with a Spec(T), and this principle needs to apply in accordance with a Spec(T), and this principle needs to apply
between a UAC and its proxy as part of the condition for considering between a UAC and its proxy as part of the condition for considering
the UAC to be within the same Trust Domain. Normal proxy procedures the UAC to be within the same Trust Domain. Normal proxy procedures
of RFC 3325 ensure that the header field is removed or replaced if of RFC 3325 ensure that the header field is removed or replaced if
the first proxy considers the UAC to be outside the Trust Domain. the first proxy considers the UAC to be outside the Trust Domain.
This update to RFC 3325 clarifies that a UAC may include a This update to RFC 3325 clarifies that a UAC may include a
P-Asserted-Identity header field in a request in certain P-Asserted-Identity header field in a request in certain
circumstances. circumstances.
3.2. Inclusion of P-Asserted-Identity in an UPDATE request 3.2. Inclusion of P-Asserted-Identity in any request
There are several use cases that would benefit from the use of the There are several use cases that would benefit from the use of the
P-Asserted-Identity header field in an UPDATE request. These use P-Asserted-Identity header field in an UPDATE request. These use
cases apply within a Trust Domain where the use of asserted identity cases apply within a Trust Domain where the use of asserted identity
is appropriate (see RFC 3325). is appropriate (see RFC 3325).
In one example, an established call passes through a gateway to the In one example, an established call passes through a gateway to the
PSTN. The gateway becomes aware that the remote party in the PSTN PSTN. The gateway becomes aware that the remote party in the PSTN
has changed, e.g., due to call transfer. By including the has changed, e.g., due to call transfer. By including the
P-Asserted-Identity header field in an UPDATE request, the gateway P-Asserted-Identity header field in an UPDATE request, the gateway
skipping to change at page 5, line 27 skipping to change at page 5, line 27
multiple early dialogs on the other side, so this action must wait multiple early dialogs on the other side, so this action must wait
until one of the called UAs answers. However, it would be useful to until one of the called UAs answers. However, it would be useful to
give an early indication to each user concerned of the identity of give an early indication to each user concerned of the identity of
the user to which they will become connected when the call is the user to which they will become connected when the call is
answered. In other words, it would provide the new calling UA with answered. In other words, it would provide the new calling UA with
the identity of the new called user and provide the new called UA(s) the identity of the new called user and provide the new called UA(s)
with the identity of the new calling user. This can be achieved by with the identity of the new calling user. This can be achieved by
the B2BUA sending an UPDATE request with a P-Asserted-Identity header the B2BUA sending an UPDATE request with a P-Asserted-Identity header
field on the dialogs concerned. field on the dialogs concerned.
This update to RFC 3325 allows a P-Asserted-Identity header field to
be included in an UPDATE request.
3.3. Inclusion of P-Asserted-Identity in a REGISTER request
Within a Trust Domain, a P-Asserted-Identity header field could Within a Trust Domain, a P-Asserted-Identity header field could
advantageously be used in a REGISTER request between an edge proxy advantageously be used in a REGISTER request between an edge proxy
that has authenticated the source of the request and the registrar. that has authenticated the source of the request and the registrar.
This update to RFC 3325 allows a P-Asserted-Identity header field to
be included in a REGISTER request.
3.4. Inclusion of P-Asserted-Identity or P-Preferred-Identity in a
MESSAGE request
Within a Trust Domain, a P-Asserted-Identity header field could Within a Trust Domain, a P-Asserted-Identity header field could
advantageously be used in a MESSAGE request to assert the source of a advantageously be used in a MESSAGE request to assert the source of a
page mode instant message. This would complement its use in an page mode instant message. This would complement its use in an
INVITE request to assert the source of an instant message session or INVITE request to assert the source of an instant message session or
any other form of session. Similarly, between a UAC and first proxy any other form of session. Similarly, between a UAC and first proxy
that are not within the same Trust Domain, a P-Preferred-Identity that are not within the same Trust Domain, a P-Preferred-Identity
header field could be used in a MESSAGE request to express a header field could be used in a MESSAGE request to express a
preference when the user has several identities. preference when the user has several identities.
This update to RFC 3325 allows a P-Asserted-Identity or P-Preferred-
Identity header field to be included in a MESSAGE request.
3.5. Inclusion of P-Asserted-Identity or P-Preferred-Identity in a
PUBLISH request
Within a Trust Domain, a P-Asserted-Identity header field could Within a Trust Domain, a P-Asserted-Identity header field could
advantageously be used in a PUBLISH request to assert the source of advantageously be used in a PUBLISH request to assert the source of
published state information. This would complement its use in published state information. This would complement its use in
SUBSCRIBE and NOTIFY requests. Similarly, between a UAC and first SUBSCRIBE and NOTIFY requests. Similarly, between a UAC and first
proxy that are not within the same Trust Domain, a P-Preferred- proxy that are not within the same Trust Domain, a P-Preferred-
Identity header field could be used in a PUBLISH request to express a Identity header field could be used in a PUBLISH request to express a
preference when the user has several identities. preference when the user has several identities.
This update to RFC 3325 allows a P-Asserted-Identity or P-Preferred-
Identity header field to be included in a PUBLISH request.
3.6. Inclusion of P-Asserted-Identity in an ACK request
Within a Trust Domain, a P-Asserted-Identity header field could Within a Trust Domain, a P-Asserted-Identity header field could
advantageously be used in an ACK request. Considering the 3PCC advantageously be used in an ACK request. Considering the 3PCC
scenario in Flow I of [RFC3725], the asserted identity of user B may scenario in Flow I of [RFC3725], the asserted identity of user B may
not be known when the B2BUA (controller) sends the initial INVITE not be known when the B2BUA (controller) sends the initial INVITE
request to UA A, but might be known when the B2BUA sends the ACK request to UA A, but might be known when the B2BUA sends the ACK
request to UA A (having received it in the 200 response from UA B). request to UA A (having received it in the 200 response from UA B).
This update to RFC 3325 allows a P-Asserted-Identity header field to Thus there are several examples where P-Asserted-Identity could be
be included in an ACK request. used in requests with methods that are not provided for in RFC 3325
or any other RFC. This leaves a few methods for which use cases are
less obvious, but the inclusion of P-Asserted Identity would not
cause any harm. In any requests, the header field would simply
assert the source of that request, whether or not this is of any use
to the UAS. Similarly there are examples where P-Preferred-Identity
could be used in requests with methods that are not provided for in
RFC 3325 or any other RFC.
3.7. Inclusion of P-Asserted-Identity or P-Preferred-Identity in a This update to RFC 3325 allows a P-Asserted-Identity or P-Preferred-
Identity header field to be included in any request.
3.3. Inclusion of P-Asserted-Identity or P-Preferred-Identity in a
response response
There are cases where the inclusion of the P-Asserted-Identity header There are cases where the inclusion of the P-Asserted-Identity header
field in responses would be useful. Retargeting of a request can field in responses would be useful. Retargeting of a request can
result in the responding entity having a different identity from that result in the responding entity having a different identity from that
placed in the To URI of the request. Inclusion of asserted identity placed in the To URI of the request. Inclusion of asserted identity
in a response would provide the UAC with the identity of the in a response would provide the UAC with the identity of the
responder. Some examples of the benefits to be gained include: responder. Some examples of the benefits to be gained include:
o Asserted identity in a 2xx response to an INVITE request would o Asserted identity in a 2xx response to an INVITE request would
skipping to change at page 8, line 11 skipping to change at page 7, line 46
Between a UAS and a SIP entity that are not within the same Trust Between a UAS and a SIP entity that are not within the same Trust
Domain, a P-Preferred-Identity header field could be used in a Domain, a P-Preferred-Identity header field could be used in a
response, in order to express a preference when the authenticated response, in order to express a preference when the authenticated
user has several identities. user has several identities.
This update to RFC 3325 allows a P-Asserted-Identity or P-Preferred- This update to RFC 3325 allows a P-Asserted-Identity or P-Preferred-
Identity header field to be included in a response in certain Identity header field to be included in a response in certain
circumstances. circumstances.
3.4. Dialog implications
A P-Asserted-Identity header field in a received request or response
asserts the identity of the source of that request or response and
says nothing about the source of subsequent received requests or
responses claiming to relate to the same dialog. The recipient can
make its own deductions about the source of subsequent requests or
responses not containing a P-Asserted-Identity header field. This
document does not change RFC 3325 in this respect.
4. Behaviour 4. Behaviour
This document updates RFC 3325 by allowing a P-Asserted-Identity This document updates RFC 3325 by allowing a P-Asserted-Identity
header field to be included by a UAC within the same Trust Domain, by header field to be included by a UAC within the same Trust Domain, by
allowing a P-Asserted-Identity header field to appear in an UPDATE, allowing a P-Asserted-Identity or P-Preferred-Identity header field
MESSAGE or PUBLISH request, and by allowing a P-Asserted-Identity to appear in any request, and by allowing a P-Asserted-Identity
header field to appear in a response in certain circumstances. It header field to appear in a response in certain circumstances.
also allows a P-Preferred-Identity header field to appear in a
MESSAGE or PUBLISH request or in a response.
4.1. UAC Behaviour 4.1. UAC Behaviour
4.1.1. Request handling 4.1.1. Request handling
A UAC MAY include a P-Asserted-Identity header field in a request to A UAC MAY include a P-Asserted-Identity header field in a request to
report the identity of the user on behalf of which the UAC is acting report the identity of the user on behalf of which the UAC is acting
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.
In addition to the methods specified in RFC 3325, a UAC MAY include a A UAC MAY include a P-Asserted-Identity or P-Preferred-Identity
P-Asserted-Identity header field in an UPDATE request to report a header field in any request, i.e., not limited to the methods allowed
changed identity mid-dialog. This can be an UPDATE request sent in RFC 3325. A UAC SHOULD include a P-Asserted-Identity header field
specially for this purpose or an UPDATE request sent for some other only in cases where it believes it is in the same Trust Domain as the
purpose. A UAC SHOULD do so only in cases where it believes it is in SIP entity to which it sends the request and is connected to that SIP
the same Trust Domain as the SIP entity to which it sends the request entity in accordance with the security requirements of RFC 3325.
and is connected to that SIP entity in accordance with the security
requirements of RFC 3325.
In addition to the methods specified in RFC 3325, a UAC MAY include a
P-Asserted-Identity or P-Preferred-Identity header field in a
MESSAGE, PUBLISH or ACK request. A UAC SHOULD include a P-Asserted-
Identity header field 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 41 skipping to change at page 9, line 26
If a proxy receives a request from a UAC within the Trust Domain it If a proxy receives a request from a UAC within the Trust Domain it
MUST behave as for a request from any other node within the Trust MUST behave as for a request from any other node within the Trust
Domain, in accordance with the rules of RFC 3325 for a proxy. Domain, in accordance with the rules of RFC 3325 for a proxy.
Note that this implies that the proxy must have authenticated the Note that this implies that the proxy must have authenticated the
sender of the request in accordance with the Spec(T) in force for sender of the request in accordance with the Spec(T) in force for
the Trust Domain and determined that the sender is indeed part of the Trust Domain and determined that the sender is indeed part of
the Trust Domain. the Trust Domain.
If a proxy receives an UPDATE, REGISTER, MESSAGE, PUBLISH or ACK If a proxy receives a request containing a P-Asserted-Identity or
request containing a P-Asserted-Identity header field, it MUST behave P-Preferred-Identity header field, it MUST behave in accordance with
as for any other request in accordance with the rules of RFC 3325 for the rules of RFC 3325 for a proxy, even if the method is not one for
a proxy. which RFC 3325 specifies use of that header field.
If a proxy receives a MESSAGE or PUBLISH request containing a
P-Preferred-Identity header field, it MUST behave as for any other
request in accordance with the rules of RFC 3325 for a proxy.
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. If a proxy receives a response
from a UAS within the Trust Domain it MUST behave as for a response from a UAS within the Trust Domain it MUST behave as for a response
skipping to change at page 10, line 43 skipping to change at page 10, line 21
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 proxy within the Trust
Domain. Otherwise it MAY use this as evidence that the registering Domain. Otherwise it MAY use this as evidence that the registering
UA has been authenticated as representing the identity asserted in UA has been authenticated as representing the identity asserted in
the header field. the header field.
4.4. UAS Behaviour 4.4. UAS Behaviour
4.4.1. Request handling 4.4.1. Request handling
If a UAS receives an UPDATE, MESSAGE, PUBLISH or ACK request If a UAS receives any request containing a P-Asserted-Identity header
containing a P-Asserted-Identity header field, it MUST behave as for field, it MUST behave as for any other request in accordance with the
any other request in accordance with the rules of RFC 3325 for a UAS. rules of RFC 3325 for a UAS, even if the method is not one for which
RFC 3325 specifies use of that header field.
4.4.2. Response handling 4.4.2. Response handling
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
skipping to change at page 12, line 5 skipping to change at page 11, line 32
When receiving a REGISTER request containing a P-Asserted-Identity When receiving a REGISTER request containing a P-Asserted-Identity
header field, a proxy will trust the asserted identity only if header field, a proxy will trust the asserted identity only if
received over a secure connection from a proxy within the Trust received over a secure connection from a proxy within the Trust
Domain. Domain.
7. Acknowledgements 7. Acknowledgements
Useful comments were received from Francois Audet, Jeroen van Bemmel, Useful comments were received from Francois Audet, Jeroen van Bemmel,
Hans Erik van Elburg, Vijay Gurbani, Cullen Jennings, Hadriel Kaplan, Hans Erik van Elburg, Vijay Gurbani, Cullen Jennings, Hadriel Kaplan,
Paul Kyzivat, Jonathan Rosenberg and Thomas Stach during drafting and Paul Kyzivat, Jonathan Rosenberg, Thomas Stach and Brett Tate during
review. drafting and review.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
 End of changes. 27 change blocks. 
94 lines changed or deleted 71 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/