SIP WG J. Elwell
Internet-Draft Siemens plc
Expires: October 26, 2006 April 24, 2006
Connected Identity in the Session Initiation Protocol (SIP)
draft-ietf-sip-connected-identity-00.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 October 26, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Because of retargeting of a Session Initiation Protocol (SIP) dialog-
forming request, the UAS can have a different identity from that in
the To header. This document provides a means for that 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 used to indicate a change of
identity during a dialog, e.g., because of some action in a PSTN
behind a gateway. This document normatively updates RFC 3261 (SIP).
Elwell Expires October 26, 2006 [Page 1]
Internet-Draft SIP Connected ID April 2006
This work is being discussed on the sip@ietf.org mailing list.
Table of Contents
1. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Existing mechanisms for conveying identity in the context
of a call . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Existing methods for providing authenticated identity
information . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Overview of solution . . . . . . . . . . . . . . . . . . . . . 5
6. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Behaviour of a UA that issues an INVITE request
outside the context of an existing dialog . . . . . . . . 6
6.2. Behaviour of a UA that receives an INVITE request
outside the context of an existing dialog . . . . . . . . 6
6.3. Behaviour of a UA whose identity changes during an
established INVITE-initiated dialog . . . . . . . . . . . 7
6.4. General UA behaviour . . . . . . . . . . . . . . . . . . . 7
6.5. Authentication Service Behaviour . . . . . . . . . . . . . 8
6.6. Proxy Behaviour . . . . . . . . . . . . . . . . . . . . . 8
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Sending connected identity after answering a call . . . . 9
7.2. Sending revised connected identity during a call . . . . . 12
8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Security considerations . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20
Elwell Expires October 26, 2006 [Page 2]
Internet-Draft SIP Connected ID April 2006
1. Conventions and Definitions
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 [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 in either direction within
the context of an existing INVITE-initiated dialog.
The provision of the identity of the responder in a response
("response identity") for requests outside the context of an INVITE-
initiated dialog is outside the scope of this document.
3. 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 from the User Agent Client (UAC) to the User Agent Server
(UAS), thereby allowing the caller's identity to be presented to the
callee. 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 call
forwarding.
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 clearly indicate the
AoR of the UAS. Also the methods described in Section 4 for
authentication do not apply to history information, which relies
instead on hop-by-hop security and transitive trust.
Elwell Expires October 26, 2006 [Page 3]
Internet-Draft SIP Connected ID April 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 UAs 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 B2BUA performs call re-arrangements
using third party call control (3PCC) techniques. With such
techniques the UA involved in the original call and still involved in
the re-arranged call receives only a re-INVITE or UPDATE 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 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 not even any need to re-negotiate
the session - the only requirement is to update the identity
information.
4. Existing methods for providing authenticated identity information
Because the From header field in a request is generated by the UAC
itself it can be subject to falsification. SIP has several means of
providing cryptographic authentication of a request's source
identity.
One such means for 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
Elwell Expires October 26, 2006 [Page 4]
Internet-Draft SIP Connected ID April 2006
based on public key cryptography are essential.
Another method 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 Authenticated Identity
Body (AIB) in the request or response. 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 is specified in [3]. For signature this uses a
private key and certificate associated with the domain indicated in
the From header URI. An Authentication Service, typically located at
the outbound proxy, authenticates the UAC by some means, using digest
authentication for example, and then inserts an Identity header and
an Identity-Info header in the forwarded request. The Identity
header contains a signature using the domain's private key and the
Identity-Info header references the corresponding certificate.
5. 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 can be used to provide
authentication.
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
alerting or answering party. A request in the same direction as the
INVITE request prior to answer can indicate a change of calling
party. A request in either direction after answer can indicate a
change of party. In all cases a dialog (early or confirmed) must be
established before such a request can be sent.
Note that it might also be possible to provide a means of
indicating the identity of the alerting or answering party in the
response to the INVITE request. However, at present the problem
of authenticating a response is still subject to study. In the
absence of a solution to this problem, the simple solution of
using a request in the opposite direction to the INVITE request is
sufficient. Furthermore a Globally Routable User agent URI (GRUU)
[8], if used in the Contact header field in a dialog-forming
response to an INVITE request, can reveal the identity of the
connected user (subject to there being no need for anonymity and
subject to policy for allocating GRUUs), but this does not deal
with the problem of a connected identity changing mid-dialog.
Elwell Expires October 26, 2006 [Page 5]
Internet-Draft SIP Connected ID April 2006
This solution involves changing the URI (not the tags) in the To and
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.
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 "id-change" is introduced for providing a
positive indication of support in the Supported header field.
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.
OPEN ISSUE. Should this be extended to allow a URI in the To
header field of a response to change compared with the To header
field in a request? This could convey a connected identity in a
response to an INVITE request, but it would not be authenticated.
Authentication would have to rely on transitive trust, which might
be feasible in a closed environment where the sips URI scheme is
used.
6. Behaviour
6.1. Behaviour of a UA that issues an INVITE request outside the
context of an existing dialog
When issuing an INVITE request, a UA that supports changes of URI in
the From and To headers during a dialog MUST include the id-change
option tag in the Supported header field.
6.2. Behaviour of a UA that receives an INVITE request outside the
context of an existing dialog
After receiving an INVITE request, a UA that supports changes of URI
Elwell Expires October 26, 2006 [Page 6]
Internet-Draft SIP Connected ID April 2006
in the From and To headers during a dialog MUST include the id-change
option tag in the Supported header field of any dialog-forming
response.
After a dialog has been formed (after sending a reliable response to
the INVITE request, i.e., a 2xx response or a reliable 1xx response),
if the id-change option tag has been received in a Supported header
field, the UA MUST issue a request on the same dialog containing its
identity in the URI of the From header field (or an anonymous
identity if anonymity is required). For this purpose the UPDATE
method [4] MUST be used if supported by the peer UA. If the UPDATE
method is not supported by the peer UA, the re-INVITE method MUST be
used, but this will necessitate waiting until the dialog is
confirmed.
OPEN ISSUE: If the identity has has not changed compared with the
URI in the To header field and the UAC (for the INVITE request)
does not support verification of an Identity header, this UPDATE
or re-INVITE transaction would fulfil no useful purpose. However,
the UAS (for the INVITE transaction) does not know this. In order
to save this round trip, should we have an additional option tag
to indicate support for receipt of the Identity header on mid-
dialog requests? Then if this option tag is not present in the
INVITE request the additional transaction could be omitted. Note
that the id-change option tag does not seem appropriate for this
purpose, since a UA could support a change of URI without
supporting Identity.
6.3. Behaviour of a UA whose identity changes during an established
INVITE-initiated dialog
If the id-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 SHOULD 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
either the UPDATE method or the re-INVITE method. However the UPDATE
method cannot be used before a reliable provisional response to the
dialog-forming INVITE request has been sent or received and the re-
INVITE method cannot be used until the dialog is confirmed.
6.4. General UA behaviour
When sending a mid-dialog request a URI MUST observe the requirements
of [3] when populating the From header field URI, including
provisions for achieving anonymity.
Elwell Expires October 26, 2006 [Page 7]
Internet-Draft SIP Connected ID April 2006
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 old URI in the To header field
of a received mid-dialog request at least until a 2xx response to the
request with the revised From header field 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.
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 act in accordance with [3] and
verify any signature in the Identity header field and discriminate
between signed and unsigned identities.
If a UA receives a mid-dialog request from the peer UA in which the
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).
6.5. Authentication Service Behaviour
An Authentication Service MUST behave in accordance with [3] when
dealing with mid-dialog requests.
OPEN ISSUE. draft-ietf-sip-identity is silent on how to behave if
the identity in the From header is not one that authenticated UA
is allowed to assert. Should the request be allowed to proceed
without the Identity header or should it be rejected, if so with
which response code?
6.6. 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
Elwell Expires October 26, 2006 [Page 8]
Internet-Draft SIP Connected ID April 2006
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.
7. Examples
7.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
therefore conveys its 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 field to the UPDATE
request.
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
From: <sip:Alice@example.com>;tag=13adc987
To: <sip:Bob@example.com>
Call-ID: 12345600@example.com
CSeq: 1 INVITE
Supported: id-change
Contact: <sip:Alice@ua1.example.com>
Elwell Expires October 26, 2006 [Page 9]
Internet-Draft SIP Connected ID April 2006
etc.
INVITE (2):
INVITE sip:Carol@ua2.example.com SIP/2.0
From: <sip:Alice@example.com>;tag=13adc987
To: <sip:Bob@example.com>
Call-ID: 12345600@example.com
CSeq: 1 INVITE
Supported: id-change
Contact: <sip:Alice@ua1.example.com>
Identity: "dKJ97..."
Identity-Info: <https://example.com/cert>;alg=rsa-sha1
etc.
200 (3):
SIP/2.0 200 OK
From: <sip:Alice@example.com>;tag=13adc987
To: <sip:Bob@example.com>;tag=2ge46ab5
Call-ID: 12345600@example.com
CSeq: 1 INVITE
Supported: id-change
Contact: <sip:Carol@ua2.example.com>
etc.
200 (4):
SIP/2.0 200 OK
From: <sip:Alice@example.com>;tag=13adc987
To: <sip:Bob@example.com>;tag=2ge46ab5
Call-ID: 12345600@example.com
CSeq: 1 INVITE
Supported: id-change
Contact: <sip:Carol@ua2.example.com>
etc.
ACK (5):
ACK sip:Bob@example.com SIP/2.0
From: <sip:Alice@example.com>;tag=13adc987
To: <sip:Bob@example.com>;tag=2ge46ab5
Call-ID: 12345600@example.com
CSeq: 1 ACK
etc.
ACK (6):
Elwell Expires October 26, 2006 [Page 10]
Internet-Draft SIP Connected ID April 2006
ACK sip:Carol@ua2.example.com SIP/2.0
From: <sip:Alice@example.com>;tag=13adc987
To: <sip:Bob@example.com>;tag=2ge46ab5
Call-ID: 12345600@example.com
CSeq: 1 ACK
etc.
UPDATE (7):
UPDATE sip:Alice@ua1.example.com SIP/2.0
From: <sip:Carol@example.com>;tag=2ge46ab5
To: <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@example.com
CSeq: 2 UPDATE
Contact: <sip:Carol@ua2.example.com>
etc.
Note that the URI in the From header differs from that in the To
header in the INVITE request/response. However, the tag is the
same as that in the INVITE response.
Elwell Expires October 26, 2006 [Page 11]
Internet-Draft SIP Connected ID April 2006
UPDATE (8):
UPDATE sip:Alice@ua1.example.com SIP/2.0
From: <sip:Carol@example.com>;tag=2ge46ab5
To: <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@example.com
CSeq: 2 UPDATE
Contact: <sip:Carol@ua2.example.com>
Identity: "cdKJH43..."
Identity-Info: <https://example.com/cert>;alg=rsa-sha1
etc.
200 (9):
SIP/2.0 200 OK
From: <sip:Carol@example.com>;tag=2ge46ab5
To: <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@example.com
CSeq: 2 UPDATE
Contact: <sip:Alice@ua1.example.com>
etc.
200 (10):
SIP/2.0 200 OK
From: <sip:Carol@example.com>;tag=2ge46ab5
To: <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@example.com
CSeq: 2 UPDATE
Contact: <sip:Alice@ua1.example.com>
etc.
7.2. Sending revised connected identity during a call
In this example a call is established between Alice and Bob, where
Bob lies behind a B2BUA or gateway to a PSTN. Bob's identity is
conveyed by an UPDATE request. Then call transfer occurs in the
B2BUA or PSTN, such that Alice becomes connected to Carol, and a re-
INVITE request is issued allowing the session to be renegotiated.
The B2BUA (or an entity behind it) or the gateway provides the
Authentication Service and thus generates the Identity header in the
re-INVITE request to provide authentication of Carol's identity.
Alice's UA PROXY B2BUA or gateway
+ Authentication
Service
Elwell Expires October 26, 2006 [Page 12]
Internet-Draft SIP Connected ID April 2006
INVITE(1) INVITE(2)
----------------> ---------------->
200(4) 200(3)
<---------------- <----------------
ACK(5) ACK(6)
----------------> ---------------->
UPDATE(8) UPDATE(7)
<---------------- <----------------
200(9) 200(10)
----------------> ---------------->
re-INVITE(12) re-INVITE(11)
<---------------- <----------------
200(13) 200(14)
----------------> ---------------->
ACK(16) ACK(15)
<--------------- <----------------
INVITE (1):
INVITE sip:Bob@example.com SIP/2.0
From: <sip:Alice@example.com>;tag=13adc987
To: <sip:Bob@example.com>
Call-ID: 12345600@example.com
CSeq: 1 INVITE
Supported: id-change
Contact: <sip:Alice@ua1.example.com>
etc.
INVITE (2):
INVITE sip:Bob@example.com SIP/2.0
From: <sip:Alice@example.com>;tag=13adc987
To: <sip:Bob@example.com>
Call-ID: 12345600@example.com
CSeq: 1 INVITE
Supported: id-change
Contact: <sip:Alice@ua1.example.com>
Identity: "dKJ97..."
Identity-Info: <https://example.com/cert>;alg=rsa-sha1
etc.
Elwell Expires October 26, 2006 [Page 13]
Internet-Draft SIP Connected ID April 2006
200 (3):
SIP/2.0 200 OK
From: <sip:Alice@example.com>;tag=13adc987
To: <sip:Bob@example.com>;tag=2ge46ab5
Call-ID: 12345600@example.com
CSeq: 1 INVITE
Supported: id-change
Contact: <sip:Bob@ua2.example.com>
etc.
200 (4):
SIP/2.0 200 OK
From: <sip:Alice@example.com>;tag=13adc987
To: <sip:Bob@example.com>;tag=2ge46ab5
Call-ID: 12345600@example.com
CSeq: 1 INVITE
Supported: id-change
Contact: <sip:Bob@ua2.example.com>
etc.
ACK (5):
ACK sip:Bob@example.com SIP/2.0
From: <sip:Alice@example.com>;tag=13adc987
To: <sip:Bob@example.com>;tag=2ge46ab5
Call-ID: 12345600@example.com
CSeq: 1 ACK
etc.
ACK (6):
ACK sip:Bob@example.com SIP/2.0
From: <sip:Alice@example.com>;tag=13adc987
To: <sip:Bob@example.com>;tag=2ge46ab5
Call-ID: 12345600@example.com
CSeq: 1 ACK
etc.
UPDATE (7):
UPDATE sip:Alice@ua1.example.com SIP/2.0
From: <sip:Bob@example.com>;tag=2ge46ab5
To: <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@example.com
CSeq: 2 UPDATE
Contact: <sip:Bob@ua2.example.com>
Elwell Expires October 26, 2006 [Page 14]
Internet-Draft SIP Connected ID April 2006
Identity: "cdKJH43..."
Identity-Info: <https://example.com/cert>;alg=rsa-sha1
etc.
UPDATE (8):
UPDATE sip:Alice@ua1.example.com SIP/2.0
From: <sip:Bob@example.com>;tag=2ge46ab5
To: <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@example.com
CSeq: 2 UPDATE
Contact: <sip:Bob@ua2.example.com>
Identity: "cdKJH43..."
Identity-Info: <https://example.com/cert>;alg=rsa-sha1
etc.
200 (9):
SIP/2.0 200 OK
From: <sip:Bob@example.com>;tag=2ge46ab5
To: <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@example.com
CSeq: 2 UPDATE
Contact: <sip:Alice@ua1.example.com>
etc.
200 (10):
SIP/2.0 200 OK
From: <sip:Bob@example.com>;tag=2ge46ab5
To: <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@example.com
CSeq: 2 UPDATE
Contact: <sip:Alice@ua1.example.com>
etc.
re-INVITE (11):
INVITE sip:Alice@ua1.example.com SIP/2.0
From: <sip:Carol@example.com>;tag=2ge46ab5
To: <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@example.com
CSeq: 3 INVITE
Contact: <sip:Carol@ua3.example.com>
Identity: "ecdFG24..."
Identity-Info: <https://example.com/cert>;alg=rsa-sha1
etc.
Elwell Expires October 26, 2006 [Page 15]
Internet-Draft SIP Connected ID April 2006
re-INVITE (12):
INVITE sip:Alice@ua1.example.com SIP/2.0
From: <sip:Carol@example.com>;tag=2ge46ab5
To: <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@example.com
CSeq: 3 INVITE
Contact: <sip:Carol@ua3.example.com>
Identity: "ecdFG24..."
Identity-Info: <https://example.com/cert>;alg=rsa-sha1
etc.
200 (13):
SIP/2.0 200 OK
From: <sip:Carol@example.com>;tag=2ge46ab5
To: <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@example.com
CSeq: 3 INVITE
Contact: <sip:Alice@ua1.example.com>
etc.
200 (14):
SIP/2.0 200 OK
From: <sip:Carol@example.com>;tag=2ge46ab5
To: <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@example.com
CSeq: 3 INVITE
Contact: <sip:Alice@ua1.example.com>
etc.
ACK (15):
ACK sip:Alice@ua1.example.com SIP/2.0
From: <sip:Carol@example.com>;tag=2ge46ab5
To: <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@example.com
CSeq: 3 ACK
etc.
ACK (16):
ACK sip:Alice@ua1.example.com SIP/2.0
From: <sip:Carol@example.com>;tag=2ge46ab5
To: <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@example.com
CSeq: 3 ACK
Elwell Expires October 26, 2006 [Page 16]
Internet-Draft SIP Connected ID April 2006
etc.
8. IANA considerations
This specification registers a new SIP option tag, as per the
guidelines in Section 27.1 of RFC 3261.
Name: id-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.
9. Security considerations
[3] discusses security considerations relating to the Identity header
in some detail. Those same considerations apply when using the
Identity header to authenticate a connected identity in the From
header URI of a mid-dialog request.
A received From header URI in a mid-dialog request for which no valid
Identity header field (or other means of authentication) has been
receivd 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.
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.
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. To
Elwell Expires October 26, 2006 [Page 17]
Internet-Draft SIP Connected ID April 2006
anonymity the UA must populate the URI in the From header field of a
mid-dialog request in the way described in [3].
10. Acknowledgments
Thanks to Francois Audet, Frank Derks, Steffen Fries, Vijay Gurbani,
Cullen Jennings, Hans Persson, Jon Peterson, Schida Schubert and Ya-
Ching Tan for providing valuable comments.
11. References
11.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
Identity Management in the Session Initiation Protocol (SIP)",
draft-ietf-sip-identity-06 (work in progress), October 2005.
[4] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, September 2002.
11.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.
[8] Rosenberg, J., "Obtaining and Using Globally Routable User Agent
(UA) URIs (GRUU) in the Session Initiation Protocol (SIP)",
draft-ietf-sip-gruu-07 (work in progress), March 2006.
Elwell Expires October 26, 2006 [Page 18]
Internet-Draft SIP Connected ID April 2006
Author's Address
John Elwell
Siemens plc
Technology Drive
Beeston, Nottingham NG9 1LA
UK
Phone: +44 115 943 4989
Email: john.elwell@siemens.com
Elwell Expires October 26, 2006 [Page 19]
Internet-Draft SIP Connected ID April 2006
Intellectual Property Statement
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.
Disclaimer of Validity
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.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Elwell Expires October 26, 2006 [Page 20]
