draft-ietf-sip-identity-01.txt   draft-ietf-sip-identity-02.txt 
SIP WG J. Peterson SIP WG J. Peterson
Internet-Draft NeuStar Internet-Draft NeuStar
Expires: August 2, 2003 February 2003 Expires: November 15, 2004 C. Jennings
Cisco Systems
May 17, 2004
Enhancements for Authenticated Identity Management in the Session Enhancements for Authenticated Identity Management in the Session
Initiation Protocol (SIP) Initiation Protocol (SIP)
draft-ietf-sip-identity-01 draft-ietf-sip-identity-02
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 2, 2003. This Internet-Draft will expire on November 15, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
The existing mechanisms for expressing identity in the Session The existing security mechanisms in the Session Initiation Protocol
Initiation Protocol oftentimes do not permit an administrative domain are inadequate for cryptographically assuring the identity of the end
to verify securely the identity of the originator of a request. This users that originate SIP requests and responses, especially in an
document recommends practices and conventions for authenticating end interdomain context. This document recommends practices and
users, and proposes a way to distribute cryptographically secure conventions for identifying end users in SIP messages, and proposes a
authenticated identities within SIP messages. way to distribute cryptographically secure authenticated identities.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Using an Authentication Service . . . . . . . . . . . . . . . 5 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. How to Share Verified Identities . . . . . . . . . . . . . . . 5 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1 Body Added by Client . . . . . . . . . . . . . . . . . . . . . 7 5. Overview of Operations . . . . . . . . . . . . . . . . . . . . 6
4.2 Body Added by Authentication Service . . . . . . . . . . . . . 8 6. User Agent Behavior: Sending Messages . . . . . . . . . . . . 7
4.3 Using Content Indirection . . . . . . . . . . . . . . . . . . 8 7. Authentication Service Behavior . . . . . . . . . . . . . . . 7
5. Identity in Responses . . . . . . . . . . . . . . . . . . . . 9 7.1 UAs acting as an Authentication service . . . . . . . . . . . 9
6. Receiving an Authentication Token . . . . . . . . . . . . . . 10 8. Verifying Identity . . . . . . . . . . . . . . . . . . . . . . 9
6.1 Authentication Service Handling of Authentication Tokens . . . 10 9. Proxy Server Behavior . . . . . . . . . . . . . . . . . . . . 10
7. Selective Sharing of Identity . . . . . . . . . . . . . . . . 10 10. Header Syntax . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1 Requesting Privacy . . . . . . . . . . . . . . . . . . . . . . 11 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 Normative References . . . . . . . . . . . . . . . . . . . . . 16
Normative References . . . . . . . . . . . . . . . . . . . . . 13 Informative References . . . . . . . . . . . . . . . . . . . . 16
Informative References . . . . . . . . . . . . . . . . . . . . 13 B. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 17
B. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 19
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
This document provides enhancements to the existing mechanisms for This document provides enhancements to the existing mechanisms for
authenticated identity management in the Session Initiation Protocol authenticated identity management in the Session Initiation Protocol
(SIP [1]). An identity, for the purposes of this document, is (SIP [1]). An identity, for the purposes of this document, is
defined as a canonical SIP URI employed to reach a user (such as defined as a canonical SIP address-of-record URI employed to reach a
'sip:alice@atlanta.com'). user (such as 'sip:alice@atlanta.com').
RFC3261 enumerates a number of places within a SIP request that a RFC3261 enumerates a number of places within a SIP request that a
user can express an identity for themselves, notably the From header user can express an identity for themselves, notably the user-
field. However, the recipient of a SIP request has no way to verify populated From header field. However, the recipient of a SIP request
that the From header field has been populated appropriately without has no way to verify that the From header field has been populated
some sort of cryptographic authentication mechanism. accurately, in the absence of some sort of cryptographic
authentication mechanism.
Today, RFC3261 specifies a number of security mechanisms that can be RFC3261 specifies a number of security mechanisms that can be
used by SIP UAs, including Digest, TLS and S/MIME (and employed by SIP UAs, including Digest, TLS and S/MIME
implementations may support other security schemes as well). (implementations may support other security schemes as well).
However, few SIP user agents today can support the end-user However, few SIP user agents today support the end-user certificates
certificates necessary to authenticate themselves via TLS or S/MIME, necessary to authenticate themselves via TLS or S/MIME, and
and Digest authentication is limited by the fact that the originator furthermore Digest authentication is limited by the fact that the
and destination must share a secret. It is desirable for SIP user originator and destination must share a pre-arranged secret. It is
agents to be able to send requests to destinations with they have no desirable for SIP user agents to be able to send requests to
previous association - just as in the telephone network today, one destinations with they have no previous association - just as in the
can receive a call from someone with whom one has no previous telephone network today, one can receive a call from someone with
association, and still have a reasonable assurance that their whom one has no previous association, and still have a reasonable
displayed Caller-ID is accurate. assurance that their displayed Caller-ID is accurate.
Many SIP user agents today support a means of authenticating 2. Terminology
themselves to a SIP registrar - commonly with a shared secret (Digest
authentication, which MUST be supported by SIP user agents, is In this document, the key words "MUST", "MUST NOT", "REQUIRED",
typically used for this purpose). Registration allows a user agent "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
to express that it is the proper entity to which requests should be RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
sent for a particular address-of-record SIP URI. described in RFC2119 [2] and indicate requirement levels for
compliant SIP implementations.
3. Background
All RFC3261-compliant SIP user agents support a means of
authenticating themselves to a SIP registrar - commonly with a shared
secret (Digest authentication, which MUST be supported by SIP user
agents, is typically used for this purpose). Registration allows a
user agent to express that it is the proper entity to which requests
should be sent for a particular address-of-record SIP URI.
Coincidentally, the address-of-record URI of a SIP user is also the Coincidentally, the address-of-record URI of a SIP user is also the
URI with which a SIP UA populates the From header of requests from URI with which a user commonly populates the From header of requests
that user - in other words, the address-of-record is an identity. So - in other words, the address-of-record is an identity. So in this
in this context users already have a means of providing their context, users already have a means of providing their identity,
identity, which makes good sense: since the contents of a From header which makes good sense: since the contents of a From header field are
field are essentially a 'return address' for SIP requests, being able essentially a 'return address' for SIP requests, being able to prove
to prove that you are eligible to receive requests for that 'return that you are eligible to receive requests for that 'return address'
address' should be identical to proving that you are authorized to should be identical to proving that you are authorized to assert this
assert this identity. identity.
However, the credentials with which a user agent proves to a However, the credentials with which a user agent proves their
registrar that they are, for example, an authorized recipient of identity to a registrar cannot be validated by a user agent or proxy
requests for 'sip:alice@atlanta.com' will not be accepted by a server server outside your local domain - these credentials are currently
in another domain - these credentials are currently only useful for only useful for registration. For the purposes of determining
local registration. What other domains really want to know about whether or not the 'return address' of a request can legitimately be
your identity is that you are capable of authenticating yourself in asserted as the identity of the user, SIP entities in other domains
your own domain. require an assurance that the sender of a message is capable of
authenticating themselves to a registrar in their own domain.
Ideally, then, there should be some way of proving to remote domains Ideally, then, SIP user agents should have some way of proving to
that your local domain has authenticated you. In the absence of end- recipients of SIP messages that their local domain has authenticated
user certificates in user agents, it is possible to implement a them. In the absence of end-user certificates in user agents, it is
mediated authentication architecture for SIP in which requests are possible to implement a mediated authentication architecture for SIP
sent to a server in the user's local domain which authenticates them in which requests are sent to a server in the user's local domain
(using the same practices by which the domain would authenticate which authenticates such requests (using the same practices by which
REGISTER requests). Once a request has been authenticated, the local the domain would authenticate REGISTER requests). Once a message has
domain then needs some way to communicate to remote domains that it been authenticated, the local domain then needs some way to
has sanctioned the request. This draft addresses how that identity communicate to other SIP entities the sending user has been
can could be securely shared. authenticated. This draft addresses how that imprimatur of
authentication can be shared.
RFC3261 already describes an architecture very similar to this in RFC3261 already describes an architecture very similar to this in
Section 26.3.2.2, in which a user agent authenticates itself to a Section 26.3.2.2, in which a user agent authenticates itself to a
local proxy server which in turn authenticates itself to a remote local proxy server which in turn authenticates itself to a remote
proxy server via mutual TLS, creating a two-link chain of transitive proxy server via mutual TLS, creating a two-link chain of transitive
authentication between the originator and the remote domain. While authentication between the originator and the remote domain. While
this works well in some architectures, there are a few respects in this works well in some architectures, there are a few respects in
which this is impractical. For one, it is possible for SIP requests which this is impractical. For one, transitive trust in inherently
to cross multiple intermediaries in separate administrative domains, weaker than an assertion that can be validated end-to-end. It is
in which case transitive trust becomes far less compelling. It also possible for SIP requests to cross multiple intermediaries in
requires intermediaries to act as proxies, rather than redirecting separate administrative domains, in which case transitive trust
requests to their destinations (redirection lightens loads on SIP becomes even less compelling. It also requires intermediaries to act
intermediaries). Both of these limitations result from the fact that as proxies, rather than redirecting requests to their destinations
authentication takes place outside the application, at the transport (redirection lightens loads on SIP intermediaries).
layer, rather than within SIP itself.
One solution to this problem is to use 'trusted' SIP intermediaries One solution to this problem is to use 'trusted' SIP intermediaries
that assert an identity for users in the form of a privileged SIP that assert an identity for users in the form of a privileged SIP
header. A mechanism for doing so (with the P-Asserted-Identity header. A mechanism for doing so (with the P-Asserted-Identity
header) is given in [6]. However, this solution allows only hop-by- header) is given in [6]. However, this solution allows only hop-by-
hop trust between intermediaries, not end-to-end cryptographic hop trust between intermediaries, not end-to-end cryptographic
authentication, and it assumes a managed network of nodes with strict authentication, and it assumes a managed network of nodes with strict
mutual trust relationships, an assumption that is incompatible with mutual trust relationships, an assumption that is incompatible with
widespread Internet deployment. widespread Internet deployment.
The desired mediated authentication architecture has quite a bit in Accordingly, a new tactic is required for sharing a cryptographic
common with the problem space of Kerberos [5]. Ideally, there should assurance of end-user identity in an intradomain context.
be a way for a user to authenticate themselves to the local domain, Furthermore, this new mechanism must work for both SIP requests and
and receive some kind of token that they can share with recipients of responses. However, there is an additional wrinkle specific to
requests that lets them know that the user has been authenticated by providing identity in a response. While the original address-of-
the local domain. However, Kerberos support in SIP user agents is record to which a request is sent is stored in the To header field of
not widespread, and moreover SIP uses other means (such as Digest) to the request, it is possible, due to retargeting at intermediaries, it
perform key authentication functions already. An ideal solution is possible that the request will be forwarded to an entity that has
would adapt existing SIP security mechanisms to address this problem. a different AoR (i.e. identity). Since the To header is not changed
in responses to a SIP request, the UAC has no way of discovering that
new AoR. This is generally known as the "response identity" or
"connected party" problem.
Therefore, this document defines a new logical role for SIP network 4. Requirements
intermediaries called an 'authentication service'. Once an
authentication service has verified the identity of the originator of
a request, as described above, it creates a cryptographic token that
contains the authenticated identity of the user, and which has some
reference integrity with the request itself. This token can then be
added to a SIP request and inspected by recipients of the request who
need a cryptographic guarantee of the identity of the user.
One possible format for such tokens is the Authenticated Identity This draft addresses the following requirements:
Body (AIB) described in [4]. Other token formats are a matter for
further investigation. Throughout this document, the use of AIB
format for the token is considered exclusively. Only tokens that are
suitable to be carried in a MIME body are considered in this
document.
2. Terminology The mechanism must allow a UAC to provide a strong cryptographic
identity assurance to the UAS in a request.
In this document, the key words "MUST", "MUST NOT", "REQUIRED", The mechanism must allow a UAS to provide a strong cryptographic
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT identity assurance to the UAC in a response.
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in RFC2119 [2] and indicate requirement levels for
compliant SIP implementations.
3. Using an Authentication Service User agents that receive identity assurances must be able to
validate these assurances without performing any network lookup.
A SIP user agents sends requests to an authentication service in Proxy servers must be capable of adding this identity assurance to
order to receive an authentication token for the request. How requests or responses.
exactly the association with an authentication service is learned or
configured is an implementation-specific matter for the user agent -
it might be implemented with a pre-loaded Route header. The
guidelines given in RFC3261 Sections 26.3.2.1 and 26.3.2.2 should be
used when connecting to an authentication service; ideally, an
authentication service should be one hop away from a user agent, it
should use a lower-layer security protocol such as TLS or IPSec to
authenticate the authentication service before providing credentials
(especially shared secrets).
This document places no requirements on how an authentication The mechanism must prevent replay of the identity assurance by an
services authenticates requests. Since Digest authentication MUST be attacker.
supported by all SIP entities, the use of Digest for this purpose is
RECOMMENDED for compatibility with the maximum set of user agents.
4. How to Share Verified Identities The mechanism must be capable of protecting the integrity of SIP
message bodies (to ensure that media offers and answers are linked
to the signaling identity).
When an authentication service has authenticated the user, it must It must be possible for a user to have multiple AoRs (i.e.
construct an identity URI for that user that will be contained in the accounts or aliases) under which it is known at a domain, and for
token. It is RECOMMENDED that these identities take the form of SIP the UAC to assert one identity while authenticating itself as
address-of-record URI (as opposed to contact addresses), as they are another, related, identity, as permitted by the local policy of
defined in Section 10 of RFC3261; in other words, URIs of the form the domain.
'sip:alice@atlanta.com'.
This identity must be expressed in the authentication token that will It must be possible, in cases where a request has been retargeted
be signed by the authentication service. For example, if the to a different AoR than the one designated in the To header field,
Authenticated Identity Body (AIB) format described in [4] is used, for the UAC to ascertain the AoR to which the request has been
then for an INVITE this identity would be stored in the From header sent.
field within a 'message/sip' or 'message/sipfrag' [7] body that will
be signed by the authentication service.
Once the token has been created, the server MUST sign the token. The 5. Overview of Operations
subject of the certificate SHOULD be assigned in one of the two
following ways:
An authentication service MAY use a common certificate, such as a This section provides an informative (non-normative) high-level
site certificate, for its administrative domain. The overview of the mechanisms described in this document.
subjectAltName of this certificate MUST correspond with the host
portion of the From header field of the identity in the
authentication token (if the identity were
'sip:alice@atlanta.com', the subjectAltName of the certificate
would be 'atlanta.com'); this should be the same certificate that
the authentication service provides when proving its own identity
(via TLS or some similar protocol).
An authentication service MAY hold a certificate corresponding to Imagine the case where Alice, who has the home proxy of example.com
each user in its administrative domain (in other words, a and the address-of-record sip:alice@example.com, wants to communicate
certificate whose subjectAltName contains a URI equivalent to the with sip:bob@example.org.
address-of-record URI of the user). In this case, the appropriate
certificate for the authenticated user will be used to sign the
authentication token. Maintaining individual certificates for
each user is RECOMMENDED, since the name subordination rules
involved with the use of a common certificate for the domain can
become complicated.
After the authentication token has been signed, the authentication Alice generates an INVITE and places her identity in the From header
token MUST somehow be integrated with any existing MIME bodies in the field of the request. She then sends an INVITE over TLS to an
request, if necessary by transitioning the outermost MIME body to a authentication service proxy for her domain.
'multipart/mixed' format, before the request can be forwarded. Three
options are considered for ways that an authentication token could be
added to a SIP message: one in which the authentication service
pushes the token back to the client for resubmission, one in which
the authentication service adds the token itself, and one in which
the client anticipates a URI at which the authentication service will
make the token available. Authentication services MUST support the
mechanism in Section 4.1 and MAY support the mechanism in Section
4.2; the mechanism in Section 4.3 is included to illustrate a future
direction.
4.1 Body Added by Client The authentication service authenticates Alice (possibly by sending a
Digest authentication challenge) and validates that she is authorized
to populate the value of the From header field (which may be Alice's
AoR, or it may be some other value that the policy of the proxy
server permits her to use). It then computes a hash over some
particular headers, including the From header field and the bodies in
the message. This hash is signed with the certificate for the domain
(example.com, in Alice's case) and inserted in a header field (the
new Identity header) in the SIP message. The proxy, as the holder
the private key of its domain, is asserting that the originator of
this request has been authenticated and that she is authorized to
claim the identity (the SIP address-of-record) which appears in the
From header field. The proxy also inserts a companion header field
that tells Bob how to acquire its certificate, if he doesn't already
have it.
In this case, the authentication service returns the authentication When Bob returns a response to the INVITE (such as a 200 OK), a
token to the originating user agent, prompting the user agent to similar set of steps happen. Bob's home proxy asserts his identity
retry the request with the authentication token attached. No in the response. In this instance, the proxy has to insert the
existing SIP mechanism can perform this function. Therefore, this header directly into the request - redirection of responses is not
document defines a 428 "Use Authentication Token" response code. possible. When Alice receives the response, she verifies Bob's
identity.
After a user has been authenticated (in the Digest example, with the If Alice's request for Bob were retargeted, one of two things might
407 response) an authentication service sends a 428 with a MIME body happened. If it were retargeted to a domain that was also the
in order to request that a user agent add the enclosed MIME body to responsibility of Bob's home proxy (for example, retargeted from
their request and retry the request. A 428 MUST have at most a sip:bob@example.com to sip:carol@example.com), then the request would
single MIME body. This MIME body MUST be signed by the proceed normally and receive an Identity. If Bob's home proxy would
authentication service. retarget the request to some other domain (e.g.
sip:bob@example.ORG), then his home proxy would redirect the request
rather than proxying it, and Alice would send a new request that
could receive a response with an Identity from the new domain.
The use of 428 without any MIME body is also defined in this 6. User Agent Behavior: Sending Messages
document. It can be sent by any server to reject a request because
the request does not contain an authentication token. A user agent
receiving this rejection SHOULD retry their request through the same
server after acquiring a token from an authentication service.
In order to signal to the authentication services and other This mechanism requires one important change to existing user agent
intermediaries that the originating user agent supports the receipt behavior for sending requests and responses: user agents using this
of the 428 response code, a new option-tag has been defined, the mechanism to send requests or responses MUST support TLS; moreover,
'auth-id' option-tag. User agents SHOULD supply the 'auth-id' they MUST be capable of establishing a persistent TLS connection with
option-tag in a Supported header whenever they provide credentials to a proxy server that acts as an authentication service. Additionally,
a server (for example, in Digest authentication, whenever a Proxy- there are several practices that should be highlighted in the context
Authorization header is added to a request). of this identity solution.
Using the 428 response code may introduce extra round-trip times for When a UAC sends a request, it MUST accurately populate the header
messages, delaying the setup of requests. However, there are some field that asserts its identity (for a SIP request, this is the From
circumstances under which extra RTTs may not impede performance. If header field). In a request it MUST set the URI portion of its From
the originating user agent possesses a non-stale nonce (assuming header to match a SIP, SIPS or TEL URI AoR under which the UAC can
Digest authentication) from the authentication service, it can pre- register (including anonymous URIs, as described in RFC 3323 [3]).
emptively include a Proxy-Authorization header, eliminating one RTT The UAC MUST also be capable of sending requests through an
(the one resulting from a 407). With regard to the second RTT, note 'outbound' proxy (the authentication service), and of course MUST
that the request needn't necessarily go through the authentication support the Digest authentication mechanism described in RFC3261.
service again once the authentication token has been added - it could Because this mechanism does not provide integrity protection for the
go directly to its destination, which reduce the impact of the second first hop to the authentication service, the UAC MUST send requests
RTT. to an authentication service only over a TLS connection.
Additionally, in order to provide identity for responses, user agents
MUST form a persistent TLS connection to a proxy server when a
REGISTER is sent.
There are two good reasons to think that the originating user agent Since a UAS cannot send a response that does not replicate the
should be the party responsible for adding the authentication token contents of the To and From header fields in the corresponding
to the request. Firstly, because this gives the client the request, UAS response-sending behavior is unchanged. Again, because
opportunity to inspect the body itself (perhaps only to see whether this mechanism does not provide integrity protection for the first
or not it is encrypted; see [4]) in order to verify that the hop of the response path, the UAS SHOULD send responses only over a
authenticated identity corresponds with the provided credentials and TLS connection.
the user's preferences. Secondly, the client can provide a signature
over the entire body of the message (either with S/MIME or some
header-based mechanism) so that the final recipient of messages can
be assured that all information in the body is there at the
originator's behest.
4.2 Body Added by Authentication Service 7. Authentication Service Behavior
Another possibility is that the authentication service could add the The authentication service authenticates the identity of the message
body to the request itself before forwarding the request. However, sender and validates that the identity given in the message can
the authentication service role is usually played by entities that legitimately be asserted by the sender. Then it computes a signature
act as proxy servers for most requests, and proxy servers cannot over the canonical form of several headers and all the bodies, and
modify message bodies (see RFC3261 Section 16.6). In order to add an inserts this signature into the message.
authentication token, the authentication service needs to act as a
transparent back-to-back user agent, effectively terminating the
request and re-originating it with a new body appended to any
existing MIME bodies (again, transposing to various MIME multipart
forms as necessary).
This mechanism has some potential advantages over pushing the First, an authentication service MUST extract the identity of the
authentication token back to the originating user agent. For one, it sender. For requests, it inspects the From header field; for
saves one additional round-trip time that would be used by the 428 responses, the To header field (henceforth the result of this
response. It also requires no new SIP mechanisms, whereas the 428 inspection will be referred to as the "identity field). If the
response necessitates option-tag support. identity field contains a SIP or SIPS URI, the authentication service
MUST extract the hostname portion of the URI in that header field,
and compare this 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. Some example policies are described in [TODO].
If the authentication service is not responsible for the identity in
question, it MAY handle the request as a normal proxy server; see
below for more information on authentication service handling of an
existing Identity header.
However, there are proposed SIP integrity mechanisms that place a Second, the authentication service must determine whether or not the
signature over the entire message body in a SIP message header. Were sender of the request is authorized to claim the identity given in
a server to modify the body of a message that was protected by such the identity field. In order to do so, the authentication service
signature, that would be perceived as an integrity violation by MUST authenticate the sender of the message. Some possible ways in
downstream recipients of the message. Presumably, a back-to-back which this authentication might be performed include:
user agent function would have to sacrifice this end-to-end
integrity. The notion of a transparent back-to-back user agent is
also ill-defined, and it is questionable if any SIP intermediaries
should interfere with SIP message bodies.
4.3 Using Content Indirection For requests, challenging the request with a 407 response code
using the Digest authentication scheme (or viewing a Proxy-
Authentication header sent in the request which was sent in
anticipation of a challenge using cached credentials, as described
in RFC 3261 Section 22.3)
Work is currently underway in the SIP WG to define a content For requests and responses that are sent over a persistent TLS
indirection [8] mechanism for SIP, a mechanism by which a MIME body connection, relying on some prior authentication that was
in a SIP request can refer, with a URL, to a document that it hosted performed at the formation of the connection (most likely, the
somewhere in the network. This raises another interesting authentication service previously challenged a REGISTER request
possibility for authentication token transport in SIP. sent after the TLS connection was formed, or possibly a prior
challenged INVITE that was sent over the TLS connection)
A SIP user agent could create a content indirection MIME body (using Authorization of the assertion of a particular username in the From
the RFC2017 [9] URL MIME External-Body Access-Type) that contains a header field of a SIP message is a matter of local policy for the
URL that identities a resource controlled by the authentication authorization service which depends greatly on the manner in which
service, anticipating that the authentication service will make the authentication is performed. A RECOMMENDED policy is as follows: the
authentication token available at that URL. This URL could be pushed username asserted during Digest authentication MUST correspond
by the authentication service to the UAC when the authentication exactly to the username in the From header field of the SIP message.
service challenges the UAC (as a new header in the 407 response). However, there are many cases in which a user might manage multiple
Once an authentication service has validated the request, it simply accounts in the same administrative domain. Accordingly, provided
makes the authentication token available at the anticipated URL; the authentication service is aware of the relationships between
recipients of the message would then dereference the URL in order to these accounts, it might allow a user providing credentials for one
inspect the token. account to assert a username associated with another account
controlled by the user name. Furthermore, if the AoR asserted in the
From header field is anonymous (per RFC3323), then the proxy should
authenticate that the user is any valid user in the domain and insert
the signature over the From header field as usual.
This approach could allow user agents to have full control over the Third, the authentication service MUST form the identity signature,
integrity of SIP requests, while still requiring the extra RTT caused as described in Section 10, and add an Identity header to the request
by the use of the 428 response code. It also has numerous advantages containing this signature. After the Identity header has been added
over other ways of handling authentication tokens issued for SIP to the request, the authentication service MUST also add an Identity-
response messages (see Section 5). Info header. The Identity-Info header contains a URI from which its
certificate can be acquired. Details are provided in section Section
10.
5. Identity in Responses Finally, the authentication service MUST forward the message
normally.
Many of the practices described in the preceding sections can be 7.1 UAs acting as an Authentication service
applied to responses as well as requests, with some important
differences. Primarily, the distinction is that a response cannot be
challenged or resubmitted in the same manner as a request, and
therefore the mechanism in Section 4.1 is not usable. However, when
a user agent registers under a particular identity, and thereby
becomes eligible to receive requests and send responses associated
with that identity, it provides credentials that prove its identity,
and thus if the registrar is co-located with the proxy that receives
requests for the user's administrative domain, is in a reasonable
position to act as an authentication service for responses.
Note that the identity in an authentication token in a response There are some instances in which a user agent may hold the private
almost certainly will not correspond with the identity asserted in key of the domain Certificate for its address-of-record. In these
the From header field of the response (which is copied from the cases, the UA MAY perform the services, and add the headers, that the
request); the identity in the authentication token represents a authentication service would normally add.
different entity. For many requests, the identity in the
authentication token of a response will correspond to the To header
field of the request, but there are numerous legitimate ways that
requests can be retargeted in which this will not be the case.
An authentication service that also acts as a registrar and inbound 8. Verifying Identity
proxy can add to a response an authentication token that corresponds
to the identity of the originator of that response in roughly the
same manner described in Section 4.2 - the authentication service
adds the authentication token to a response before it forwards the
response towards the originator of the request. There is no way for
an authentication service to perform a function for responses
comparable to the mechanism described in Section 4.1; however,
content indirection (see Section 4.3 could provide an alternative
that would allow the client to retain end-to-end integrity properties
on responses.
6. Receiving an Authentication Token When a user agent or proxy server receives a SIP message containing
an Identity header, it can inspect the signature to verify the
identity of the sender of the message. If an Identity header is not
present in a request, and one is required by local policy, then a 428
Use Identity response is sent. If an Identity header is not present
in a response, and one is required by local policy, then the
recipient of the response MUST communicate this lapse to its user,
and MAY immediately terminate any created dialog or ignore
transactions, as policy dictates.
The manner in which an authentication token is handled is dependent In order to verify the identity of the sender of a message, the user
on the nature of the token itself; rules for handling the agent or proxy server MUST first acquire the certificate for the
Authenticated Identity Body (AIB) format are given [4]. signing domain. Implementations supporting this specification should
have some means of retaining domain certificates (in accordance with
normal practices for certificate lifetimes and revocation) in order
to prevent themselves from needlessly downloading the same
certificate every time a request from the same domain is received.
Certificates retained in this manner should be indexed by the URI
given in the Identity-Info header field value.
6.1 Authentication Service Handling of Authentication Tokens Provided that the domain certificate used to sign this message is
unknown, SIP entities discover this certificate by dereferencing the
Identity-Info header. The client processes this certificate in the
usual ways including checking that it has not expired, that the chain
is valid back to a trusted CA, and that it does not appear on
revocation lists.
SIP intermediaries generally should not attempt to inspect MIME Subsequently, the recipient MUST verify the signature in the Identity
bodies; following the rules of RFC3261 Section 16.6, MIME bodies may header, and compare the identity of the signer (the subjectAltName of
be encrypted end-to-end or have other properties that make them the certificate) with the domain portion of the URI in the From
unsuitable for consumption by intermediaries. However, header field of the request as described in Section 11.
intermediaries that implement the authentication service logical role Additionally, the Date, Contact and Call-ID headers MUST be analyzed
MAY inspect MIME bodies in order to find one with a Content- in the manner described in Section 11; recipients that wish to verify
Disposition of 'auth-id'. Identity signatures MUST support all of the operations described
there. Any discrepancies or violations MUST be reported to the user.
For the most part, the actual value of an authenticated identity is When the originating user agent of a request receives a response
not likely to be of interest to a proxy server, though it MAY refuse containing an Authenticated Identity Body (AIB, see [4]), it SHOULD
to process a request that does not contain a valid authentication compare the identity in the From header field of the AIB of the
token (using the 428 request, as described in Section 4.1). However, response with the original value of the To header field in the
authentication services MAY additionally maintain lists of known request. If these represent different identities, the user agent
problem users that are banned from making requests to their SHOULD render the identity in the AIB of the response to its user.
administrative domain, for example, and subsequently reject some Note that a discrepancy in these identity fields is not necessary an
requests after comparing their authenticated identities to such indication of a security breach; normal retargeting may simply have
access control lists. directed the request to a different final destination. Implementers
therefore may consider it unnecessary to alert the user of a security
violation in this case.
7. Selective Sharing of Identity 9. Proxy Server Behavior
Most of the time, there is no need to restrict the propagation of In most respects, a proxy server behaves normally when it receives a
verified identities in the network. User agents and intermediaries SIP request or response containing an Identity header. This
benefit from receiving verified identities. However, in some cases mechanism is fully backwards-compatible with existing RFC3261 proxy
intermediaries might want to restrict the distribution of identity behavior. However, if a proxy intends to act as an authentication
information, for example if service for responses to requests it receives, it must exhibit some
additional behavior to ensure that retargeting requests are handled
properly. Essentially, a proxy server MUST NOT provide an Identity
header for a request that it retargets to a different administrative
domain. It is the responsibility of that administrative domain to
provide its own identity assertion, if it can. However, proxying the
request to a remote domain where identity services may be provided
has its own problems - the originator of the request has no way to
know whether the request was legitimately retargeted, or if any
responses it receives from the new domain are spoofed or otherwise
illegitimate. It is thus much more secure for the proxy server to
redirect in cases where it might otherwise retarget.
o the authenticated identity body contains an identity that is only If a proxy server intends to act as an authentication service for a
meaningful as an internal identifier within a particular service response to a SIP request that it is forwarding, it MUST do ALL of
provider's network, or, the following:
o the originating user agent has requested privacy, and the Ascertain if it is responsible for the domain indicated in the
unrestricted distribution of the authenticated identity body would Request-URI field of the request. If not, it MUST forward the
violate that request. request normally. If so, it must then:
If it is not appropriate to share an authenticated identity because a Determine the route set of targets to which this request might be
user has requested privacy, an authenticated identity body SHOULD NOT forwarded. From that target list, the proxy must determine which
be created and distributed. However, in some cases there may be contact addresses are associated with persistent TLS connections
other entities in the administrative domain of the authentication that have been established to the proxy server. It places all
service that are consumers of the authenticated identity. If, for such targets (if any) into a primary route set for the call, and
example, each of these servers needed to challenge the user places remaining targets into a secondary route set for the call.
individually for identity, it might significantly delay the It performs this operations irrespective of any qvalues associated
processing of the request. For that reason, it may be appropriate to with the contact addresses.
circulate authenticated identity bodies among a controlled set of
entities. For that purpose, an encryption mechanism for
authenticated identities is required.
7.1 Requesting Privacy The proxy then MUST follow normal administrative policies for
forwarding the request to any targets in the primary route set
(which may involve qvalue calculations or any other behaviors
described in RFC3261). Before the proxy forwards any responses to
this request upstream, the proxy server MUST act as an
authentication service (as described in Section 7), adding an
Identity and Identity-Info header.
When users authenticate themselves to an authentication service, they If there are no appropriate responses from the primary route set
MAY explicitly notify the service that they do not wish their for the proxy server to forward upstream, it moves on to the
authenticated identity to be circulated. Usually, the user in secondary route set (essentially, the proxy server forks
question would also be taking other steps to preserve their privacy sequentially, exploring the primary route set as one cluster, and
(perhaps by including an anonymous From header in the SIP request, then moves on to the secondary set). The proxy server is unable
and following other standard privacy practices). to act as an authentication service for those contact addresses.
Accordingly, the proxy server MUST NOT explore these route targets
itself; instead, it MUST redirect the request with a 3xx class
response containing the contact addresses that constitute the
secondary route set.
Authentication services MUST support the privacy mechanism described In order to build the primary route set for the call, the location
in RFC3323 [3]. Users requesting privacy should also support the service associated with the domain of the proxy server MUST implement
mechanisms described in that document. additional intelligence to determine which contact addresses are
associated with a persistent TLS connection - this is used to
determine when the server should act as a proxy and when it should
redirect. When the SIP registrar receives a REGISTER request over a
persistent TLS connection, it MUST compare any contact addresses
appearing in Contact header fields to the topmost Via header field in
the REGISTER request. If the host portion of a contact address
matches the hostname given in the topmost Via header field, then that
contact address is said to be "associated" with the persistent TLS
connection over which the REGISTER was received. Location services
must mark or flag these contact addresses accordingly, and remember
the identity that the user provided when they were authenticated
during registration. Only these contact addresses are added to the
primary route set by a proxy server that wishes to act as an
authentication service for responses.
In particular, this document uses an identity-specific priv-value Additionally, domain policy may require proxy servers to inspect and
that can appear in the Privacy header, a value of 'id', which was verify the identity provided in SIP requests. The proxy server may
registered by RFC3325 [6]. This Privacy value requests that the wish to ascertain the identity of the sender of the message to
results of authentication should not be shared by the authenticating provide spam prevention or call control services. Even if a proxy
intermediary. An authentication service SHOULD NOT create an server does not act as an authentication service, it MAY verify the
authentication token for a request when 'id' privacy has been signature present in an Identity header before it makes a forwarding
requested. If such a token is created, it MUST be encrypted or decision for a request. Proxy servers MUST NOT remove or modify the
rendered confidential in the manner most appropriate to the token. Identity or Identity-Info headers.
Guidelines for encrypting AIBs are given in [4], and these mechanisms
MUST be supported by any authentication service that uses AIBs.
8. Security Considerations 10. Header Syntax
This document specifies two new SIP headers: Identity and Identity-
Info. Each of these headers can appear only once in a SIP message.
Identity = "Identity" HCOLON signed-identity-digest
signed-identity-digest = LDQUOT 32LHEX RDQUOT
Identity-Info = "Identity-Info" HCOLON ident-info
Ident-info = LAQUOT absoluteURI RAQUOT
To create the contents of the signed-identity-digest, the following
elements of a SIP message MUST placed in the string in the order
specified here, separated by a colon:
The AoR of the UA sending the message, or the 'identity field'.
For a request, this is the addr-spec from the From header field;
for responses, the addr-spec of the To header field. This needs
to be in lower case and to be represented as a SIP URI.
The callid from Call-Id header field.
The Date header field, with exactly one space each for each SP and
the weekday and month items case set as shown in BNF in 3261. The
first letter is upper case and the rest of the letters are lower
case.
The addr-spec component of the Contact header field value.
The body content of the message with the bits exactly as they are
in the message.
For more information on the security properties of these headers, and
why their inclusion mitigates replay attacks, see [4]. The precise
formulation of this digest-string is, therefore:
digest-string = addr-spec HCOLON callid HCOLON SIP-Date
HCOLON addr-spec HCOLON message-body
Note again that the first addr-spec MUST be taken from the From
header field value, and the second addr-spec from the Contact header
field value.
After the digest-string is formed, it MUST be hashed and signed with
the certificate for the domain, as follows: compute the results of
signing this string with sha1WithRSAEncryption as described in RFC
3370 and base64 encode the results as specified in RFC 3548. Put the
result in the Identity header.
Note on this choice: Assuming a 1024 bit RSA key, the raw signature
will result in about 170 octets of base64 encoded data. For
comparison's sake, a typical HTTP Digest Authorization header (such
as those used in RFC3261) with no cnonce is around 180 octets. From
a speed point of view, a 2.8GHz Intel processor does somewhere in the
range of 250 RSA 1024 bits signs per second or 1200 RSA 512 bits
signs; verifies are roughly 10 times faster. Hardware accelerator
cards are available that speed this up.
The Identity-Info header MUST contain either an HTTPS URI or a SIPS
URI. If it contains an HTTPS URI, the URI must dereference to a
resource that contains a single MIME body containing the certificate
of the authentication service. If it is a SIPS URI, then the
authentication service intends for a user agent that wishes to fetch
the certificate to form a TLS connection to that URI, acquire the
certificate during normal TLS negotiation, and close the connection.
This document adds the following entries to Table 2 of [1]:
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
Identity a - o - o o -
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
o o o - - -
Identity-Info a - o - o o -
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
o o o - - -
11. Security Considerations
This document describes a mechanism which provides a signature over
the Contact, Date, Call-ID, and 'identity fields' (addr-spec of the
From header field for requests, and To header field for responses) of
SIP messages. While a signature over the identity field alone would
be sufficient to secure a URI alone, the additional headers provide
replay protection and reference integrity necessary to make sure that
the Identity header will not be used in cut-and-paste attacks. In
general, the considerations related to the security of these headers
are the same as those given in RFC3261 for including headers in
tunneled 'message/sip' MIME bodies (see Section 23 in particular).
The identity field indicates the identity of the sender of the
message. The Date and Contact headers provide reference integrity
and replay protection, as described in RFC3261 Section 23.4.2.
Implementations of this specification MUST NOT consider valid a
request with an outdated Date header field (the RECOMMENDED interval
is that the Date header must indicate a time within 3600 seconds of
the receipt of a message). Implementations MUST also record Call-IDs
received in valid requests containing an Identity header, and MUST
remember those Call-IDs for at least the duration of a single Date
interval (i.e. 3600 seconds). Accordingly, if an Identity header is
replayed within the Date interval, receivers will recognize that it
is invalid because of a Call-ID duplication; if an Identity header is
replayed after the Date interval, receivers will recognize that it is
invalid because the Date is stale. The Contact header field is
included to tie the Identity header to a particular device instance
that generated the request. Were an active attacker to intercept a
request containing an Identity header, and cut-and-paste the Identity
header field into their own request (reusing the identity fields,
Contact, Date and Call-ID fields that appear in the original
message), they would not be eligible to receive SIP requests from the
called user agent, since those requests are routed to the URI
identified in the Contact header field.
This mechanism also provides a signature over the bodies of SIP
requests. The most important reason for doing so is to protect SDP
bodies carried in SIP requests. There is little purpose in
establishing the identity of the user agent that provided the
signaling if a man-in-the-middle can change the SDP and direct media
to an alternate address. Note however that this is not perfect end-
to-end security. The authentication service itself, when
instantiated at a intermediary, can change the SDP (and SIP headers,
for that matter) before providing a signature. Thus, while this
mechanism reduces the chance that a man-in-the-middle will interfere
with sessions, it does not eliminate it entirely. Since it is
assumed that the user trusts their local domain to vouch for their
security, they must also trust the service not to violate the
integrity of their message bodies without good reason.
Users SHOULD NOT provide credentials to an authentication service to Users SHOULD NOT provide credentials to an authentication service to
which they cannot initiate a direct connection, preferably one which they cannot initiate a direct connection, preferably one
secured by a network or transport layer security protocol such as secured by TLS. If a user does not receive a certificate from the
TLS. If a user does not receive a certificate from the authentication service over this TLS that corresponds to the expected
authentication service over this lower-layer protocol that domain (especially when they receive a challenge via a mechanism such
corresponds to the expected domain (especially when they receive a as Digest), then it is possible that a rogue server is attempting to
challenge via a mechanism such as Digest), then it is possible that a pose as a authentication service for a domain that it does not
rogue server is attempting to pose as a authentication service for a control, possibly in an attempt to collect shared secrets for that
domain that it does not control, possibly in an attempt to collect domain. If a user cannot connect directly to the desired
shared secrets for that domain. If a user cannot connect directly to authentication service, the user SHOULD at least use a SIPS URI to
the desired authentication service, the user SHOULD at least use a ensure that mutual TLS authentication will be used to reach the
SIPS URI to ensure that mutual TLS authentication will be used to remote server.
reach the remote server.
Relying on an authentication token generated by a remote Relying on an Identity header generated by a remote administrative
administrative domain assumes that the domain uses some trustworthy domain assumes that the issuing domain uses some trustworthy practice
practice to authenticate its users. However, it is possible that to authenticate its users. However, it is possible that some domains
some domains will implement policies that effectively make users will implement policies that effectively make users unaccountable
unaccountable (such as accepting unauthenticated registrations from (such as accepting unauthenticated registrations from arbitrary
arbitrary users). Therefore, it is RECOMMENDED that authentication users). The value of an Identity header for such domains is
tokens contain some indication of the specific practice (for example, questionable.
Digest) that was used to authenticate this request as a rough
indicator of credential strength. No manner of describing
authentication practices is specified in this document.
If a common certificate is used by an authentication service (rather Since a domain certificate is used by an authentication service
than individual certificates for each identity), certain problems can (rather than individual certificates for each identity), certain
arise with name subordination. For example, if an authentication problems can arise with name subordination. For example, if an
service holds a common certificate for the hostname authentication service holds a common certificate for the hostname
'sip.atlanta.com', can it legitimately sign a token containing an 'sip.atlanta.com', can it legitimately sign a token containing an
identity of 'sip:alice@atlanta.com'? It is difficult for the identity of 'sip:alice@atlanta.com'? It is difficult for the
recipient of a request to ascertain whether or not 'sip.atlanta.com' recipient of a request to ascertain whether or not 'sip.atlanta.com'
is authoritative for the 'atlanta.com' domain unless the recipient is authoritative for the 'atlanta.com' domain unless the recipient
has some foreknowledge of the administration of 'atlanta.com'. has some foreknowledge of the administration of 'atlanta.com'.
Therefore, it is RECOMMEND that user agent recipients of Therefore, it is RECOMMENDED that user agent recipients of
authentication tokens notify end users if there is ANY discrepancy authentication tokens notify end users if there is ANY discrepancy
between the subjectAltName of the signers certificate and the between the subjectAltName of the signers certificate and the
identity within the authentication token. identity within the authentication token. Minor discrepancies MAY be
characterized as such. Additionally, relying parties MAY follow the
Authentication tokens MUST have some form of replay protection. The procedures in RFC3264 to look up on the domain portion of the
best protection is to copy the SIP request in its entirety (via the identity in the From header field in the DNS, and compare the SIP
'message/sip' MIME type) into the authentication token - in that way, services listed for that domain with the subjectAltName of the
it will be clear that this token has been issued for this request, certificate; this can give the relying party a better sense of the
since collectively the headers of a SIP request provide a unique canonical SIP services for that domain.
identifier. However, SIP requests can be large, and it is reasonable
to include only a subset of the SIP headers in a request (using the
'message/sipfrag' MIME type) as long as certain critical headers are
provided. For further discussion of this issue, including guidelines
for including particular headers in a sipfrag, see [4].
Because the common certificates that can be used by authentication Because the domain certificates that can be used by authentication
services need to assert only the hostname of the authentication services need to assert only the hostname of the authentication
service, existing certificate authorities can provide adequate service, existing certificate authorities can provide adequate
certificates for this mechanism. However, not all proxy servers and certificates for this mechanism. However, not all proxy servers and
user agents will be able support the root certificates of all user agents will be able support the root certificates of all
certificate authorities, and moreover there are some significant certificate authorities, and moreover there are some significant
differences in the policies by which certificate authorities issue differences in the policies by which certificate authorities issue
their certificates. This document makes no recommendations for the their certificates. This document makes no recommendations for the
usage of particular certificate authorities, nor does it describe any usage of particular certificate authorities, nor does it describe any
particular policies that certificate authorities should follow, but particular policies that certificate authorities should follow, but
it is anticipated that operational experience will create de facto it is anticipated that operational experience will create de facto
standards for the purposes of authentication services. Some standards for the purposes of authentication services. Some
federations of service providers, for example, might only trust federations of service providers, for example, might only trust
certificates that have been provided by a certificate authority certificates that have been provided by a certificate authority
operated by the federation. operated by the federation.
9. IANA Considerations 12. IANA Considerations
This document defines a new SIP status code, '428 Use Authentication This document specifies two new SIP headers: Identity and Identity-
Token'. The use of this status code is further described in Section Info. Their syntax is given in Section 10. This document requests
4.1. that IANA add these headers to the SIP header registry.
This document also defines a new SIP response code, 428 "Use
Identity", as described in Section 8.
Normative References Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[2] Bradner, S., "Key words for use in RFCs to indicate requirement [2] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", RFC 2119, March 1997. levels", RFC 2119, March 1997.
skipping to change at page 14, line 5 skipping to change at page 17, line 5
[7] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, [7] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420,
November 2002. November 2002.
[8] Olson, S., "A Mechanism for Content Indirection in SIP [8] Olson, S., "A Mechanism for Content Indirection in SIP
Messages", draft-ietf-sip-content-indirect-mech-01 (work in Messages", draft-ietf-sip-content-indirect-mech-01 (work in
progress), August 2002. progress), August 2002.
[9] Freed, N., "Definition of the URL MIME External-Body Access- [9] Freed, N., "Definition of the URL MIME External-Body Access-
Type", RFC 2017, November 1996. Type", RFC 2017, November 1996.
Author's Address Authors' Addresses
Jon Peterson Jon Peterson
NeuStar, Inc. NeuStar, Inc.
1800 Sutter St 1800 Sutter St
Suite 570 Suite 570
Concord, CA 94520 Concord, CA 94520
US US
Phone: +1 925/363-8720 Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/ URI: http://www.neustar.biz/
Cullen Jennings
Cisco Systems
170 West Tasman Drive
MS: SJC-21/2
San Jose, CA 95134
USA
Phone: +1 408 902-3341
EMail: fluffy@cisco.com
Appendix A. Acknowledgments Appendix A. Acknowledgments
The authors would like to thank Eric Rescorla, Rohan Mahy, Robert The authors would like to thank Eric Rescorla, Rohan Mahy, Robert
Sparks, Jonathan Rosenberg, Mark Watson and Patrik Faltstrom for Sparks, Jonathan Rosenberg, Mark Watson and Patrik Faltstrom for
their comments. Cullen Jennings assisted greatly in the development their comments.
of the content indirection mechanism considered in Section 4.3.
Appendix B. Changelog Appendix B. Changelog
Changes from draft-ietf-sip-identity-01:
- Completely changed underlying mechanism - instead of using an
AIB, the mechanism now recommends the use of the Identity header
and Identity-Info header
- Numerous other changes resulting from the above
- Various other editorial corrections
Changes from draft-peterson-sip-identity-01: Changes from draft-peterson-sip-identity-01:
- Split off child draft-ietf-sip-authid-body-00 for defining of - Split off child draft-ietf-sip-authid-body-00 for defining of
the AIB the AIB
- Clarified scope in introduction - Clarified scope in introduction
- Removed a lot of text that was redundant with RFC3261 - Removed a lot of text that was redundant with RFC3261
(especially about authentication practices) (especially about authentication practices)
- Added mention of content indirection mechanism for adding token - Added mention of content indirection mechanism for adding token
to requests and responses to requests and responses
- Improved Security Considerations (added piece about credential - Improved Security Considerations (added piece about credential
strength) strength)
Changes from draft-peterson-sip-identity-00: Changes from draft-peterson-sip-identity-00:
skipping to change at page 15, line 4 skipping to change at page 18, line 22
Changes from draft-peterson-sip-identity-00: Changes from draft-peterson-sip-identity-00:
- Added a section on authenticated identities in responses - Added a section on authenticated identities in responses
- Removed hostname convention for authentication services - Removed hostname convention for authentication services
- Added text about using 'message/sip' or 'message/sipfrag' in - Added text about using 'message/sip' or 'message/sipfrag' in
authenticated identity bodies, also RECOMMENDED a few more headers authenticated identity bodies, also RECOMMENDED a few more headers
in sipfrags to increase reference integrity in sipfrags to increase reference integrity
- Various other editorial corrections - Various other editorial corrections
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/