One document matched: draft-elwell-sip-connected-identity-00.txt
Internet Engineering Task Force J. Elwell
Internet Draft Siemens
draft-elwell-sip-connected-identity-00.txt
Expires: April 2006 October 2005
Connected Identity in the Session Initiation Protocol (SIP)
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.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
This provides a means of providing a signed connected identity in
SIP. Because of retargeting of a 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 TDM network behind a gateway.
Elwell Expires - April 2006 [Page 1]
Connected Identity in SIP October 2005
Table of Contents
1 Introduction....................................................3
2 Overview of proposed solution...................................4
3 Connected UA behaviour..........................................6
3.1 Connected UA at dialog establishing time......................6
3.2 Identity change during an established dialog..................7
4 Authentication service behaviour................................7
5 Verifier behaviour..............................................9
6 Header syntax..................................................10
7 Examples.......................................................11
7.1 Sending connected identity after answering a call............11
8 IANA considerations............................................12
8.1 Header field names...........................................12
8.2 SIP option tag...............................................12
9 Security Considerations........................................13
10 Acknowledgements..............................................13
11 Author's Addresses............................................13
12 Normative References..........................................14
13 Appendix - Rejected Alternatives (temporary – to be removed)..15
13.1 Changing the From header to reflect connected identity......15
13.2 Conveying the connected identity URI in a body..............15
13.3 Conveying the connected identity URI and the connected identity
signature in the same header field...............................15
13.4 Reuse of the Identity header for signing connected identity.15
13.5 Response identity...........................................16
13.6 Establishment of a new dialog using Replaces................16
Elwell Expires - April 2006 [Page 2]
Connected Identity in SIP October 2005
1 Introduction
An important aspect of the Session Initiation Protocol (SIP) [SIP] is
the ability to convey to a User Agent Server (UAS) as part of a
request an identity associated with the User Agent Client (UAC) that
generated that request. Although the From header performs this
function, this header is generated by the UAC client itself and
therefore can be subject to falsification. SIP has several means of
providing cryptographic authentication of a request’s source
identity.
One such means is digest authentication, as specified in [SIP].
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.
Another method is specified in [AIB]. This requires a UAC to have a
private key and associated certificate in order to sign an
Authenticated Identity Body (AIB) in the request. 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 [Identity]. For signature this uses a
private key and certificate associated with the domain indicated in
the From header URI. 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 contains the corresponding
certificate.
Some have argued that there is a need to provide the UAS’s identity
to the UAC in a response. This reflects the fact that a request can
be retargeted for various reasons before reaching the UAS, and the
UAS identity may differ from that in the To header field of the
request. Since the URI in the To header field of the response must
equal that in the request, the To header field is not suitable for
providing the UAS’s identity. Furthermore, any such identity would
need to be authenticated in some way. [AIB] provides for this, since
the AIB contains a From field, the URI of which identifies the source
of the response, not the source of the request (thus differing from
the From header field of the message itself).
However, there is no equivalent of [Identity] for responses. This
reflects the difficulty in the final proxy challenging the UAS to
Elwell Expires - April 2006 [Page 3]
Connected Identity in SIP October 2005
provide digest authentication, in many circumstances a necessary step
in adding an Identity header or equivalent.
For dialog-forming requests (such as INVITE), the identity of the UAS
is particularly important, since that UA will remain as part of the
dialog until the dialog terminates. The identity of that UA often
differs from that in the To header of the dialog-forming request
owing to retargeting. If the identity is made available to the UAC,
the dialog can be terminated early if the UAS identity is not
acceptable. For requests that are not part of a new or existing
dialog, it can be argued that authenticated UAS identity is less
important since any damage arising from reaching an unacceptable UAS
has already been done.
Furthermore, the identity of a UA involved in a dialog can change
during the course of that dialog. One example is where a UA is a
PSTN/ISDN gateway and transfer occurs within the PSTN/ISDN. It is not
only important to send the identity of the PSTN/ISDN party to the
peer UA on dialog establishment, but also to send an updated identity
if the party changes. A similar situation can arise with B2BUAs that
perform third party call control operations.
This document therefore proposes a solution to the general problem of
connected identity, which is the provision of the identity of the UAS
in a dialog-forming request to the UAC of that request and the
provision of a revised identity to the peer UA if identity changes
during a dialog. In each case the UA whose identity is provided is
known as the connected UA and that UA is known as the connected
identity.
2 Overview of proposed solution
Because of difficulties providing authenticated identity in the
response to a dialog forming request, a request in the reverse
direction is used to provide authenticated identity of the UAS in the
dialog forming request, i.e., the identity of the connected UA.
Likewise, if the identity of either UA changes during the lifetime of
the dialog, the new connected identity can be provided in a request
issued by that UA. In either case the signalling path must pass
through an authentication service acting on behalf of the connected
UA, and therefore the proxy concerned must record-route. Note that
this may involve different authentication services at the two ends of
the dialog.
The URI in the From header field of a request in the backward
direction (opposite direction to the dialog-forming request) is
unsuitable for providing connected identity, since the URI in the
From header field must always be the same as the URI in the To header
field of the dialog-forming request (see 12.2.1.1/[SIP]). Because of
Elwell Expires - April 2006 [Page 4]
Connected Identity in SIP October 2005
retargeting of the dialog-forming request, the connected identity can
differ from the URI in the From header of a request in the reverse
direction. Likewise the URI in the From header of a request in the
forward direction (the same direction as the dialog-forming request)
is unsuitable for providing a changed connected identity, because the
From header field must not change.
Therefore a new Header known as Connected-URI is defined to convey
the connected identity URI. A UA wishing to indicate its connected
identity may include a Connected-URI header field in a request. This
can be any request issued by a UA in the context of an early or
established dialog. An UPDATE request [UPDATE] can be sent for this
purpose if there is no other purpose for sending a request at this
time.
OPEN ISSUE. RFC 3311 talks about circumstances in which an UPDATE
request cannot contain an SDP offer, yet does not explicitly talk
about the use of UPDATE requests without SDP offers. It needs to be
resolved whether an UPDATE request can be used in order to convey
Connected-URI even though no SDP offer needs to be sent at the time.
If the outcome is that an UPDATE request must contain an SDP offer,
then SDP offer will need to be included when sending Connected-URI is
sent.
An authentication service on the path of a request containing a
Connected-URI header field may add a Connected-Identity header field
to sign the request on behalf of the domain part of the URI indicated
in the Connected-URI header field. This is similar to an Identity
header but the signature covers also the Connected-URI header field
and certifies that the UAC has credentials that allow it to register
as a contact for that URI. To ascertain this the authentication
service would normally challenge the UAC to provide digest
authentication, unless TLS is used and the UA has already been
authenticated on that connection, e.g., by means of a certificate
during the TLS handshake or a shared secret used to respond to a
challenge at the application layer. The authentication service also
adds an Identity-Info header to provide information about the
certificate needed to verify the signature.
A proxy that provides an authentication service may also add a
Connected-URI header field if not already present in a request or
replace an existing one.
A UAS receiving a request containing a Connected-URI header field and
a valid Connected-Identity header field may use the connected
identity for any purpose, such as passing to an application or
displaying. A UAS receiving a request containing a Connected-URI
header field but no Connected-Identity header field should either
discard the connected identity or use it with caution.
Elwell Expires - April 2006 [Page 5]
Connected Identity in SIP October 2005
OPEN ISSUE: Should we also consider the possibility of including a
Connected-URI header in a response? An authentication service would
be able to add a Connected-Identity header only if has some means of
authenticating the UAS. It cannot challenge the UAS, so it would have
to rely on other means, e.g., challenging an earlier request on the
same TLS transport).
This document also specifies a new option tag, connectedID, to
indicate support for or requirement for connected identity.
OPEN ISSUE. Is this option tag worthwhile? Use of it a Require header
field to force the sending of a Connected-URI header field in a
reverse request is not particularly secure, since it does not fall
within the signature of the Identity header and could be removed by
an attacker. Also, even if the UAS provides a Connected-URI header
field in a reverse request, there is no guarantee that an
authentication service will be available or be prepared to add a
signature in the form of a Connected-Identity header field.
3 Connected UA behaviour
3.1 Connected UA at dialog establishing time
When a dialog is established, the connected UA is the UA that acts as
UAS for the dialog establishing request and returns a 1xx (not 100)
or 2xx response.
The behaviour below relies on a connected UA knowing its connected
URI, i.e., its AoR. Some UAs register as contacts for multiple AoRs.
Provided a UA has registered a different contact URI for each AoR it
registers for, then it can associate an incoming request with a
particular AoR by examining the Request-URI.
After sending the first reliable response (1xx or 2xx) to a dialog
forming request, a UA MAY send its identity (the connected identity)
if the dialog-forming request contained a Supported header field with
the connectedID option tag and MUST send its connected identity if
the dialog-forming request contained a REQUIRED header field with the
connectedID option tag.
To send its connected identity the UA MUST include a Connected-URI
header field in a mid-dialog request, e.g., an UPDATE request or a
(re-)INVITE request. If there is no other reason to send a mid-dialog
request, the UA SHOULD send an UPDATE request for this specific
purpose. The UA MUST accurately populate the Connected-URI header
field with a value corresponding to an identity that it believes it
is authorized to claim. It MUST set the URI portion of the header to
Elwell Expires - April 2006 [Page 6]
Connected Identity in SIP October 2005
match a SIP, SIPS or TEL URI AoR which it is authorized to use in the
domain (including anonymous URIs, as described in [Privacy]).
Note that [Identity] defines a number of new 4xx response codes, and
these in general are applicable also to connected identity. If a UA
supports these response codes, it will be able to respond
intelligently to Identity-based error conditions.
3.2 Identity change during an established dialog
An identity change can occur at a gateway as a result of action in
the legacy network beyond the gateway, e.g., call transfer. During an
established dialog the gateway can receive updated identity
information from the legacy network that prompts it to adopt a
revised identity within the SIP network. This can apply to either the
UAC or the UAS of the original dialog establishing request.
If during a dialog the identity of a UA changes from that which it
indicated previously in the From header or Connected-URI header of a
request, the UA MAY send its revised identity if it has received from
the peer UA a Supported header field with the connectedID option tag
and MUST send its revised identity if it has received from the peer
UA a Required header field with the connectedID option tag. To send
its revised identity the UA MUST included a Connected-URI header
field in a mid-dialog request as specified in 3.1.
In this case it will frequently be the case that the UA provides its
own authentication service and will therefore add a Connected-
Identity header field too. Authentication is on the basis of trusting
the identity received from the legacy network.
4 Authentication service behaviour
The authentication service described here is an extension to that
described in [Identity] except that it authenticates the connected
identity. As stated in [Identity], the authentication service role
can be instantiated by a proxy server or a user agent. Any entity
that instantiates the authentication service role MUST possess the
private key of a domain certificate, and MUST be capable of
authenticating one or more SIP users that can register in that
domain. Commonly, this role will be instantiated by a proxy server,
since these entities are more likely to have a static hostname, hold
a corresponding certificate, and have access to SIP registrar
capabilities that allow them to authenticate users in their domain.
A proxy wishing to perform the role of authentication service for a
dialog must record-route during dialog establishment, so that mid-
dialog requests pass through it.
Elwell Expires - April 2006 [Page 7]
Connected Identity in SIP October 2005
The behaviour described below applies only to requests containing a
Connected-URI header field received in the context of an early or
established dialog. Otherwise the authentication service behaviour of
[Identity] is applicable (i.e., an Identity header will be added, if
applicable).
A SIP entity that acts as an authentication service MUST add a Date
header field to SIP requests if one is not already present.
Similarly, an authentication service MUST add a Content-Length header
field to SIP requests if one is not already present; this can help
the verifier to double-check that it is hashing exactly as many bytes
of message-body as the authentication service when it verifies the
message.
An entity instantiating the authentication service role performs the
following steps, in order, to generate a Connected-Identity header
for a SIP request:
Step 1: The authentication service MUST extract the identity of the
sender from the request. The authentication service takes this value
from the Connected-URI header field; this AoR will be referred to
here as the 'identity field'. If the identity field contains a SIP
or SIPS URI, the authentication service MUST extract the hostname
portion of the identity field and compare it to the domain(s) for
which it is responsible. If the identity field uses the TEL URI
scheme, the policy of the authentication service determines whether
or not it is responsible for this identity; see Section 12 of
[Identity] for more information. If the authentication service is not
responsible for the identity in question, it SHOULD process and
forward the request normally, but it MUST NOT add a Connected-
Identity header; see below for more information on authentication
service handling of an existing Connected-Identity header.
Step 2: The authentication service MUST determine whether or not the
sender of the request is authorized to claim the identity given in
the connected identity field. In order to do so, the authentication
service MUST first authenticate the sender of the message.
Authentication and authorization considerations are as described in
authentication service behaviour step 2 in [Identity]. If the
authentication service is unable to authorise the connected identity
it MUST reject the request with a 403 response.
Step 3: The authentication service SHOULD ensure that any pre-
existing Date header in the request is accurate, in accordance with
authentication service behaviour step 3 in [Identity].
Step 4: The authentication service MUST form the connected identity
signature and add a Connected-Identity header to the request
containing this signature. After the Connected-Identity header has
Elwell Expires - April 2006 [Page 8]
Connected Identity in SIP October 2005
been added to the request, the authentication service MUST also add
an Identity-Info header. The Identity-Info header contains a URI
from which its certificate can be acquired. Details on the
generation of both of these headers are provided in section 6.
Finally, the authentication service MUST forward the message
normally.
5 Verifier behaviour
This document extends the logical role for SIP entities called a
'verifier', as introduced in [Identity]. When a verifier receives a
SIP request in the context of an early or established dialog and
containing a Connected-Identity header, it may inspect the signature
to verify the identity of the sender of the message. Typically, the
results of a verification are provided as input to an authorization
process which is outside the scope of this document. If neither an
Identity header field nor a Connected-Identity header field is
present in a request, and one is required by local policy (for
example, based on a per-sending-domain policy, or a per-sending-user
policy), then a 428 'Use Identity Header' response MUST be sent,
which should be interpreted in this case as 'Use Identity header or
Connected-Identity header, as appropriate'.
In order to verify the identity of the sender of a message containing
a Connected-Identity header field together with Connected-URI and
Identity-Info header fields, an entity acting as a verifier MUST
perform the following steps, in the order here specified.
Step 1: The verifier MUST acquire the certificate for the signing
domain as described in verifier behaviour step 1 in [Identity].
Step 2: The verifier MUST compare the identity of the signer with the
domain portion of the URI in the Connected-URI header field using the
method described in verifier behaviour step 2 of [Identity].
Step 3: The verifier MUST verify the signature in the Connected-
Identity header field, following the procedures for generating the
hashed digest- string described in Section 6. If a verifier
determines that the signature on the message does not correspond to
the reconstructed digest-string, then a 428 'Invalid Identity Header'
response MUST be returned.
Step 4: The verifier MUST validate the Date, Contact and Call-ID
headers the manner described in Section 14.1 of [IDENTITY];
recipients that wish to verify Connected-Identity signatures MUST
support all of the operations described there.
Elwell Expires - April 2006 [Page 9]
Connected Identity in SIP October 2005
The verifier function is normally located at the UAS of a mid-dialog
request. The UA SHOULD render the connected identity and its validity
to the user through an appropriate user interface or to an
application. A UA MAY also make use of a Connected-URI header field
that is not accompanied by a Connected-Identity header field, i.e.,
an unsigned connected identity, in which case the UA SHOULD
distinguish unsigned connected identities from signed connected
identities when rendering the information to a user or application.
In order to have the possibility of receiving connected identity, a
UA MUST include the connectedID option tag in a Supported or Required
header field in a SIP message towards the peer UA, e.g., in the
dialog-forming request. Use of this option tag in a Required header
will cause the request to fail if connected identity is not supported
and will cause the Connected-URI to be returned in a request in the
reverse direction if connected identity is supported at the UAS.
However, although the return of a Connected-URI header can be forced
using this mechanism, this does not guarantee that it will be
accompanied by a Connected-Identity header field, which will depend
on the presence of an authentication service on the path and the
ability of the authentication service to authenticate the sender.
6 Header syntax
This document specifies two new SIP headers: Connected-URI and
Connected-Identity. Each of these headers can appear only once in a
SIP message. The grammar for these two headers is:
Connected-URI = "Connected-URI" HCOLON ( name-addr / addr-spec )
Connected-Identity = "Identity" HCOLON signed-connected-id-digest
signed-connected-id-digest = LDQUOT 32LHEX RDQUOT
The signed-connected-id-digest is a signed hash of a canonical string
generated from certain components of a SIP request. It is identical
to signed-identity-digest in [Identity] except that in the canonical
string instead of the addr-spec of the From header field the addr-
spec of the Connected-URI header field MUST be used.
This document adds the following entries to Table 2 of [SIP]:
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
Connected-URI R r o o - o o -
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
- o o o o o
Elwell Expires - April 2006 [Page 10]
Connected Identity in SIP October 2005
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
Connected-Identity R a o o - o o -
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
- o o o o o
Note, in the table above, only methods that can be used in the
context of an early or established dialog are applicable. The CANCEL
method is excluded for reasons given in [Identity].
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 places a Connected-URI header field in an UPDATE request.
The proxy also provides an authentication service and therefore adds
a Connected-Identity header field and an Identity-Info header field
to the UPDATE request.
Alice's UA PROXY Carol's UA
INVITE (1) INVITE(2)
----------------> ---------------->
200 (3) 200 (3)
<---------------- <----------------
ACK(5) ACK(6)
----------------> ---------------->
UPDATE (8) UPDATE (7)
<---------------- <----------------
200 (9) 200 (10)
----------------> ---------------->
INVITE (1) and INVITE (2)
These include either:
Require: connectedID
or
Supported: connectedID
Elwell Expires - April 2006 [Page 11]
Connected Identity in SIP October 2005
UPDATE (7)
UPDATE sip:ua1@example.com SIP/2.0
From: <sip:Bob@example.com>;tag=2
To: <sip:Alice@example.com>;tag=3
Call-ID: 12345600@example.com
CSeq: 1 UPDATE
Connected-URI: <sip:Carol@example.com>
UPDATE (8)
UPDATE sip:ua1@example.com SIP/2.0
From: <sip:Bob@example.com>;tag=2
To: <sip:Alice@example.com>;tag=3
Call-ID: 12345600@example.com
CSeq: 1 UPDATE
Connected-URI: <sip:Carol@example.com>
Conncected-Identity: "dKJ97..."
Identity-Info: <https://example.com/cert>;alg=rsa-sha1
8 IANA considerations
This document requests changes to the header fields and option tags
registries within the SIP parameters IANA registry.
8.1 Header field names
This document specifies two new SIP headers: Connected-URI and
Connected-Identity. Their syntax is given in section 6. These
headers are defined by the following information, which is to be
added to the header sub-registry under
http://www.iana.org/assignments/sip-parameters.
Header Name: Connected-URI
Compact Form: N/A
Header Name: Connected-Identity
Compact Form: N/A
8.2 SIP option tag
This specification registers a new SIP option tag, as per the
guidelines in Section 27.1 of RFC 3261.
Name: connectedID
Description: This option tag is used to identify connected identity
and the Connected-URI and Connected-Identity header fields. When used
in a Supported header, it indicates support for receiving these
header fields and acts as a request to provide this information. When
used in a Required header it indicates that the request concerned
should be rejected if connected identity information cannot be
provided.
Elwell Expires - April 2006 [Page 12]
Connected Identity in SIP October 2005
9 Security Considerations
[Identity] discusses security considerations relating to the Identity
header in some detail. Essentially those same considerations apply to
the Connected-Identity header.
A received Connected-URI header field that is not accompanied by a
valid Connected-Identity header field cannot be trusted (except in
very closed environments) and should be treated in a similar way to a
From header field that is not backed up by a valid Identity header
field.
A signed connected identity (Connected-URI header field accompanied
by a valid Connected-Identity 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 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 of its legitimacy.
Privacy may be required by the user of a connected UA. To achieve
privacy the UA MUST either decline to send the Connected-URI header
field or populate it in the way described in [IDENTITY] for the From
header field when anonymity is required. Note that if a Require
header field has been received with the connectedID option tag,
accepting the request but declining to send the Connected-URI header
field is not an option, and therefore the UA MUST either decline the
request or populate the Connected-URI header field anonymously.
10 Acknowledgements
Thanks to Francois Audet, Frank Derks, Steffen Fries and Jon Peterson
for providing valuable comments.
11 Author's Addresses
John Elwell
Siemens Communications
Technology Drive
Beeston
Nottingham, UK, NG9 1LA
email: john.elwell@siemens.com
Elwell Expires - April 2006 [Page 13]
Connected Identity in SIP October 2005
12 Normative References
[SIP] J. Rosenberg, H. Schulzrinne, et al., "SIP: Session initiation
protocol", RFC 3261.
[AIB]J. Peterson, "Session Initiation Protocol (SIP) Authenticated
Identity Body (AIB) Format", RFC 3893.
[Identity] J. Peterson, C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)", draft-
ietf-sip-identity-05 (work in progress).
[Privacy] J. Peterson, "A Privacy Mechanism for the Session
Initiation Protocol (SIP)", RFC 3323.
[UPDATE] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE
method", RFC 3311.
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 IETF's procedures with respect to rights in IETF 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,
Elwell Expires - April 2006 [Page 14]
Connected Identity in SIP October 2005
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 (2005).
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
13 Appendix - Rejected Alternatives (temporary – to be removed)
The following alternative solutions were considered and rejected.
13.1 Changing the From header to reflect connected identity
[SIP] disallows any change to the From and To header fields during
the course of a dialog, since these header fields (along with the
Call-Id header field) provide unique identification for a dialog.
Although the tag parameters in the From and To header fields are in
fact sufficient for dialog identification purposes, for backward
compatibility with RFC 2543 changes to the URIs in these header
fields are prohibited. It is probable that [SIP]-compliant
implementations may break if a URI changes during a dialog. The
community has already rejected this approach.
13.2 Conveying the connected identity URI in a body
This might have the advantage that the existing Identity header could
be used, but this is contrary to the semantics of the Identity
header.
13.3 Conveying the connected identity URI and the connected identity
signature in the same header field.
This has the minor disadvantage that the syntax of the header field
would differ from that of the Identity header field.
13.4 Reuse of the Identity header for signing connected identity
Elwell Expires - April 2006 [Page 15]
Connected Identity in SIP October 2005
The signature in the Identity header basically authenticates the
identity in the From header and would not be able to authenticate a
different identity (e.g., in a Connected-URI header).
13.5 Response identity
Although the proposed solution can under some circumstances provide
connected identity in a response, a general solution to response
identity is not possible because of the inability to challenge a
response to obtain authentication.
13.6 Establishment of a new dialog using Replaces
The UA wishing to convey its identity and being unable to do so in
the From header field of a request on the existing INVITE-initiated
dialog could send a new INVITE request containing a Replaces header
field indicating replacement of the existing dialog at the UAS. The
From header field of that request would contain the correct identity
and could be signed by means of an Identity header in the normal way.
There is no normative specification at present covering the fate of
the existing session when an existing INVITE-initiated dialog is
replaced by a new dialog between the same two UAs. It would be
undesirable to interrupt an ongoing session just because the dialog
needs to be replaced, particularly if this means the calculation of
new security keys for media.
The Replaces header is not defined for use in a SUBSCRIBE request, so
this technique would not be applicable to SUBSCRIBE-initiated
dialogs. It is not clear whether this would matter.
This technique would be unsuitable for use on an early dialog, since
the replaced dialog might by-pass any proxy that was supervising the
early dialog and might wish to cancel it under certain circumstances
or take account of any non 2xx final response.
This technique would involve additional SIP messages (5, including
the BYE request and response on the replaced dialog, rather than 2).
Elwell Expires - April 2006 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-24 06:55:44 |