One document matched: draft-elwell-sipping-update-pai-01.txt
Differences from draft-elwell-sipping-update-pai-00.txt
SIPPING WG J. Elwell
Internet-Draft Siemens Enterprise Communications
Updates: RFC 3325 Limited
(if approved) February 26, 2007
Intended status: Informational
Expires: August 30, 2007
The use of Asserted Identity in the Session Initiation Protocol (SIP)
UPDATE method
draft-elwell-sipping-update-pai-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 30, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
SIP has a mechanism for conveying the asserted identity of the
originator of a request by means of the P-Asserted-Identity header
field. This header field is specified for use in requests using a
number of SIP methods, in particular the INVITE method. However, RFC
3325 does not specify the insertion of this header field by a UAC,
Elwell Expires August 30, 2007 [Page 1]
Internet-Draft Asserted Identity in SIP UPDATE February 2007
does not specify the use of this header field with the SIP UPDATE
method, and is unclear on the use of this header field in responses.
This document extends RFC 3325 to cover these situations.
This work is being discussed on the sipping@ietf.org mailing list.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Inclusion of P-Asserted-Identity by a UAC . . . . . . . . . 3
3.2. Inclusion of P-Asserted-Identity in an UPDATE request . . . 3
3.3. Inclusion of P-Asserted-Identity in a response . . . . . . 4
4. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. UAC Behaviour . . . . . . . . . . . . . . . . . . . . . . . 5
4.1.1. Request handling . . . . . . . . . . . . . . . . . . . 5
4.1.2. Response handling . . . . . . . . . . . . . . . . . . . 5
4.2. Proxy Behaviour . . . . . . . . . . . . . . . . . . . . . . 6
4.2.1. Request handling . . . . . . . . . . . . . . . . . . . 6
4.2.2. Response handling . . . . . . . . . . . . . . . . . . . 6
4.3. UAS Behaviour . . . . . . . . . . . . . . . . . . . . . . . 6
4.3.1. Request handling . . . . . . . . . . . . . . . . . . . 6
4.3.2. Response handling . . . . . . . . . . . . . . . . . . . 6
5. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. Security considerations . . . . . . . . . . . . . . . . . . . . 7
7. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Elwell Expires August 30, 2007 [Page 2]
Internet-Draft Asserted Identity in SIP UPDATE February 2007
1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [2].
2. Introduction
SIP (RFC 3261 [1]) has a mechanism for conveying the asserted
identity of the originator of a request by means of the P-Asserted-
Identity header field (RFC 3325 [4]). This header field is specified
for use in requests using a number of SIP methods, in particular the
INVITE method. However, RFC 3325 does not specify the insertion of
this header field by a UAC, does not specify the use of this header
field with the SIP UPDATE method (RFC 3311 [3]), and is unclear on
the use of this header field in responses. This document extends RFC
3325 by allowing inclusion of the P-Asserted-Identity header field by
trusted UACs, allowing use of this header field in UPDATE requests
and, in certain conditions, allowing use of this header field in SIP
responses.
3. Discussion
3.1. Inclusion of P-Asserted-Identity by a UAC
RFC 3325 does not include procedures for a UAC to include the
P-Asserted-Identity header field in a request. This can be
meaningful if the UAC can be trusted by the first proxy, as is often
the case for PSTN gateways, for example. Indeed it is common
practice to do so. Normal proxy procedures would ensure that the
header field is removed or replaced if the UAC cannot be trusted and
the asserted identity cannot be authenticated.
3.2. Inclusion of P-Asserted-Identity in an UPDATE request
There are several use cases that would benefit from the use of the
P-Asserted-Identity header field in an UPDATE request. These use
cases apply within a trusted environment where the use of asserted
identity is appropriate (see RFC 3325).
In one example an established call passes through a gateway to the
PSTN. The gateway becomes aware that the remote party in the PSTN
has changed, e.g., due to call transfer. By including the
P-Asserted-Identity header field in an UPDATE request, the gateway
can convey the identity of the new remote party to the peer SIP UA.
Elwell Expires August 30, 2007 [Page 3]
Internet-Draft Asserted Identity in SIP UPDATE February 2007
Note that the (re-)INVITE method could be used in this situation.
However, this forces an offer-answer exchange, which typically is
not required in this situation. Also it involves 3 messages
rather than 2.
In another example, a B2BUA that provides third party call control
(3PCC) wishes to join two calls together, one of which is still
waiting to be answered and potentially is forked to different UAs.
At this point in time it is not possible to trigger the normal offer-
answer exchange between the two joined parties, because of the
mismatch between a single dialog on the one side and potentially
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
give an early indication to each user concerned of the identity of
the user to which they will become connected when the call is
answered. This can be achieved by the B2BUA sending an UPDATE
request with a P-Asserted-Identity header field on the dialogs
concerned.
3.3. Inclusion of P-Asserted-Identity in a response
There are cases where the inclusion of the P-Asserted-Identity header
field in responses would be useful. RFC 3325 is ambiguous on this.
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 talk only about
requests.
Section 5 of RFC 3325 requires a proxy to authenticate the originator
of a message before adding a P-Asserted-Identity header field to the
forwarded message. In practice there is no SIP means to authenticate
the sender of a SIP response message. However, authentication may be
possible by other means. For example, if the proxy has TLS
connectivity with the originator of the response and has previously
authenticated that entity (e.g., using SIP digest authentication at
registration time), then the originator of the response can be
considered to be authenticated. In such circumstances it is
permissible for a proxy to insert a P-Asserted-Identity header field
in a SIP response.
4. Behaviour
This updates RFC 3325 by allowing a P-Asserted-Identity header field
to be included by a UAC, by allowing a P-Asserted-Identity header
field to appear in an UPDATE request, and by allowing a P-Asserted-
Identity header field to appear in a response in certain
Elwell Expires August 30, 2007 [Page 4]
Internet-Draft Asserted Identity in SIP UPDATE February 2007
circumstances.
4.1. UAC Behaviour
4.1.1. Request handling
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
and whose identity the UAC is in a position to assert. A UAC SHOULD
do so only in cases where it can expect to be trusted by the first
proxy. A UAC SHOULD NOT do so in other circumstances and might
instead use the P-Preferred-Identity header field.
Note that a proxy might trust a UAC such as a known PSTN gateway.
The proxy might trust the PSTN gateway to assert an identity
received from the PSTN, the proxy itself having no means to
authenticate such an identity.
A UAC MAY include a P-Asserted-Identity header field in an UPDATE
request to report a changed identity mid-dialog. This can be an
UPDATE request sent specially for this purpose or an UPDATE request
sent for some other purpose.
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 that 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 freely but it MUST ensure that it does not forward the
information to any element that is not part of the Trust Domain if
the user has requested that asserted identity information be kept
private.
If a UA is not part of the Trust Domain from which it received a
response containing a P-Asserted-Identity header field, then it can
Elwell Expires August 30, 2007 [Page 5]
Internet-Draft Asserted Identity in SIP UPDATE February 2007
assume this information does not need to be kept private.
4.2. Proxy Behaviour
4.2.1. Request handling
If a proxy receives an UPDATE request containing a P-Asserted-
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
The proxy behaviour specified in RFC 3325 is applicable to responses
with the following qualification. A proxy that receives a response
from a node that it does not trust cannot directly authenticate the
UAS by SIP means. Therefore it MUST NOT include a P-Asserted-
Identity header field when forwarding the response unless it has
authenticated the UAS by other means.
One possible circumstance in which a proxy can include a
P-Asserted-Identity header field when forwarding a response from a
node that it does not trust is when the proxy has direct TLS
connectivity with the UAS and has authenticated the UA by some
other means (e.g., SIP digest authentication) during that same TLS
session.
4.3. UAS Behaviour
4.3.1. Request handling
If a UAS receives an UPDATE request containing a P-Asserted-Identity
header field, it MUST behave as for any other request in accordance
with the rules of RFC 3325 for a UAS.
4.3.2. Response handling
A UAS MAY include a P-Asserted-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
do so only in cases where it can expect to be trusted by the first
proxy that handles the response.
Note that a proxy might trust a UAS such as a known PSTN gateway.
The proxy might trust the PSTN gateway to assert an identity
received from the PSTN, the proxy itself having no means to
authenticate such an identity.
Elwell Expires August 30, 2007 [Page 6]
Internet-Draft Asserted Identity in SIP UPDATE February 2007
5. IANA considerations
None
6. Security considerations
The use of asserted identity raises a number of security
considerations, which are discussed fully in RFC 3325 [4]. This
document raises the following additional security considerations.
When receiving a request or response containing a P-Asserted-Identity
header field directly from a UA (rather than from another proxy), a
proxy may trust the UA in certain circumstances. This might occur if
the UA is a known PSTN gateway and the request or response has been
secured by TLS. The proxy might trust the PSTN gateway to assert an
identity received from the PSTN, the proxy itself having no means to
authenticate such an identity. In other circumstances a proxy should
not trust an identity asserted by a UA.
When receiving a response from an untrusted node, a proxy has no
direct SIP means to authenticate the node. However, if
authentication has taken place by other means (e.g., an earlier use
of SIP digest authentication) and the entity sending the response is
known to be the same entity (e.g., connected via the same TLS
session) this can be sufficient grounds for asserting an identity.
In other circumstances a proxy must not assert identity for a
responding user.
7. Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, September 2002.
[4] Jennings, C., Peterson, J., and M. Watson, "Private Extensions
to the Session Initiation Protocol (SIP) for Asserted Identity
within Trusted Networks", RFC 3325, November 2002.
Elwell Expires August 30, 2007 [Page 7]
Internet-Draft Asserted Identity in SIP UPDATE February 2007
Author's Address
John Elwell
Siemens Enterprise Communications Limited
Technology Drive
Beeston, Nottingham NG9 1LA
UK
Phone: +44 115 943 4989
Email: john.elwell@siemens.com
Elwell Expires August 30, 2007 [Page 8]
Internet-Draft Asserted Identity in SIP UPDATE February 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Elwell Expires August 30, 2007 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-23 22:31:43 |