draft-ietf-sip-identity-00.txt   draft-ietf-sip-identity-01.txt 
SIP WG J. Peterson SIP WG J. Peterson
Internet-Draft NeuStar Internet-Draft NeuStar
Expires: April 28, 2003 October 28, 2002 Expires: August 2, 2003 February 2003
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-00 draft-ietf-sip-identity-01
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 32
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 April 28, 2003. This Internet-Draft will expire on August 2, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
The existing mechanisms for expressing identity in the Session The existing mechanisms for expressing identity in the Session
Initiation Protocol oftentimes do not permit an administrative domain Initiation Protocol oftentimes do not permit an administrative domain
to verify securely the identity of the originator of a request. This to verify securely the identity of the originator of a request. This
document recommends practices and conventions for authenticating end document recommends practices and conventions for authenticating end
users, and proposes a way to distribute cryptographically secure users, and proposes a way to distribute cryptographically secure
authenticated identities within SIP messages. authenticated identities within SIP messages.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Using an Authentication Service . . . . . . . . . . . . . . . 5 3. Using an Authentication Service . . . . . . . . . . . . . . . 5
4. How to Share Verified Identities . . . . . . . . . . . . . . . 5 4. How to Share Verified Identities . . . . . . . . . . . . . . . 5
4.1 Body Added by Authentication Service . . . . . . . . . . . . . 6 4.1 Body Added by Client . . . . . . . . . . . . . . . . . . . . . 7
4.2 Body Added by Client . . . . . . . . . . . . . . . . . . . . . 7 4.2 Body Added by Authentication Service . . . . . . . . . . . . . 8
4.3 Using Content Indirection . . . . . . . . . . . . . . . . . . 8 4.3 Using Content Indirection . . . . . . . . . . . . . . . . . . 8
5. Identity in Responses . . . . . . . . . . . . . . . . . . . . 9 5. Identity in Responses . . . . . . . . . . . . . . . . . . . . 9
6. Receiving an Authentication Token . . . . . . . . . . . . . . 9 6. Receiving an Authentication Token . . . . . . . . . . . . . . 10
6.1 Authentication Service Handling of Authentication Tokens . . . 9 6.1 Authentication Service Handling of Authentication Tokens . . . 10
7. Selective Sharing of Identity . . . . . . . . . . . . . . . . 10 7. Selective Sharing of Identity . . . . . . . . . . . . . . . . 10
7.1 Requesting Privacy . . . . . . . . . . . . . . . . . . . . . . 10 7.1 Requesting Privacy . . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
Normative References . . . . . . . . . . . . . . . . . . . . . 12 Normative References . . . . . . . . . . . . . . . . . . . . . 13
Informative References . . . . . . . . . . . . . . . . . . . . 13 Informative References . . . . . . . . . . . . . . . . . . . . 13
B. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 14 B. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15 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 URI employed to reach a user (such as
'sip:alice@atlanta.com'). '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 From header
field. However, the recipient of a SIP request has no way to verify field. However, the recipient of a SIP request has no way to verify
that the From header field has been populated appropriately without that the From header field has been populated appropriately without
some sort of cryptographic authentication mechanism. some sort of cryptographic authentication mechanism.
Today, RFC3261 specifies a number of security mechanisms that can be Today, RFC3261 specifies a number of security mechanisms that can be
skipping to change at page 3, line 33 skipping to change at page 3, line 33
certificates necessary to authenticate themselves via TLS or S/MIME, certificates necessary to authenticate themselves via TLS or S/MIME,
and Digest authentication is limited by the fact that the originator and Digest authentication is limited by the fact that the originator
and destination must share a secret. It is desirable for SIP user and destination must share a secret. It is desirable for SIP user
agents to be able to send requests to destinations with they have no agents to be able to send requests to destinations with they have no
previous association - just as in the telephone network today, one previous association - just as in the telephone network today, one
can receive a call from someone with whom one has no previous can receive a call from someone with whom one has no previous
association, and still have a reasonable assurance that their association, and still have a reasonable assurance that their
displayed Caller-ID is accurate. displayed Caller-ID is accurate.
Many SIP user agents today support a means of authenticating Many SIP user agents today support a means of authenticating
themselves to a SIP registrar - commonly with a shared secret themselves to a SIP registrar - commonly with a shared secret (Digest
(Digest, which MUST be supported by SIP user agents, is typically authentication, which MUST be supported by SIP user agents, is
used for this purpose). Registration allows a user agent to express typically used for this purpose). Registration allows a user agent
that it is the proper place to which requests should be sent for a to express that it is the proper entity to which requests should be
particular address-of-record SIP URI. However, the credentials with sent for a particular address-of-record SIP URI.
which a user agent proves to a registrar that they are, for example,
an authorized recipient of requests for 'sip:alice@atlanta.com'
cannot be shared with a server in another domain - these credentials
are currently only useful for local registration.
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 SIP UA populates the From header of requests from
that user - in other words, the address-of-record is an identity. So that user - in other words, the address-of-record is an identity. So
it turns out that users already have a means of providing their in this context users already have a means of providing their
identity, if only to a registrar; in fact, since the contents of a identity, which makes good sense: since the contents of a From header
From header field are essentially a 'return address' for SIP field are essentially a 'return address' for SIP requests, being able
requests, being able to prove that you are eligible to receive to prove that you are eligible to receive requests for that 'return
requests for that 'return address' is identical to proving that you address' should be identical to proving that you are authorized to
are authorized to assert this identity. In other words, the best way assert this identity.
for a SIP user to prove that they can legitimately claim an identity
is to provide the same credentials they would need to provide in
order to register to receive requests for that identity; the two have
the same security properties. Since the operator of the registrar
controls the namespace of local SIP users (assigning the user portion
of SIP URIs in the domain), it is the ideal arbiter for identity in
SIP.
In the absence of end-user certificates in user agents, it is However, the credentials with which a user agent proves to a
possible to implement a mediated authentication architecture for SIP registrar that they are, for example, an authorized recipient of
in which requests are sent to a server in the user's local domain requests for 'sip:alice@atlanta.com' will not be accepted by a server
which authenticates them (using the same practices by which the in another domain - these credentials are currently only useful for
domain would authenticate REGISTER requests). Once a request has local registration. What other domains really want to know about
been authenticated, the local domain then needs some way to your identity is that you are capable of authenticating yourself in
communicate to remote domains that it has sanctioned the request. your own domain.
This draft addresses how that identity can could be securely shared.
Ideally, then, there should be some way of proving to remote domains
that your local domain has authenticated you. In the absence of end-
user certificates in user agents, it is possible to implement a
mediated authentication architecture for SIP in which requests are
sent to a server in the user's local domain which authenticates them
(using the same practices by which the domain would authenticate
REGISTER requests). Once a request has been authenticated, the local
domain then needs some way to communicate to remote domains that it
has sanctioned the request. This draft addresses how that identity
can could be securely 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, it is possible for SIP requests
to cross multiple intermediaries in separate administrative domains, to cross multiple intermediaries in separate administrative domains,
in which case transitive trust becomes far less compelling. It also in which case transitive trust becomes far less compelling. It also
skipping to change at page 5, line 7 skipping to change at page 5, line 6
common with the problem space of Kerberos [5]. Ideally, there should common with the problem space of Kerberos [5]. Ideally, there should
be a way for a user to authenticate themselves to the local domain, be a way for a user to authenticate themselves to the local domain,
and receive some kind of token that they can share with recipients of and receive some kind of token that they can share with recipients of
requests that lets them know that the user has been authenticated by requests that lets them know that the user has been authenticated by
the local domain. However, Kerberos support in SIP user agents is the local domain. However, Kerberos support in SIP user agents is
not widespread, and moreover SIP uses other means (such as Digest) to not widespread, and moreover SIP uses other means (such as Digest) to
perform key authentication functions already. An ideal solution perform key authentication functions already. An ideal solution
would adapt existing SIP security mechanisms to address this problem. would adapt existing SIP security mechanisms to address this problem.
Therefore, this document defines a new logical role for SIP network Therefore, this document defines a new logical role for SIP network
intermediaries (typically proxy servers) called an 'authentication intermediaries called an 'authentication service'. Once an
service'. Once an authentication service has verified the identity authentication service has verified the identity of the originator of
of the originator of a request, as describe above, it creates a a request, as described above, it creates a cryptographic token that
cryptographic token that contains the authenticated identity of the contains the authenticated identity of the user, and which has some
user, and which has some reference integrity with the request itself. reference integrity with the request itself. This token can then be
This token can then be added to a SIP request and inspected by added to a SIP request and inspected by recipients of the request who
recipients of the request who would like a cryptographic guarantee of need a cryptographic guarantee of the identity of the user.
the identity of the user.
One possible format for such tokens is the Authenticated Identity One possible format for such tokens is the Authenticated Identity
Body (AIB) described in [4]. Other plausible token formats are a Body (AIB) described in [4]. Other token formats are a matter for
matter for further investigation. Throughout this document, the use further investigation. Throughout this document, the use of AIB
of the AIB format as a token is considered exclusively. 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 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in RFC2119 [2] and indicate requirement levels for described in RFC2119 [2] and indicate requirement levels for
compliant SIP implementations. compliant SIP implementations.
3. Using an Authentication Service 3. Using an Authentication Service
A SIP user agents sends requests to an authentication service in A SIP user agents sends requests to an authentication service in
order to receive an authentication token for the request. How order to receive an authentication token for the request. How
exactly the association with an authentication service is configured exactly the association with an authentication service is learned or
is an implementation-specific matter for the user agent - it might be configured is an implementation-specific matter for the user agent -
implemented with a pre-loaded Route header. The guidelines given in it might be implemented with a pre-loaded Route header. The
RFC3261 Sections 26.3.2.1 and 26.3.2.2 should be used when connecting guidelines given in RFC3261 Sections 26.3.2.1 and 26.3.2.2 should be
to an authentication service; ideally, an authentication service used when connecting to an authentication service; ideally, an
should be one hop away from a user agent, it should use a lower-layer authentication service should be one hop away from a user agent, it
security protocol such as TLS or IPSec to authenticate the should use a lower-layer security protocol such as TLS or IPSec to
authentication service before providing credentials (especially authenticate the authentication service before providing credentials
shared secrets). (especially shared secrets).
This document places no requirements on how an authentication This document places no requirements on how an authentication
services authenticates requests. Since Digest authentication MUST be services authenticates requests. Since Digest authentication MUST be
supported by all SIP entities, the use of Digest for this purpose is supported by all SIP entities, the use of Digest for this purpose is
likely. RECOMMENDED for compatibility with the maximum set of user agents.
4. How to Share Verified Identities 4. How to Share Verified Identities
When an authentication service has authenticated the user, it must When an authentication service has authenticated the user, it must
construct an identity for that user that will be contained in the construct an identity URI for that user that will be contained in the
token. It is RECOMMENDED that these identities take the form of token. It is RECOMMENDED that these identities take the form of SIP
addresses-of-record, as they are defined in Section 10 of RFC3261; in address-of-record URI (as opposed to contact addresses), as they are
other words, URIs of the form 'sip:alice@atlanta.com'. defined in Section 10 of RFC3261; in other words, URIs of the form
'sip:alice@atlanta.com'.
This identity must be expressed in the authentication token that will This identity must be expressed in the authentication token that will
be signed by the authentication service. For example, if the be signed by the authentication service. For example, if the
Authentication Identity Body (AIB) format described in [4] is used, Authenticated Identity Body (AIB) format described in [4] is used,
this identity would be stored in the From header field within a then for an INVITE this identity would be stored in the From header
'message/sip' or 'message/sipfrag' [7] body that will be signed by field within a 'message/sip' or 'message/sipfrag' [7] body that will
the authentication service. be signed by the authentication service.
In some cases, an authentication service will hold a certificate Once the token has been created, the server MUST sign the token. The
corresponding to each user in its administrative domain (in other subject of the certificate SHOULD be assigned in one of the two
words, a certificate whose subjectAltName contains a URI equivalent following ways:
to the address-of-record URI of the user). The appropriate
certificate for the authenticated user will be used to sign the An authentication service MAY use a common certificate, such as a
authentication token. However, an authentication service MAY instead site certificate, for its administrative domain. The
use a common certificate for its administrative domain. The
subjectAltName of this certificate MUST correspond with the host subjectAltName of this certificate MUST correspond with the host
portion of the From header field of the identity in the portion of the From header field of the identity in the
authentication token (if the identity were 'sip:alice@atlanta.com', authentication token (if the identity were
the subjectAltName of the certificate would be 'atlanta.com'); this 'sip:alice@atlanta.com', the subjectAltName of the certificate
should be the same certificate that the authentication service would be 'atlanta.com'); this should be the same certificate that
provides when proving its own identity (via TLS or some similar the authentication service provides when proving its own identity
protocol). Maintaining individual certificates for each user is (via TLS or some similar protocol).
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
token MUST be added to any existing MIME bodies in the request, if
necessary by transitioning the outermost MIME body to a 'multipart/
mixed' format. Two options are considered for ways that an
authentication token could be added to a SIP message: one in which
the authentication service adds the token itself, and one in which it
pushes the token back to the client, essentially asking the client to
include the token in a retry of the request. Another possibility,
using content indirection, is mentioned as a direction for future
work. Authentication services MUST support the mechanism in Section
4.2 and MAY support the mechanism in Section 4.1.
4.1 Body Added by Authentication Service
The first possibility is that the authentication service could add
the body to the request itself before forwarding the request.
However, the authentication service role is usually played by
entities that act as proxy servers for most requests, and proxy
servers cannot modify message bodies (see RFC3261 Section 16.6). In
order to add an 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 push the An authentication service MAY hold a certificate corresponding to
authentication token back to the originating user agent. For one, it each user in its administrative domain (in other words, a
saves on additional round-trip times for signaling that result from certificate whose subjectAltName contains a URI equivalent to the
passing the body back to the user agent. It also requires no new SIP address-of-record URI of the user). In this case, the appropriate
mechanisms, whereas any method of asking a user agent to include a certificate for the authenticated user will be used to sign the
body in a resubmission to the current request would introduce new authentication token. Maintaining individual certificates for
protocol requirements. each user is RECOMMENDED, since the name subordination rules
involved with the use of a common certificate for the domain can
become complicated.
However, there are proposed SIP integrity mechanisms that place a After the authentication token has been signed, the authentication
signature over the entire message body in a SIP message header. Were token MUST somehow be integrated with any existing MIME bodies in the
a server to modify the body of a message that was protected by such request, if necessary by transitioning the outermost MIME body to a
signature, that would be perceived as an integrity violation by 'multipart/mixed' format, before the request can be forwarded. Three
downstream recipients of the message. Presumably, a back-to-back options are considered for ways that an authentication token could be
user agent function would have to sacrifice this end-to-end added to a SIP message: one in which the authentication service
integrity. 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.2 Body Added by Client 4.1 Body Added by Client
Alternatively, the authentication service could in some fashion In this case, the authentication service returns the authentication
return the authentication token to the originating user agent, token to the originating user agent, prompting the user agent to
prompting the user agent to retry the request with the authentication retry the request with the authentication token attached. No
token attached. No existing SIP mechanism performs this function. existing SIP mechanism can perform this function. Therefore, this
Therefore, this document defines a 428 "Use Authentication Token" document defines a 428 "Use Authentication Token" response code.
response code.
An authentication service sends a 428 with a MIME body in order to After a user has been authenticated (in the Digest example, with the
request that a user agent add the enclosed MIME body to their request 407 response) an authentication service sends a 428 with a MIME body
and retry the request. A 428 MUST have at most a single MIME body. in order to request that a user agent add the enclosed MIME body to
This MIME body MUST be signed by the authentication service. their request and retry the request. A 428 MUST have at most a
single MIME body. This MIME body MUST be signed by the
authentication service.
The use of 428 without any MIME body is also defined in this The use of 428 without any MIME body is also defined in this
document. It can be sent by any server to reject a request because document. It can be sent by any server to reject a request because
the request does not contain an authentication token. A user agent the request does not contain an authentication token. A user agent
receiving this rejection SHOULD retry their request through an receiving this rejection SHOULD retry their request through the same
authentication service. server after acquiring a token from an authentication service.
In order to signal to the authentication services that the In order to signal to the authentication services and other
originating user agent supports the receipt of the 428 response code, intermediaries that the originating user agent supports the receipt
a new option-tag has been defined, the 'auth-id' option-tag. User of the 428 response code, a new option-tag has been defined, the
agents SHOULD supply the 'auth-id' option-tag in a Supported header 'auth-id' option-tag. User agents SHOULD supply the 'auth-id'
whenever they provide credentials to a server (for example, in Digest option-tag in a Supported header whenever they provide credentials to
authentication, whenever a Proxy-Authorization header is added to a a server (for example, in Digest authentication, whenever a Proxy-
request). Authorization header is added to a request).
Using the 428 response code may introduce extra round-trip times for Using the 428 response code may introduce extra round-trip times for
messages, delaying the setup of requests (one RTT for the 407, messages, delaying the setup of requests. However, there are some
another for the 428). However, there are some circumstances under circumstances under which extra RTTs may not impede performance. If
which extra RTTs may not impede performance. If the originating user the originating user agent possesses a non-stale nonce (assuming
agent possesses a non-stale nonce (assuming Digest authentication) Digest authentication) from the authentication service, it can pre-
from the authentication service, it can pre-emptively include a emptively include a Proxy-Authorization header, eliminating one RTT
Proxy-Authorization header, eliminating one RTT. With regard to the (the one resulting from a 407). With regard to the second RTT, note
second RTT, note that the request needn't necessarily go through the that the request needn't necessarily go through the authentication
authentication service again once the authentication token has been service again once the authentication token has been added - it could
added - it could go directly to its destination, which reduce the go directly to its destination, which reduce the impact of the second
impact of the second RTT. RTT.
There are two reasons why the originating user agent should be the There are two good reasons to think that the originating user agent
party responsible for adding the authentication token to the request. should be the party responsible for adding the authentication token
Firstly, because this gives the client the opportunity to inspect the to the request. Firstly, because this gives the client the
body itself (perhaps only to see whether or not it is encrypted; see opportunity to inspect the body itself (perhaps only to see whether
[4]) in order to verify that the authenticated identity corresponds or not it is encrypted; see [4]) in order to verify that the
with the provided credentials and the user's preferences. Secondly, authenticated identity corresponds with the provided credentials and
the client can provide a signature over the entire body of the the user's preferences. Secondly, the client can provide a signature
message (either with S/MIME or some header-based mechanism) so that over the entire body of the message (either with S/MIME or some
the final recipient of messages can be assured that all information header-based mechanism) so that the final recipient of messages can
in the body is there at the originator's behest. be assured that all information in the body is there at the
originator's behest.
4.2 Body Added by Authentication Service
Another possibility is that the authentication service could add the
body to the request itself before forwarding the request. However,
the authentication service role is usually played by entities that
act as proxy servers for most requests, and proxy servers cannot
modify message bodies (see RFC3261 Section 16.6). In order to add an
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
authentication token back to the originating user agent. For one, it
saves one additional round-trip time that would be used by the 428
response. It also requires no new SIP mechanisms, whereas the 428
response necessitates option-tag support.
However, there are proposed SIP integrity mechanisms that place a
signature over the entire message body in a SIP message header. Were
a server to modify the body of a message that was protected by such
signature, that would be perceived as an integrity violation by
downstream recipients of the message. Presumably, a back-to-back
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 4.3 Using Content Indirection
Work [8] is currently underway in the SIP WG to define a content Work is currently underway in the SIP WG to define a content
indirection mechanism for SIP, a mechanism by which a MIME body in a indirection [8] mechanism for SIP, a mechanism by which a MIME body
SIP request can refer, with a URL, to a document that it hosted in a SIP request can refer, with a URL, to a document that it hosted
somewhere in the network. This raises another interesting somewhere in the network. This raises another interesting
possibility for authentication token management. possibility for authentication token transport in SIP.
A SIP user agent could create a content indirection MIME body (using A SIP user agent could create a content indirection MIME body (using
the RFC2017 [9] URL MIME External-Body Access-Type) that contains a the RFC2017 [9] URL MIME External-Body Access-Type) that contains a
URL that identities a resource controlled by the authentication URL that identities a resource controlled by the authentication
service, anticipating that the authentication service will make the service, anticipating that the authentication service will make the
authentication token available at that URL. Authentication services authentication token available at that URL. This URL could be pushed
could define a standard way to anticipate URIs for a particular by the authentication service to the UAC when the authentication
request (for example, an HTTP URL could be structured with a hostname service challenges the UAC (as a new header in the 407 response).
corresponding to the authentication service, and a path corresponding Once an authentication service has validated the request, it simply
to a unique identifier selected by the user agent for this request: makes the authentication token available at the anticipated URL;
http://auth-serv.biz/12345678901234567890). Once an authentication recipients of the message would then dereference the URL in order to
service has validated the request, it simply makes the authentication inspect the token.
token available at the anticipated URL; recipients of the message
would then dereference the URL in order to inspect the token.
This approach could allow user agents to have full control over the This approach could allow user agents to have full control over the
integrity of SIP requests, while still not requiring the extra RTT integrity of SIP requests, while still requiring the extra RTT caused
caused by the use of the 428 response code. It also has numerous by the use of the 428 response code. It also has numerous advantages
advantages over other ways of handling authentication tokens issued over other ways of handling authentication tokens issued for SIP
for SIP response messages (see Section 5). response messages (see Section 5).
5. Identity in Responses 5. Identity in Responses
Many of the practices described in the preceding sections can be Many of the practices described in the preceding sections can be
applied to responses as well as requests, with some important applied to responses as well as requests, with some important
differences. Primarily, the distinction is that a response cannot be differences. Primarily, the distinction is that a response cannot be
challenged or resubmitted in the same manner as a request. However, challenged or resubmitted in the same manner as a request, and
when a user agent registers under a particular identity, and thereby 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 becomes eligible to receive requests and send responses associated
with that identity, it provides credentials that prove its identity, with that identity, it provides credentials that prove its identity,
and thus the registrar is in a reasonable position to act as an and thus if the registrar is co-located with the proxy that receives
authentication service for responses. 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 Note that the identity in an authentication token in a response
almost certainly will not correspond with identity asserted in the almost certainly will not correspond with the identity asserted in
From header field of the response (which is copied from the Request); the From header field of the response (which is copied from the
the identity in the authentication token represents a different request); the identity in the authentication token represents a
entity. In many network implementations, the identity in the different entity. For many requests, the identity in the
authentication token of a response will correspond to the To header authentication token of a response will correspond to the To header
field of the request, but there are numerous legitimate architectures field of the request, but there are numerous legitimate ways that
(which contain redirections) in which this will not be the case. requests can be retargeted in which this will not be the case.
An authentication service that acts as a registrar can add to a An authentication service that also acts as a registrar and inbound
response an authentication token that corresponds to the identity of proxy can add to a response an authentication token that corresponds
the originator of that response in roughly the same manner described to the identity of the originator of that response in roughly the
in Section 4.1 - the authentication service adds the authentication same manner described in Section 4.2 - the authentication service
token to a response before it forwards the response towards the adds the authentication token to a response before it forwards the
originator of the request. There is no way for an authentication response towards the originator of the request. There is no way for
service to perform a function for responses comparable to the an authentication service to perform a function for responses
mechanism described in Section 4.2; however, content indirection (see comparable to the mechanism described in Section 4.1; however,
Section 4.3 could provide an alternative that would allow the client content indirection (see Section 4.3 could provide an alternative
to retain end-to-end integrity properties on responses. that would allow the client to retain end-to-end integrity properties
on responses.
6. Receiving an Authentication Token 6. Receiving an Authentication Token
The manner in which an authentication token is handled is dependent The manner in which an authentication token is handled is dependent
on the nature of the token itself; for rules for handling the on the nature of the token itself; rules for handling the
Authentication Identity Body (AIB) format, see [4]. Authenticated Identity Body (AIB) format are given [4].
6.1 Authentication Service Handling of Authentication Tokens 6.1 Authentication Service Handling of Authentication Tokens
SIP intermediaries generally should not attempt to inspect MIME SIP intermediaries generally should not attempt to inspect MIME
bodies; following the rules of RFC3261 Section 16.6, MIME bodies may bodies; following the rules of RFC3261 Section 16.6, MIME bodies may
be encrypted end-to-end or have other properties that make them be encrypted end-to-end or have other properties that make them
unsuitable for consumption by intermediaries. However, unsuitable for consumption by intermediaries. However,
intermediaries that implement the authentication service logical role intermediaries that implement the authentication service logical role
MAY inspect MIME bodies in order to find one with a Content- MAY inspect MIME bodies in order to find one with a Content-
Disposition of 'auth-id'. Disposition of 'auth-id'.
For the most part, the actual value of an authenticated identity is For the most part, the actual value of an authenticated identity is
not likely to be of interest to a proxy server, though it MAY refuse not likely to be of interest to a proxy server, though it MAY refuse
to process a request that does not contain a valid authentication to process a request that does not contain a valid authentication
token (using the 428 request, as described in Section 4.2). However, token (using the 428 request, as described in Section 4.1). However,
proxy servers MAY additionally maintain lists of known problem users authentication services MAY additionally maintain lists of known
that are banned from making requests to their administrative domain, problem users that are banned from making requests to their
for example, and subsequently reject some requests after comparing administrative domain, for example, and subsequently reject some
their authenticated identities to such access control lists. requests after comparing their authenticated identities to such
access control lists.
7. Selective Sharing of Identity 7. Selective Sharing of Identity
Most of the time, there is no need to restrict the propagation of Most of the time, there is no need to restrict the propagation of
verified identities in the network. User agents and intermediaries verified identities in the network. User agents and intermediaries
benefit from receiving verified identities. However, in some cases benefit from receiving verified identities. However, in some cases
intermediaries might want to restrict the distribution of identity intermediaries might want to restrict the distribution of identity
information, for example if information, for example if
o the authenticated identity body contains an identity that is only o the authenticated identity body contains an identity that is only
meaningful as an internal identifier within a particular service meaningful as an internal identifier within a particular service
provider's network, or, provider's network, or,
o the originating user agent has requested privacy, and the o the originating user agent has requested privacy, and the
unrestricted distribution of the authenticated identity body would unrestricted distribution of the authenticated identity body would
violate that request. violate that request.
If it is not appropriate to share an authenticated identity, an If it is not appropriate to share an authenticated identity because a
authenticated identity body SHOULD NOT be created and distributed. user has requested privacy, an authenticated identity body SHOULD NOT
However, in some cases there may be other entities in the be created and distributed. However, in some cases there may be
administrative domain of the authentication service that are other entities in the administrative domain of the authentication
consumers of the authenticated identity. If, for example, each of service that are consumers of the authenticated identity. If, for
these servers needed to challenge the user individually for identity, example, each of these servers needed to challenge the user
it might significantly delay the processing of the request. For that individually for identity, it might significantly delay the
reason, it may be appropriate to circulate authenticated identity processing of the request. For that reason, it may be appropriate to
bodies among a controlled set of entities. For that purpose, an circulate authenticated identity bodies among a controlled set of
encryption mechanism for authenticated identities is required. entities. For that purpose, an encryption mechanism for
authenticated identities is required.
7.1 Requesting Privacy 7.1 Requesting Privacy
When users authenticate themselves to an authentication service, they When users authenticate themselves to an authentication service, they
MAY use SIP to explicitly notify the service that they do not wish MAY explicitly notify the service that they do not wish their
their authenticated identity to be circulated. Usually, the user in authenticated identity to be circulated. Usually, the user in
question would also be taking other steps to preserve their privacy question would also be taking other steps to preserve their privacy
(perhaps by including an anonymous From header in the SIP request, (perhaps by including an anonymous From header in the SIP request,
and following other standard privacy practices). and following other standard privacy practices).
Authentication services MUST support the privacy mechanism described Authentication services MUST support the privacy mechanism described
in [3]. Users requesting privacy should also support the mechanisms in RFC3323 [3]. Users requesting privacy should also support the
described in that document. mechanisms described in that document.
In particular, this document uses an identity-specific priv-value In particular, this document uses an identity-specific priv-value
that can appear in the Privacy header, a value of 'id', which was that can appear in the Privacy header, a value of 'id', which was
registered by [6]. This Privacy value requests that the results of registered by RFC3325 [6]. This Privacy value requests that the
authentication should not be shared by the authenticating server. An results of authentication should not be shared by the authenticating
authentication service SHOULD NOT create an authentication token for intermediary. An authentication service SHOULD NOT create an
a request when 'id' privacy has been requested. If such a token is authentication token for a request when 'id' privacy has been
created, it MUST be encrypted or rendered confidential in the manner requested. If such a token is created, it MUST be encrypted or
most appropriate to the token. Guidelines for encrypting AIBs are rendered confidential in the manner most appropriate to the token.
given in [4], and these mechanisms MUST be supported by any Guidelines for encrypting AIBs are given in [4], and these mechanisms
authentication service that uses AIBs. MUST be supported by any authentication service that uses AIBs.
8. Security Considerations 8. Security Considerations
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 a network or transport layer security protocol such as
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 lower-layer protocol that authentication service over this lower-layer protocol that
corresponds to the expected domain (especially when they receive a corresponds to the expected domain (especially when they receive a
challenge via a mechanism such as Digest), then it is possible that a challenge via a mechanism such as Digest), then it is possible that a
skipping to change at page 11, line 44 skipping to change at page 12, line 10
reach the remote server. reach the remote server.
Relying on an authentication token generated by a remote Relying on an authentication token generated by a remote
administrative domain assumes that the domain uses some trustworthy administrative domain assumes that the domain uses some trustworthy
practice to authenticate its users. However, it is possible that practice to authenticate its users. However, it is possible that
some domains will implement policies that effectively make users some domains will implement policies that effectively make users
unaccountable (such as accepting unauthenticated registrations from unaccountable (such as accepting unauthenticated registrations from
arbitrary users). Therefore, it is RECOMMENDED that authentication arbitrary users). Therefore, it is RECOMMENDED that authentication
tokens contain some indication of the specific practice (for example, tokens contain some indication of the specific practice (for example,
Digest) that was used to authenticate this request as a rough Digest) that was used to authenticate this request as a rough
indicator of credential strength. 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 If a common certificate is used by an authentication service (rather
than individual certificates for each identity), certain problems can than individual certificates for each identity), certain problems can
arise with name subordination. For example, if an authentication arise with name subordination. For example, if an authentication
service holds a common certificate for the hostname 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'.
skipping to change at page 12, line 42 skipping to change at page 13, line 10
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 9. IANA Considerations
This document defines a new SIP status code, '428 Use Authentication This document defines a new SIP status code, '428 Use Authentication
Token'. The use of this status code is further described in Section Token'. The use of this status code is further described in Section
4.2. 4.1.
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.
[3] Peterson, J., "A Privacy Mechanism for the Session Initiation [3] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", draft-ietf-sip-privacy-general-02 (work in Protocol (SIP)", RFC 3323, November 2002.
progress), June 2002.
[4] Peterson, J., "SIP Authenticated Identity Body (AIB) Format", [4] Peterson, J., "SIP Authenticated Identity Body (AIB) Format",
draft-ietf-sip-authid-body-00 (work in progress), October 2002. draft-ietf-sip-authid-body-01 (work in progress), October 2002.
Informative References Informative References
[5] Kohl, J. and C. Neumann, "The Kerberos Network Authentication [5] Kohl, J. and C. Neumann, "The Kerberos Network Authentication
Service (V5)", RFC 1510, September 1993. Service (V5)", RFC 1510, September 1993.
[6] Jennings, C., Peterson, J. and M. Watson, "Private Extensions to [6] Jennings, C., Peterson, J. and M. Watson, "Private Extensions to
the Session Initiation Protocol (SIP) for Asserted Identity the Session Initiation Protocol (SIP) for Asserted Identity
within Trusted Networks", draft-ietf-sip-asserted-identity-02 within Trusted Networks", RFC 3325, November 2002.
(work in progress), June 2002.
[7] Sparks, R., "Internet Media Type message/sipfrag", draft-ietf- [7] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420,
sip-sipfrag-00 (work in progress), September 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 Author's Address
skipping to change at page 14, line 32 skipping to change at page 15, line 4
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 (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). 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/