One document matched: draft-ietf-sip-connected-identity-02.txt
Differences from draft-ietf-sip-connected-identity-01.txt
SIP WG J. Elwell
Internet-Draft Siemens Enterprise Communications
Updates: RFC 3261 and RFC 4474 (if Limited
approved) October 5, 2006
Intended status: Informational
Expires: April 8, 2007
Connected Identity in the Session Initiation Protocol (SIP)
draft-ietf-sip-connected-identity-02.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 April 8, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Because of retargeting of a Session Initiation Protocol (SIP) dialog-
forming request, the User Agent Server (UAS) can have a different
identity from that in the To header field. This document provides a
means for that User Agent (UA) to supply its identity to the peer UA
by means of a request in the reverse direction and for that identity
to be signed by an Authentication Service. The same mechanism can be
Elwell Expires April 8, 2007 [Page 1]
Internet-Draft SIP Connected ID October 2006
used to indicate a change of identity during a dialog, e.g., because
of some action in a Public Switched Telephone Network (PSTN) behind a
gateway. This document normatively updates RFC 3261 (SIP) and RFC
4474 (SIP Identity).
This work is being discussed on the sip@ietf.org mailing list.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of solution . . . . . . . . . . . . . . . . . . . . . 4
4. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Behaviour of a UA that issues an INVITE request
outside the context of an existing dialog . . . . . . . . 5
4.2. Behaviour of a UA that receives an INVITE request
outside the context of an existing dialog . . . . . . . . 6
4.3. Behaviour of a UA whose identity changes during an
established INVITE-initiated dialog . . . . . . . . . . . 6
4.4. General UA behaviour . . . . . . . . . . . . . . . . . . . 7
4.4.1. Sending a mid-dialog request . . . . . . . . . . . . . 7
4.4.2. Receiving a mid-dialog request . . . . . . . . . . . . 7
4.5. Authentication Service Behaviour . . . . . . . . . . . . . 8
4.6. Verifier Behaviour . . . . . . . . . . . . . . . . . . . . 8
4.7. Proxy Behaviour . . . . . . . . . . . . . . . . . . . . . 9
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Sending connected identity after answering a call . . . . 10
5.2. Sending revised connected identity during a call . . . . . 15
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 20
7. Security considerations . . . . . . . . . . . . . . . . . . . 20
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Existing mechanisms . . . . . . . . . . . . . . . . . 22
A.1. Existing mechanisms for conveying identity in the
context of a call . . . . . . . . . . . . . . . . . . . . 22
A.2. Existing methods for providing authenticated identity
information . . . . . . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 25
Elwell Expires April 8, 2007 [Page 2]
Internet-Draft SIP Connected ID October 2006
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].
This specification defines the following additional terms:
caller: the user of the UA that issues an INVITE request to
initiate a call.
caller identity: the identity (Address of Record) of a caller.
callee: the user of the UA that answers a call by issuing a 2xx
response to an INVITE request.
callee identity: the identity (Address of Record) of a callee.
potential callee: the user of any UA to which an INVITE request
is targeted resulting in formation of an early dialog, but
because of parallel or serial forking of the request, not
necessarily the user that answers the call.
connected user: any user involved in an established call,
including the caller, the callee or any user that replaces the
caller or callee following a call re-arrangement such as call
transfer.
connected identity: the identity (Address of Record) of a
connected user.
2. Introduction
SIP (RFC 3261 [1]) initiates sessions but it also provides
information on the identities of the parties at both ends of a
session. Users need this information to help determine how to deal
with communications initiated by SIP. As a call proceeds, these
identities may change. This can happen for many reasons: calls are
forwarded, calls are parked and picked up, calls are transferred,
calls are queued to be picked up by a pool of agents, and so on.
This can have impact on the identity of the party that answers a
call. It can also cause the identity of a party to change during an
established call.
This document extends the use of the From header field to allow it to
convey "connected identity" information (the identity of the
connected user) in either direction within the context of an existing
Elwell Expires April 8, 2007 [Page 3]
Internet-Draft SIP Connected ID October 2006
INVITE-initiated dialog. It can be used to convey:
o the callee identity to a caller when a call is answered;
o the identity of a potential callee prior to answer; or
o the identity of a user that replaces the caller or callee
following a call re-arrangement such as call transfer.
A survey of existing mechanisms for conveyance and authentication of
identity information is given in Appendix A.
The provision of the identity of the responder in a response
("response identity") is outside the scope of this document.
3. Overview of solution
A mid-dialog request is used to provide connected identity. The UAC
for that request inserts its identity in the From header field of the
request and the Identity header field (RFC 4474 [3]) can be used to
provide authentication. The Identity header field is inserted by a
suitable Authentication Service on the path of the mid-dialog
request, typically at a proxy that record routes and is able to
authenticate the UAC.
A request in the opposite direction to the INVITE request prior to or
at the time the call is answered can indicate the identity of the
potential callee or callee respectively. A request in the same
direction as the INVITE request prior to answer can indicate a change
of caller. A request in either direction after answer can indicate a
change of connected user. In all cases a dialog (early or confirmed)
must be established before such a request can be sent.
This solution uses the UPDATE method (RFC 3311 [4]) for the
additional request. To send the callee identity the UAS for the
INVITE request sends the UPDATE request after sending the 2xx
response to the INVITE request and receiving an ACK request. To send
the potential callee identity the UAS for the INVITE request sends
the UPDATE request after sending a reliable 1xx response to the
INVITE request and after receiving a PRACK request and responding to
it. The UPDATE request could conceivably be used for other purposes
too, e.g., during an early dialog it could be used to send the
potential callee identity at the same time as an SDP offer for early
media. To indicate a connected identity change during an established
call, the re-INVITE method can be used if required for other purposes
(e.g., when a B2BUA performs transfer using 3PCC techniques it may
need to issue a re-INVITE request without an SDP offer to solicit an
SDP offer from the UA).
This solution involves changing the URI (not the tags) in the To and
Elwell Expires April 8, 2007 [Page 4]
Internet-Draft SIP Connected ID October 2006
From header fields of mid-dialog requests and their responses,
compared with the corresponding values in the dialog forming request
and response. Changing the To and From header field URIs was
contemplated in Section 12.2.1.1 of RFC 3261, which says:
"Usage of the URI from the To and From fields in the original
request within subsequent requests is done for backwards
compatibility with RFC 2543, which used the URI for dialog
identification. In this specification, only the tags are used for
dialog identification. It is expected that mandatory reflection
of the original To and From URI in mid-dialog requests will be
deprecated in a subsequent revision of this specification."
This document therefore deprecates mandatory reflection of the
original To and From URIs in mid-dialog requests and their responses,
which constitutes a change to RFC 3261. It is assumed that deployed
proxies will already be able to tolerate a change of URI, since this
has been expected for a considerable time. To cater for any UAs that
are not able to tolerate a change of URI, a new option tag "from-
change" is introduced for providing a positive indication of support
in the Supported header field. By sending a request with a changed
From header field URI only to targets that have indicated support for
this option, there should be no need to send this option tag in a
Require header field.
In addition to allowing the From header field URI to change during a
dialog to reflect the connected identity, this document also requires
a UA that has received a connected identity in the URI of the From
header field of a mid-dialog request to use that URI in the To header
field of any subsequent mid-dialog request sent by that UA.
In the absence of a suitable Authentication Service on the path of
the mid-dialog request, the UAS will receive an unauthenticated
connected identity (i.e., without a corresponding Identity header
field). The implications of this are discussed in section Section 7
4. Behaviour
4.1. Behaviour of a UA that issues an INVITE request outside the
context of an existing dialog
When issuing an INVITE request, a UA compliant with this
specification MUST include the "from-change" option tag in the
Supported header field.
Elwell Expires April 8, 2007 [Page 5]
Internet-Draft SIP Connected ID October 2006
Note that sending the "from-change" option tag does not guarantee
that connected identity will be received in subsequent requests.
4.2. Behaviour of a UA that receives an INVITE request outside the
context of an existing dialog
After receiving an INVITE request, a UA compliant with this
specification MUST include the "from-change" option tag in the
Supported header field of any dialog-forming response.
Note that sending the "from-change" option tag does not guarantee
that connected identity will be received in the event of a change
of caller.
After an early dialog has been formed (after sending a reliable
provisional response the INVITE request), if the "from-change" option
tag has been received in a Supported header field, the UA MAY issue
an UPDATE request [4] on the same dialog. After a full dialog has
been formed (after sending a 2xx provisional response the INVITE
request), if the "from-change" option tag has been received in a
Supported header field and an UPDATE request has not already been
sent on the early dialog, the UA MUST issue an UPDATE request on the
same dialog. In either case the UPDATE request MUST contain the
callee's (or potential callee's) identity in the URI of the From
header field (or an anonymous identity if anonymity is required).
Note that even if the URI does not differ from that in the To
header field URI of the INVITE request, sending a new request
allows the Authentication Service to assert authentication of this
identity and confirms to the peer UA that the connected identity
is the same as that in the To header field URI of the INVITE
request.
4.3. Behaviour of a UA whose identity changes during an established
INVITE-initiated dialog
If the "from-change" option tag has been received in a Supported
header field during an INVITE-initiated dialog and if the identity
associated with the UA changes (e.g., due to transfer) compared to
that last indicated in the From header field of a request sent by
that UA, the UA MUST issue a request on the same dialog containing
the new identity in the URI of the From header field (or an anonymous
identity if anonymity is required). For this purpose the UA MUST use
the UPDATE method unless for other reasons the re-INVITE method is
being used at the same time.
Elwell Expires April 8, 2007 [Page 6]
Internet-Draft SIP Connected ID October 2006
4.4. General UA behaviour
4.4.1. Sending a mid-dialog request
When sending a mid-dialog request a UA MUST observe the requirements
of RFC 4474 [3] when populating the From header field URI, including
provisions for achieving anonymity.
This will allow an Authentication Service on the path of the mid-
dialog request to insert an Identity header field.
After sending a request with a revised From header field URI (i.e.,
revised compared to the URI sent in the From header field of the
previous request on this dialog or in the To header field of the
received dialog-forming INVITE request if no request has been sent),
the UA MUST be prepared to receive the revised URI in the To header
field of subsequent mid-dialog requests and MUST also continue to be
prepared to receive the old URI at least until a request containing
the revised URI has been received.
After receiving a 2xx response to a request with a revised URI in the
From header field (i.e., revised compared to the URI sent in the From
header field of the previous request on this dialog or in the To
header field of the received dialog-forming INVITE request if no
request has been sent), the UA MUST send the same URI in the From
header field of any future requests on the same dialog, unless the
identity changes again.
The mid-dialog request can be rejected in accordance with RFC 4474 if
the UAS does not accept the connected identity. If the UAC receives
a 428, 436, 437 or 438 response to a mid-dialog request it MUST
behave as specified in [1] for receipt of a 4xx response to a mid-
dialog request.
Note that this involves terminating the dialog. To avoid this, it
is recommended in section Section 4.6 that a Verifier should avoid
sending such responses to mid-dialog requests.
4.4.2. Receiving a mid-dialog request
If a UA receives a mid-dialog request from the peer UA, the UA may
make use of the identity in the From header field URI (e.g., by
indicating to the user). The UA MAY discriminate between signed and
unsigned identities. In the case of a signed identity, the UA SHOULD
invoke a Verifier (see section Section 4.6) if it cannot rely on the
presence of a Verifier on the path of the request.
If a UA receives a mid-dialog request from the peer UA in which the
Elwell Expires April 8, 2007 [Page 7]
Internet-Draft SIP Connected ID October 2006
From header field URI differs from that received in the previous
request on that dialog or that sent in the To header field of the
original INVITE request and if the UA sends a 2xx response, the UA
MUST use this revised URI in the To header field of any future
requests it sends on the same dialog (irrespective of whether the
received identity is supported by a valid signature).
4.5. Authentication Service Behaviour
An Authentication Service MUST behave in accordance with RFC 4474 [3]
when dealing with mid-dialog requests.
Note that RFC 4474 is silent on how to behave if the identity in
the From header field is not one that the UAC is allowed to
assert, and therefore it is a matter for local policy whether to
reject the request or forward it without an Identity header field.
Policy may be different for a mid-dialog request compared with
other requests.
Note that when UAs conform with this specification the
Authentication Service will normally be able to authenticate the
sender of a request as being the entity identified in the From
header field and hence will be able provide a signature for this
identity. This is in contrast to UAs that do not support this
specification, where retargeting and mid-dialog identity changes
can render the From header field inaccurate as a means of
identifying the sender of the request.
4.6. Verifier Behaviour
When dealing with mid-dialog requests, an Authentication Service MUST
behave in accordance with RFC 4474 [3] updated as stated below.
RFC 4474 states that it is a matter of policy whether to reject a
request with a 428 "Use Identity Header" response if there is no
Identity header field in the request. A UA MUST NOT issue a 428
response to a mid-dialog request.
This will allow mid-dialog requests to function in the event that
there is no Authentication Service available.
RFC 4474 mandates that the verifier reject a request by sending a
436, 437 or 438 response in certain circumstances. This document
updates RFC 4474 by making it a matter of local policy whether to
send a 436, 437 or 438 request when the circumstances concerned
arise. Policy may be different for a mid-dialog request compared
with other requests. For mid-dialog requests the policy SHOULD be to
not send a 436, 437 or 438 response. If the Verifier does not send a
Elwell Expires April 8, 2007 [Page 8]
Internet-Draft SIP Connected ID October 2006
436, 437 or 438 response in the circumstances concerned, it MUST
remove the Identity and Identity-Info header fields when forwarding
the request.
This recommendation not to send a 436, 437 or 438 response to a
mid-dialog requests will allow a dialog to survive in the face of
certain conditions, e.g., where the Verifier is unable to
dereference the certificate URL. Since the insertion of an
Identity header field by an Authentication Service is often
outside the control of the UAC, the UAC may have no means of
rectifying the situation reported by a 436, 437 or 438 response.
4.7. Proxy Behaviour
A proxy that record routes during an INVITE request MUST be tolerant
of changes of the From header field URI compared with that in the
initial INVITE request for mid-dialog requests in the same direction
as the INVITE request and MUST be tolerant of changes of the From
header field URI compared with the To header field URI in the initial
INVITE request for mid-dialog requests in the opposite direction. A
proxy that record routes MUST also be tolerant of changes of the To
header field URI in mid dialog requests to reflect changes of the
From header field URI in mid-dialog requests in the opposite
direction.
A proxy that is able to provide an Authentication Service or a
Verifier for mid-dialog requests MUST record route if Supported:
from-change is indicated in the dialog forming request.
5. Examples
In the examples the domain example.com is assumed to have the
following private key rendered in OpenSSL format). The private key
is used by the Authentication Service for generating the signature in
the Identity header field.
Elwell Expires April 8, 2007 [Page 9]
Internet-Draft SIP Connected ID October 2006
-----BEGIN RSA PRIVATE KEY-----
MIICXQIBAAKBgQDPPMBtHVoPkXV+Z6jq1LsgfTELVWpy2BVUffJMPH06LL0cJSQO
aIeVzIojzWtpauB7IylZKlAjB5f429tRuoUiedCwMLKblWAqZt6eHWpCNZJ7lONc
IEwnmh2nAccKk83Lp/VH3tgAS/43DQoX2sndnYh+g8522Pzwg7EGWspzzwIDAQAB
AoGBAK0W3tnEFD7AjVQAnJNXDtx59Aa1Vu2JEXe6oi+OrkFysJjbZJwsLmKtrgtt
PXOU8t2mZpi0wK4hX4tZhntiwGKkUPC3h9Bjp+GerifP341RMyMO+6fPgjqOzUDw
+rPjjMpwD7AkcEcqDgbTrZnWv/QnCSaaF3xkUGfFkLx5OKcRAkEA7UxnsE8XaT30
tP/UUc51gNk2KGKgxQQTHopBcew9yfeCRFhvdL7jpaGatEi5iZwGGQQDVOVHUN1H
0YLpHQjRowJBAN+R2bvA/Nimq464ZgnelEDPqaEAZWaD3kOfhS9+vL7oqES+u5E0
J7kXb7ZkiSVUg9XU/8PxMKx/DAz0dUmOL+UCQH8C9ETUMI2uEbqHbBdVUGNk364C
DFcndSxVh+34KqJdjiYSx6VPPv26X9m7S0OydTkSgs3/4ooPxo8HaMqXm80CQB+r
xbB3UlpOohcBwFK9mTrlMB6Cs9ql66KgwnlL9ukEhHHYozGatdXeoBCyhUsogdSU
6/aSAFcvWEGtj7/vyJECQQCCS1lKgEXoNQPqONalvYhyyMZRXFLdD4gbwRPK1uXK
Ypk3CkfFzOyfjeLcGPxXzq2qzuHzGTDxZ9PAepwX4RSk
-----END RSA PRIVATE KEY-----
5.1. Sending connected identity after answering a call
In this example Carol's UA has been reached by retargeting at the
proxy and thus her identity (AoR) is not equal to that in the To
header field of the received INVITE request (Bob). Carol's UA
conveys Carol's identity in the From header field of an UPDATE
request. The proxy also provides an Authentication Service and
therefore adds Identity and Identity-Info header fields to the UPDATE
request.
Elwell Expires April 8, 2007 [Page 10]
Internet-Draft SIP Connected ID October 2006
Alice's UA PROXY + Carol's UA
Authentication
Service
INVITE(1) INVITE(2)
----------------> ---------------->
200(4) 200(3)
<---------------- <----------------
ACK(5) ACK(6)
----------------> ---------------->
UPDATE(8) UPDATE(7)
<---------------- <----------------
200(9) 200(10)
----------------> ---------------->
INVITE (1):
INVITE sip:Bob@example.com SIP/2.0
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 1 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:03 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Supported: from-change
Contact: <sip:alice@ua1.example.com>
Content-Type: application/sdp
Content-Length: 154
v=0
o=UserA 2890844526 2890844526 IN IP4 ua1.example.com
s=Session SDP
c=IN IP4 ua1.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
INVITE (2):
INVITE sip:Carol@ua2.example.com SIP/2.0
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhds
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8;received=192.0.2.1
Elwell Expires April 8, 2007 [Page 11]
Internet-Draft SIP Connected ID October 2006
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 1 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:03 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Supported: from-change
Contact: <sip:alice@ua1.example.com>
Record-Route: <sip:proxy.example.com;lr>
Identity: "xN6gCHR6KxGM+nyiEM13LcWgAFQD3lkni1DPkwgadxh4BB7G+VwY13uRv5hbCI2VSvKuZ4LYN0JNoe7v8VAzruKMyi4Bi4nUghR/fFGBrpBSjztmfffLTp6SFLxo9XQSVrkm1O4c/4UrKn2ejRz+5BULu9n9kWswzKDNjlYlmmc="
Identity-Info: <https://example.com/example.cer>;alg=rsa-sha1
Content-Type: application/sdp
Content-Length: 154
v=0
o=UserA 2890844526 2890844526 IN IP4 ua1.example.com
s=Session SDP
c=IN IP4 ua1.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
200 (3):
SIP/2.0 200 OK
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhds;received=192.0.2.2
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8;received=192.0.2.1
To: Bob <sip:bob@example.com>;tag=2ge46ab5
From: Alice <sip:alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Supported: from-change
Contact: <sip:carol@ua2.example.com>
Record-Route: <sip:proxy.example.com;lr>
Content-Type: application/sdp
Content-Length: 154
v=0
o=UserB 2890844536 2890844536 IN IP4 ua2.example.com
s=Session SDP
c=IN IP4 ua2.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
200 (4):
Elwell Expires April 8, 2007 [Page 12]
Internet-Draft SIP Connected ID October 2006
SIP/2.0 200 OK
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8;received=192.0.2.1
To: Bob <sip:bob@example.com>;tag=2ge46ab5
From: Alice <sip:alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Supported: from-change
Contact: <sip:carol@ua2.example.com>
Record-Route: <sip:proxy.example.com;lr>
Content-Type: application/sdp
Content-Length: 154
v=0
o=UserB 2890844536 2890844536 IN IP4 ua2.example.com
s=Session SDP
c=IN IP4 ua2.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
ACK (5):
ACK sip:carol@ua2.example.com SIP/2.0
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds9
From: Alice <sip:Alice@example.com>;tag=13adc987
To: Bob <sip:Bob@example.com>;tag=2ge46ab5
Call-ID: 12345600@ua1.example.com
CSeq: 1 ACK
Max-Forwards: 70
Route: <sip:proxy.example.com;lr>
Content-Length: 0
ACK (6):
ACK sip:carol@ua2.example.com SIP/2.0
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhdt
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds9;received=192.0.2.1
From: Alice <sip:Alice@example.com>;tag=13adc987
To: Bob <sip:Bob@example.com>;tag=2ge46ab5
Call-ID: 12345600@ua1.example.com
CSeq: 1 ACK
Max-Forwards: 70
Content-Length: 0
UPDATE (7):
UPDATE sip:Alice@ua1.example.com SIP/2.0
Elwell Expires April 8, 2007 [Page 13]
Internet-Draft SIP Connected ID October 2006
Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bKnashdt1
From: Carol <sip:Carol@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 2 UPDATE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:15 GMT
Route: <sip:proxy.example.com;lr>
Contact: <sip:Carol@ua2.example.com>
Content-Length: 0
Note that the URI in the From header field differs from that in
the To header field in the INVITE request/response. However, the
tag is the same as that in the INVITE response.
Elwell Expires April 8, 2007 [Page 14]
Internet-Draft SIP Connected ID October 2006
UPDATE (8):
UPDATE sip:Alice@ua1.example.com SIP/2.0
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhdu
Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bKnashdt1;received=192.0.2.3
From: Carol <sip:Carol@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 2 UPDATE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:15 GMT
Contact: <sip:Carol@ua2.example.com>
Identity: "g8WJiVEzrbYum+z2lnS3pL+MIhuI439gDiMCHm01fwX5D8Ft5Ib9tewLfBT9mDOUSn6wkPSWVQfqdMF/QBPkpsIIROIi2sJOYBEMXZpNrhJd8/uboXMl9KRujDFQefZlmXV8dwD6XsPnMgcH8jAcaZ5aS04NyfWadIwTnGeuxko="
Identity-Info: <https://example.com/cert>;alg=rsa-sha1
Content-Length: 0
200 (9):
SIP/2.0 200 OK
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhdu;received=192.0.2.2
Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bKnashdt1;received=192.0.2.3
From: Carol <sip:Carol@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 2 UPDATE
Contact: <sip:Alice@ua1.example.com>
Content-Length: 0
200 (10):
SIP/2.0 200 OK
Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bKnashdt1;received=192.0.2.3
From: Carol <sip:Carol@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 2 UPDATE
Contact: <sip:Alice@ua1.example.com>
Content-Length: 0
5.2. Sending revised connected identity during a call
In this example a call is established between Alice and Bob, where
Bob (not shown) lies behind a B2BUA. Bob's identity is conveyed by
an UPDATE request. Then call transfer occurs in the B2BUA, such that
Alice becomes connected to Carol (also not shown), and a re-INVITE
request is issued allowing the session to be renegotiated. The B2BUA
provides the Authentication Service and thus generates the Identity
header field in the re-INVITE request to provide authentication of
Elwell Expires April 8, 2007 [Page 15]
Internet-Draft SIP Connected ID October 2006
Carol's identity.
Elwell Expires April 8, 2007 [Page 16]
Internet-Draft SIP Connected ID October 2006
Alice's UA B2BUA
INVITE(1)
---------------->
200(2)
<----------------
ACK(3)
---------------->
UPDATE(4)
<----------------
200(5)
---------------->
re-INVITE(6)
<----------------
200(7)
---------------->
ACK(8)
<---------------
INVITE (1):
INVITE sip:Bob@example.com SIP/2.0
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 1 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:03 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Supported: from-change
Contact: <sip:alice@ua1.example.com>
Content-Type: application/sdp
Content-Length: 154
v=0
o=UserA 2890844526 2890844526 IN IP4 ua1.example.com
s=Session SDP
c=IN IP4 ua1.example.com
t=0 0
m=audio 49172 RTP/AVP 0
Elwell Expires April 8, 2007 [Page 17]
Internet-Draft SIP Connected ID October 2006
a=rtpmap:0 PCMU/8000
200 (2)
SIP/2.0 200 OK
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8;received=192.0.2.1
To: Bob <sip:bob@example.com>;tag=2ge46ab5
From: Alice <sip:alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Supported: from-change
Contact: <sip:xyz@b2bua.example.com>
Content-Type: application/sdp
Content-Length: 154
v=0
o=UserB 2890844536 2890844536 IN IP4 ua2.example.com
s=Session SDP
c=IN IP4 ua2.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
ACK (3)
ACK sip:xyz@b2bua.example.com SIP/2.0
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds9
From: Alice <sip:Alice@example.com>;tag=13adc987
To: Bob <sip:Bob@example.com>;tag=2ge46ab5
Call-ID: 12345600@ua1.example.com
CSeq: 1 ACK
Max-Forwards: 70
Content-Length: 0
UPDATE (4)
UPDATE sip:alice@ua1.example.com SIP/2.0
Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdt1
From: Bob <sip:Bob@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 2 UPDATE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:12 GMT
Contact: <sip:xyz@b2bua.example.com>
Identity "AQFLSjCDRhO2eXlWmTajk99612hkJii9giDMWki5uT6qc4BrekywOUuObcwZI3qhJReZCN7ybMBNYFZ5yFXWdyet4j3zLNCONU9ma+rs8ZOv0+z/Q3Z5cD26HrmitU+OCKWPLObaxbkGQry9hQxOmwRmlUgSjkeCEjgnc1iQc3E="
Identity-Info: <https://example.com/cert>;alg=rsa-sha1
Elwell Expires April 8, 2007 [Page 18]
Internet-Draft SIP Connected ID October 2006
Content-Length: 0
200 (5)
SIP/2.0 200 OK
Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdt1;received=192.0.2.2
From: Bob <sip:Bob@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 2 UPDATE
Contact: <sip:Alice@ua1.example.com>
Content-Length: 0
re-INVITE (6)
INVITE sip:alice@ua1.example.com SIP/2.0
Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdxy
From: Carol <sip:Carol@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 3 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:03:20 GMT
Contact: <sip:xyz@b2bua.example.com>
Identity: "KCd3YLQHj51SlCQhFMnpQjmP6wHh7JGRO8LsB4v5SGEr/Mwu7j6Gpal8ckVM2vd1zqH/F4WJXYDlB525uuJm/fN3O1A2xsZ9BxRkh4N4U19TL9I2Tok3U3kGg8To/6w1mEXpUQjo3OgNYqOBtawHuZI5nrOVaV3IrbQh1b2KgLo="
Identity-Info: <https://example.com/cert>;alg=rsa-sha1
Content-Length: 0
200 (7)
SIP/2.0 200 OK
Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdxy;received=192.0.2.2
From: Carol <sip:Carol@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 3 INVITE
Contact: <sip:Alice@ua1.example.com>
Content-Length: 154
v=0
o=UserA 2890844526 2890844526 IN IP4 ua1.example.com
s=Session SDP
c=IN IP4 ua1.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
ACK (8)
Elwell Expires April 8, 2007 [Page 19]
Internet-Draft SIP Connected ID October 2006
ACK sip:alice@ua1.example.com SIP/2.0
Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdxz
From: Carol <sip:Carol@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 3 ACK
Max-Forwards: 70
Content-Length: 154
v=0
o=UserC 2890844546 2890844546 IN IP4 ua3.example.com
s=Session SDP
c=IN IP4 ua3.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
6. IANA considerations
This specification registers a new SIP option tag, as per the
guidelines in Section 27.1 of RFC 3261.
Name: from-change
Description: This option tag is used to indicate that a UA supports
changes to URIs in From and To header fields during a dialog.
7. Security considerations
RFC 4474 [3] discusses security considerations relating to the
Identity header field in some detail. Those same considerations
apply when using the Identity header field to authenticate a
connected identity in the From header field URI of a mid-dialog
request.
A received From header field URI in a mid-dialog request for which no
valid Identity header field (or other means of authentication) has
been received either in this request or in an an earlier request on
this dialog cannot be trusted (except in very closed environments)
and should be treated in a similar way to a From header field in a
dialog-initiating request that is not backed up by a valid Identity
header field. However, it is recommended not to reject a mid-dialog
request on the grounds that the Identity header field is missing
(since this would interfere with ongoing operation of the call). The
absence of a valid Identity header field may influence the
Elwell Expires April 8, 2007 [Page 20]
Internet-Draft SIP Connected ID October 2006
information given to the user. A UA can clear the call if policy or
user preference dictates.
A signed connected identity in a mid-dialog request (URI in the From
header field accompanied by a valid Identity header field) provides
information about the peer UA in a dialog. In the case of the UA
that was the UAS in the dialog-forming request, this identity is not
necessarily the same as that in the To header field of the dialog-
forming request. This is because of retargeting during the routing
of the dialog-forming request. A signed connected identity says
nothing about the legitimacy of such retargeting, but merely reflects
the result of that retargeting. History information (RFC 4244 [7])
can provide additional hints as to how the connected user has been
reached.
Likewise, when a signed connected identity indicates a change of
identity during a dialog, it conveys no information about the reason
for such change of identity or its legitimacy.
Use of the sips URI scheme can minimise the chances of attacks in
which inappropriate connected identity information is sent, either at
call establishment time or during a call.
Anonymity may be required by the user of a connected UA. For
anonymity the UA must populate the URI in the From header field of a
mid-dialog request in the way described in RFC 4474 [3].
8. Acknowledgments
Thanks to Francois Audet, Frank Derks, Steffen Fries, Vijay Gurbani,
Cullen Jennings, Paul Kyzivat, Hans Persson, Jon Peterson, Eric
Rescorla, Schida Schubert, Ya-Ching Tan and Dan Wing for providing
valuable comments.
9. References
9.1. 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] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Elwell Expires April 8, 2007 [Page 21]
Internet-Draft SIP Connected ID October 2006
Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006.
[4] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, September 2002.
9.2. Informative References
[5] Peterson, J., "Session Initiation Protocol (SIP) Authenticated
Identity Body (AIB) Format", RFC 3893, September 2004.
[6] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg,
"SIP: Session Initiation Protocol", RFC 2543, March 1999.
[7] Barnes, M., "An Extension to the Session Initiation Protocol
(SIP) for Request History Information", RFC 4244, November 2005.
Appendix A. Existing mechanisms
A.1. Existing mechanisms for conveying identity in the context of a
call
When establishing a call and its session, the SIP From header field
in the INVITE request provides a means for conveying the identity of
the caller (caller identity) from the User Agent Client (UAC) to the
User Agent Server (UAS), thereby allowing the caller identity to be
presented to the callee (or a potential callee prior to the call
being answered). There is no corresponding mechanism specified for
conveying the identity of the callee from the UAS to the UAC, to
allow the callee's identity to be presented to the caller. The
identity of the callee is normally expected to be the identity placed
in the To header field of the INVITE request, but often this
expectation is not met because a different party answers the call,
e.g., because of retargeting.
The identity in the To header field does not change during the
routing of an INVITE request and the same value is reflected back
in the response. Therefore this is of no use for determining the
identity of the callee.
History information [7] gathered during the routing of a request
and returned in the response can provide additional information to
the UAC. However, this does not necessarily indicate the Address
of Record (AoR) of the callee. Also the methods described in
Appendix A.2 for authentication do not apply to history
information, which relies instead on hop-by-hop security and
transitive trust.
Elwell Expires April 8, 2007 [Page 22]
Internet-Draft SIP Connected ID October 2006
The Reply-To header field has its own meaning and cannot be relied
on in all circumstances.
The Contact header field provides a contact URI, which may not
reveal the identity (Address of Record) of the user on whose
behalf the response is sent.
Parties involved in a call can change owing to actions such as call
transfer. If such actions are achieved by issuing a new INVITE
request (with a Replaces header field) between the two User Agents
(UA) that are to be involved in the re-arranged call, the SIP From
header field in the INVITE request can provide identity information
in one direction, but again there is no mechanism for conveying
identity information in the reverse direction.
However, call re-arrangements are not always carried out using a new
INVITE request. Sometimes a Back-to-Back User Agent (B2BUA) performs
call re-arrangements using third party call control (3PCC)
techniques. For example, when call transfer is carried out by a
B2BUA, the transferred UA normally receives only a re-INVITE request
in the context of the original dialog between that UA and the B2BUA.
This forces the UA to re-negotiate the session with the new remote
party, but introduces a need to convey the identity of the new remote
party to the UA. Because there is no new INVITE request (outside the
context of the existing dialog), techniques applicable to new calls
do not apply.
Another case where call re-arrangements are not carried out using a
new INVITE request is where one of the UAs is a gateway to a Public
Switched Telephone Network (PSTN) and a call re-arrangement such as
call transfer has occurred within the PSTN. The gateway then has a
need to convey the identity of the new party within the PSTN to the
remote UA. This needs to be done within the context of the existing
dialog between the gateway and the remote UA. In this case there is
probably no need to re-negotiate the session - the only requirement
is to update the identity information. Again, techniques applicable
to new calls do not apply.
A.2. Existing methods for providing authenticated identity information
Delivery of connected identity is of limited value unless it can be
authenticated. This section explores existing means for
authenticating caller identity and their potential for authenticating
connected identity.
The UAC can falsify the From header field in a request. SIP has
several means of providing cryptographic authentication of a
request's source identity.
Elwell Expires April 8, 2007 [Page 23]
Internet-Draft SIP Connected ID October 2006
One such means for providing authenticated identity in requests is
HTTP-based digest authentication, as specified in [1]. Although a
UAS can require digest authentication, it is not usually feasible
between an arbitrary pair of UAs because of reliance on a shared
secret. To achieve scalability, methods based on public key
cryptography are essential. Similar issues would apply if this were
to be used for connected identity.
Another method, Authenticated Identity Body (AIB) is specified in
[5], and is applicable to responses as well as requests. This
requires a UA to have a private key and associated certificate in
order to sign an identity in a body in the request or response.
Potentially it could be used for connected identity. However, this
has seen little deployment, since the public key infrastructures
needed to support private keys and certificates in every UA are not
generally available.
A third method, SIP Identity, is specified in [3]. For signature
this uses a private key and certificate associated with the domain
indicated in the From header field URI. An Authentication Service
authenticates the UAC by some means, using digest authentication for
example, and then inserts an Identity header field and an Identity-
Info header field in the forwarded request. The Identity header
field contains a signature using the domain's private key and the
Identity-Info header field references the corresponding certificate.
This third method, which avoids the need for private keys and
certificates in UAs, is adopted as the basis for authenticating
connected identity in this document.
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 April 8, 2007 [Page 24]
Internet-Draft SIP Connected ID October 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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 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 April 8, 2007 [Page 25]
| PAFTECH AB 2003-2026 | 2026-04-22 07:48:16 |