draft-ietf-sipping-update-pai-06.txt   draft-ietf-sipping-update-pai-07.txt 
SIPPING WG J. Elwell SIPPING WG J. Elwell
Internet-Draft Siemens Enterprise Communications Internet-Draft Siemens Enterprise Communications
Updates: RFC 3325 September 23, 2008 Updates: RFC 3325 October 13, 2008
(if approved) (if approved)
Intended status: Informational Intended status: Informational
Expires: March 27, 2009 Expires: April 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-06.txt draft-ietf-sipping-update-pai-07.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 March 27, 2009. This Internet-Draft will expire on April 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 P-Asserted-Identity and P-Preferred-
methods such as UPDATE, REGISTER, MESSAGE, PUBLISH and ACK, and is Identity header fields with certain SIP methods such as UPDATE,
unclear on the use of this header field in responses. This document REGISTER, MESSAGE, PUBLISH and ACK, and does not specify how to
extends RFC 3325 to cover these situations. handle an unexpected number of URIs or unexpected URI schemes in
these header fields. This document 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 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. Inclusion of P-Asserted-Identity or 3.3. Dialog implications . . . . . . . . . . . . . . . . . . . 6
P-Preferred-Identity in a response . . . . . . . . . . . . 6 4. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3.1. Inclusion of P-Asserted-Identity or 4.1. UAC Behaviour . . . . . . . . . . . . . . . . . . . . . . 7
P-Preferred-Identity by a UAS in a response . . . . . 7 4.2. Proxy Behaviour . . . . . . . . . . . . . . . . . . . . . 7
3.3.2. Inclusion of P-Asserted-Identity by a proxy in a 4.3. Registrar Behaviour . . . . . . . . . . . . . . . . . . . 7
response . . . . . . . . . . . . . . . . . . . . . . . 7 4.4. UAS Behaviour . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Dialog implications . . . . . . . . . . . . . . . . . . . 8 4.5. General handling . . . . . . . . . . . . . . . . . . . . . 8
4. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8
4.1. UAC Behaviour . . . . . . . . . . . . . . . . . . . . . . 8 6. Security considerations . . . . . . . . . . . . . . . . . . . 9
4.1.1. Request handling . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.2. Response handling . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Proxy Behaviour . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
4.2.1. Request handling . . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . . 10
4.2.2. Response handling . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Registrar Behaviour . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 12
4.4. UAS Behaviour . . . . . . . . . . . . . . . . . . . . . . 10
4.4.1. Request handling . . . . . . . . . . . . . . . . . . . 10
4.4.2. Response handling . . . . . . . . . . . . . . . . . . 10
4.5. General handling . . . . . . . . . . . . . . . . . . . . . 10
5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Security considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 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 25 skipping to change at page 3, line 25
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 and
header field with certain SIP methods such as UPDATE [RFC3311], P-Preferred-Identity header fields with certain SIP methods such as
REGISTER, MESSAGE [RFC3428], PUBLISH [RFC3903] and ACK. Finally, RFC UPDATE [RFC3311], REGISTER, MESSAGE [RFC3428], PUBLISH [RFC3903] and
3325 is unclear on the use of this header field in responses. There ACK. This document extends RFC 3325 by allowing inclusion of the
are similar omissions concerning the P-Preferred-Identity header
field.
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 and allowing use of P-Asserted-Identity and
and, under certain conditions, allowing use of this header field in P-Preferred-Identity header fields in any request.
SIP responses. This document also allows the use of the P-Preferred-
Identity header field in some of these situations.
RFC 3325 allows the P-Asserted-Identity and P-Preferred-Identity 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 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 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 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 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 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 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 that is not based on a telephone number). This document therefore
provides forwards compatibility by mandating tolerance to the receipt provides forwards compatibility by mandating tolerance to the receipt
skipping to change at page 4, line 4 skipping to change at page 3, line 46
unduly restrictive in future, for example if there is a need to allow 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 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 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 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 that is not based on a telephone number). This document therefore
provides forwards compatibility by mandating tolerance to the receipt provides forwards compatibility by mandating tolerance to the receipt
of unexpected URIs. 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. RFC 4916
[RFC4916] specifies the use of RFC 4474 in mid-dialog requests, in
particular in requests in the reverse direction to the dialog-forming
request as a means of providing authenticated connected identity.
RFC 3325 is unclear on the use of P-Asserted-Identity in responses.
In contrast to requests, there is no means in SIP to challenge a UAS
to provide SIP digest authentication in a response. As a result,
there is currently no standardised mechanism whereby a proxy can
authenticate a UAS. Since authenticating the source of a message is
a pre-requisite for asserting an identity, this document does not
specify the use of the P-Asserted-Identity header field in responses.
This may be the subject of a future update to RFC 3325. Also this
document does not specify the use of the P-Preferred-Identity header
field in responses, as this would serve no purpose in the absence of
the ability for a proxy to insert the P-Asserted-Identity header
field.
3. Discussion 3. Discussion
3.1. Inclusion of P-Asserted-Identity by a UAC 3.1. Inclusion of P-Asserted-Identity by a UAC
RFC 3325 does not include procedures for a UAC to include the RFC 3325 does not include procedures for a UAC to include the
P-Asserted-Identity header field in a request. This can be P-Asserted-Identity header field in a request. This can be
meaningful if the UAC is in the same Trust Domain as the first meaningful if the UAC is in the same Trust Domain as the first
downstream SIP entity. Examples of types of UAC that are often downstream SIP entity. Examples of types of UAC that are often
suitable for inclusion in a Trust Domain are: suitable for inclusion in a Trust Domain are:
skipping to change at page 6, line 16 skipping to change at page 6, line 24
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.
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.
Thus there are several examples where P-Asserted-Identity could be Thus there are several examples where P-Asserted-Identity could be
used in requests with methods that are not provided for in RFC 3325 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 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 less obvious, but the inclusion of P-Asserted Identity would not
cause any harm. In any requests, the header field would simply 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 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 to the UAS. Similarly there are examples where P-Preferred-Identity
could be used in requests with methods that are not provided for in could be used in requests with methods that are not provided for in
RFC 3325 or any other RFC. RFC 3325 or any other RFC.
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 any request. Identity header field to be included in any request.
3.3. Inclusion of P-Asserted-Identity or P-Preferred-Identity in a 3.3. Dialog implications
response
There are cases where the inclusion of the P-Asserted-Identity header
field in responses would be useful. Retargeting of a request can
result in the responding entity having a different identity from that
placed in the To URI of the request. Inclusion of asserted identity
in a response would provide the UAC with the identity of the
responder. Some examples of the benefits to be gained include:
o Asserted identity in a 2xx response to an INVITE request would
indicate the identity of the connected user.
o Asserted identity in a provisional response to an INVITE request
would indicate the contacted (e.g., alerted) user.
o Asserted identity in a 2xx response to a MESSAGE request would
provide confirmation of where the message was delivered to.
o Asserted identity in certain 4xx/5xx/6xx responses would provide
an indication of where the response originated.
In the case of a request that results in the formation of a dialog, a
mid-dialog request (e.g., UPDATE) in the reverse direction can
provide the identity of the user at the destination end of that
dialog, and therefore the need to include asserted identity in a
response to the dialog-forming request to identify the connected user
is debatable. There can be some benefits in terms of ease of
interworking with PSTN, where such information is placed in the
response to a call establishment request. For other responses,
including successful responses to requests such as MESSAGE and
PUBLISH and unsuccessful responses, the use of a request in the
reverse direction is unsuitable.
Note that when the authenticated identity of the connected user is
to be provided using the From and Identity header fields (as
opposed to providing asserted identity using the P-Asserted-
Identity header field), RFC 4916 [RFC4916] requires this to be
done in a mid-dialog request (e.g., UPDATE) in the reverse
direction. This is because the Identity header field is defined
only for use in requests.
RFC 3325 is ambiguous on inclusion of P-Asserted-Identity in a
response. For example, section 4 of RFC 3325 talks about inclusion
of the header field in messages, as opposed to requests. Moreover
section 5 explicitly mentions "message (request or response)".
However, there are other places (e.g., sections 6, 7 and 8) that only
mention requests.
3.3.1. Inclusion of P-Asserted-Identity or P-Preferred-Identity by a
UAS in a response
It should be permissible for a UAS to insert a P-Asserted-Identity
header field into a response if it is within the same Trust Domain as
the SIP entity from which the request was received.
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
response, in order to express a preference when the authenticated
user has several identities.
This update to RFC 3325 allows a UAS to insert a P-Asserted-Identity
or P-Preferred-Identity header field in a response.
3.3.2. Inclusion of P-Asserted-Identity by a proxy in a response
Section 5 of RFC 3325 requires a proxy to authenticate the originator
of a message from a node outside the Trust Domain before including a
P-Asserted-Identity header field in the forwarded message. While
this is achievable for requests using SIP digest authentication, it
is not achievable in the same way for responses. A proxy cannot
challenge a response and cannot establish the authenticity of the
sender of a response. In practice, there is no standardised manner
by which a SIP proxy can authenticate the sender of the response.
Therefore, a proxy must not include a P-Asserted-Identity header
field when forwarding the response unless it has authenticated the
UAS by some means. The means to authenticate the UAS is outside the
scope of this document. However, future documents may define
techniques for response authentication.
This update to RFC 3325 allows a proxy to include a P-Asserted-
Identity header field in certain circumstances when forwarding a
response.
3.4. Dialog implications
A P-Asserted-Identity header field in a received request or response A P-Asserted-Identity header field in a received request asserts the
asserts the identity of the source of that request or response and identity of the source of that request and says nothing about the
says nothing about the source of subsequent received requests or source of subsequent received requests claiming to relate to the same
responses claiming to relate to the same dialog. The recipient can dialog. The recipient can make its own deductions about the source
make its own deductions about the source of subsequent requests or of subsequent requests not containing a P-Asserted-Identity header
responses not containing a P-Asserted-Identity header field. This field. This document does not change RFC 3325 in this respect.
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 and
allowing a P-Asserted-Identity or P-Preferred-Identity header field by allowing a P-Asserted-Identity or P-Preferred-Identity header
to appear in any request, and by allowing a P-Asserted-Identity field to appear in any request.
header field to appear in a response in certain circumstances.
4.1. UAC Behaviour 4.1. UAC Behaviour
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.
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. in RFC 3325.
4.1.2. Response handling
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
the identity provided by a Trust Domain to be privileged, or
intrinsically more trustworthy than other information in the
response. However, any particular behaviour is specific to
implementations or services. This document also does not mandate any
UA handling for multiple P-Asserted-Identity header field values that
happen to appear in a response (such as a SIP URI alongside a tel
URL).
However, if a UAC receives a response from a previous element it does
not trust, it MUST NOT use the P-Asserted-Identity header field in
any way.
If a UA is part of the Trust Domain from which it received a response
containing a P-Asserted-Identity header field, then it can use the
value internally but it MUST ensure that it does not forward the
information to any element that is not part of the Trust Domain if
the responding user has requested that asserted identity information
be kept private.
4.2. Proxy Behaviour 4.2. Proxy Behaviour
4.2.1. Request handling If a proxy receives a request containing a P-Asserted-Identity header
field from a UAC within the Trust Domain it MUST behave as for a
If a proxy receives a request from a UAC within the Trust Domain it request from any other node within the Trust Domain, in accordance
MUST behave as for a request from any other node within the Trust 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 a request containing a P-Asserted-Identity or If a proxy receives a request containing a P-Asserted-Identity or
P-Preferred-Identity header field, it MUST behave in accordance with P-Preferred-Identity header field, it MUST behave in accordance with
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
The proxy behaviour specified in RFC 3325 is applicable to responses
with the following qualifications. A proxy MUST NOT include a
P-Asserted-Identity header field when forwarding a response from a
node outside the Trust Domain unless it has authenticated the UAS by
some means. The means to authenticate the UAS is outside the scope
of this document.
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
P-Preferred-Identity header field is applicable also to responses,
subject to the qualification above concerning authentication of the
UAS as a pre-requisite for including a P-Asserted-Identity header
field when forwarding a response.
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 node within the Trust Domain. received over a secure transport from a node within the Trust Domain.
Otherwise it MAY use this as evidence that the registering UA has Otherwise it MAY use this as evidence that the registering UA has
been authenticated as representing the identity asserted in the been authenticated as representing the identity asserted in the
header field. header field.
4.4. UAS Behaviour 4.4. UAS Behaviour
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.
4.4.2. Response handling
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
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
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
connected to that SIP entity in accordance with the security
requirements of RFC 3325.
4.5. General handling 4.5. General handling
If an entity receives a request or response containing a P-Asserted- If an entity receives a request containing a P-Asserted-Identity or
Identity or P-Preferred-Identity header field containing an P-Preferred-Identity header field containing an unexpected number of
unexpected number of URIs or unexpected URI schemes it MUST act as URIs or unexpected URI schemes it MUST act as follows:
follows:
o ignore any URI with an unexpected URI scheme; o ignore any URI with an unexpected URI scheme;
o ignore any URI for which the expected maximum number of URIs with o ignore any URI for which the expected maximum number of URIs with
the same scheme occurred earlier in the header field; and the same scheme occurred earlier in the header field; and
o ignore any URI whose scheme is not expected to occur in o ignore any URI whose scheme is not expected to occur in
combination with a scheme that occurred earlier in the header combination with a scheme that occurred earlier in the header
field. field.
This document does not change the RFC 3325 requirement that allows 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 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 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 this document may relax that requirement. In the absence of such a
relaxation, the requirement above means that an entity receiving a relaxation, the requirement above means that an entity receiving a
request or response containing a P-Asserted-Identity or P-Preferred- request containing a P-Asserted-Identity or P-Preferred-Identity
Identity header field must act as follows: header field must act as follows:
o ignore any URI with a scheme other than SIP, SIPS or TEL; 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 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 message 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.
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 receiving a request or response containing a P-Asserted-Identity When receiving a request containing a P-Asserted-Identity header
header field, a proxy will trust the assertion only if the source is field, a proxy will trust the assertion only if the source is known
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
(such as a desk phone or mobile phone) should not be considered part (such as a desk phone or mobile phone) should not be considered part
of a Trust Domain. of a Trust Domain.
When receiving a response from a node outside the Trust Domain, a When receiving a response from a node outside the Trust Domain, a
proxy has no standardised SIP means to authenticate the node. proxy has no standardised SIP means to authenticate the node. For
However, if authentication has taken place by other means, outside this reason, this document does not specify the use of P-Asserted-
the scope of this document, this can be sufficient grounds for Identity or P-Preferred-Identity in responses.
asserting an identity. In other circumstances a proxy must not
assert identity for a responding user.
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,
 End of changes. 25 change blocks. 
223 lines changed or deleted 75 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/