WDIFF

draft-ietf-sip-identity-01.txt --> draft-ietf-sip-identity-02.txt

SIP WG J. Peterson
Internet-Draft NeuStar
Expires: August 2, 2003 February 2003 November 15, 2004 C. Jennings
Cisco Systems
May 17, 2004

Enhancements for Authenticated Identity Management in the Session
Initiation Protocol (SIP)
draft-ietf-sip-identity-01
draft-ietf-sip-identity-02

Status of this Memo

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on August 2, 2003. November 15, 2004.

Abstract

The existing security mechanisms for expressing identity in the Session Initiation Protocol oftentimes do not permit an administrative domain
to verify securely
are inadequate for cryptographically assuring the identity of the originator of a request. end
users that originate SIP requests and responses, especially in an
interdomain context. This document recommends practices and
conventions for authenticating identifying end
users, users in SIP messages, and proposes a
way to distribute cryptographically secure authenticated identities within SIP messages. identities.

Peterson & Jennings Expires August 2, 2003 November 15, 2004 [Page 1]

Internet-Draft SIP Identity February 2003 May 2004

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3
3. Using an Authentication Service Background . . . . . . . . . . . . . . . 5
4. How to Share Verified Identities . . . . . . . . . . . 3
4. Requirements . . . . 5
4.1 Body Added by Client . . . . . . . . . . . . . . . . . . . . . 7
4.2 Body Added by Authentication Service 5
5. Overview of Operations . . . . . . . . . . . . . 8
4.3 Using Content Indirection . . . . . . . 6
6. User Agent Behavior: Sending Messages . . . . . . . . . . . 8
5. Identity in Responses . 7
7. Authentication Service Behavior . . . . . . . . . . . . . . . 7
7.1 UAs acting as an Authentication service . . . . . . . . . . . 9
6. Receiving an Authentication Token
8. Verifying Identity . . . . . . . . . . . . . . 10
6.1 Authentication Service Handling of Authentication Tokens . . . 10
7. Selective Sharing of Identity . . . . . 9
9. Proxy Server Behavior . . . . . . . . . . . . . . . . . . . . 10
7.1 Requesting Privacy
10. Header Syntax . . . . . . . . . . . . . . . . . . . . . . 11
8. . . 12
11. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. 13
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 17
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 17
Normative References . . . . . . . . . . . . . . . . . . . . . 13 16
Informative References . . . . . . . . . . . . . . . . . . . . 13 16
B. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 14 17
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 16 19

Peterson & Jennings Expires August 2, 2003 November 15, 2004 [Page 2]

Internet-Draft SIP Identity February 2003 May 2004

1. Introduction

This document provides enhancements to the existing mechanisms for
authenticated identity management in the Session Initiation Protocol
(SIP [1]). An identity, for the purposes of this document, is
defined as a canonical SIP address-of-record URI employed to reach a
user (such as 'sip:alice@atlanta.com').

RFC3261 enumerates a number of places within a SIP request that a
user can express an identity for themselves, notably the user-
populated From header field. However, the recipient of a SIP request
has no way to verify that the From header field has been populated appropriately without
accurately, in the absence of some sort of cryptographic
authentication mechanism.

Today,

RFC3261 specifies a number of security mechanisms that can be
used
employed by SIP UAs, including Digest, TLS and S/MIME (and
implementations
(implementations may support other security schemes as well).
However, few SIP user agents today can support the end-user certificates
necessary to authenticate themselves via TLS or S/MIME, and
furthermore Digest authentication is limited by the fact that the
originator and destination must share a pre-arranged secret. It is
desirable for SIP user agents to be able to send requests to
destinations with they have no previous association - just as in the
telephone network today, one can receive a call from someone with
whom one has no previous association, and still have a reasonable
assurance that their displayed Caller-ID is accurate.

Many

2. Terminology

In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in RFC2119 [2] and indicate requirement levels for
compliant SIP implementations.

3. Background

All RFC3261-compliant SIP user agents today 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
URI with which a SIP UA user commonly populates the From header of requests from
that user
- in other words, the address-of-record is an identity. So in this context

Peterson & Jennings Expires November 15, 2004 [Page 3]

Internet-Draft SIP Identity May 2004

context, users already have a means of providing their identity,
which makes good sense: since the contents of a From header field are
essentially a 'return address' for SIP requests, being able to prove
that you are eligible to receive requests for that 'return address'
should be identical to proving that you are authorized to assert this
identity.

However, the credentials with which a user agent proves their
identity to a registrar that they are, for example, an authorized recipient of
requests for 'sip:alice@atlanta.com' will not cannot be accepted validated by a user agent or proxy
server
in another outside your local domain - these credentials are currently
only useful for

Peterson Expires August 2, 2003 [Page 3]

Internet-Draft SIP Identity February 2003

local registration. What other domains really want to know about
your identity is that you are capable For the purposes of authenticating yourself determining
whether or not the 'return address' of a request can legitimately be
asserted as the identity of the user, SIP entities in
your other domains
require an assurance that the sender of a message is capable of
authenticating themselves to a registrar in their own domain.

Ideally, then, there SIP user agents should be have some way of proving to remote domains
recipients of SIP messages that your their local domain has authenticated you.
them. In the absence of end-
user 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 such requests (using the same practices by which
the domain would authenticate REGISTER requests). Once a request message has
been authenticated, the local domain then needs some way to
communicate to remote domains that it
has sanctioned other SIP entities the request. sending user has been
authenticated. This draft addresses how that identity imprimatur of
authentication can could be securely shared.

RFC3261 already describes an architecture very similar to this in
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
proxy server via mutual TLS, creating a two-link chain of transitive
authentication between the originator and the remote domain. While
this works well in some architectures, there are a few respects in
which this is impractical. For one, it transitive trust in inherently
weaker than an assertion that can be validated end-to-end. It is
possible for SIP requests to cross multiple intermediaries in
separate administrative domains, in which case transitive trust
becomes far even less compelling. It also requires intermediaries to act
as proxies, rather than redirecting requests to their destinations
(redirection lightens loads on SIP intermediaries). Both of these limitations result from the fact that
authentication takes place outside the application, at the transport
layer, rather than within SIP itself.

One solution to this problem is to use 'trusted' SIP intermediaries
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) is given in [6]. However, this solution allows only hop-by-
hop trust between intermediaries, not end-to-end cryptographic
authentication, and it assumes a managed network of nodes with strict

Peterson & Jennings Expires November 15, 2004 [Page 4]

Internet-Draft SIP Identity May 2004

mutual trust relationships, an assumption that is incompatible with
widespread Internet deployment.

The desired mediated authentication architecture has quite a bit in
common with the problem space of Kerberos [5]. Ideally, there should
be

Accordingly, a way new tactic is required for sharing a user cryptographic
assurance of end-user identity in an intradomain context.
Furthermore, this new mechanism must work for both SIP requests and
responses. However, there is an additional wrinkle specific to authenticate themselves
providing identity in a response. While the original address-of-
record to which a request is sent is stored in the local domain,
and receive some kind of token that they can share with recipients To header field of
requests that lets them know
the request, it is possible, due to retargeting at intermediaries, it
is possible that the user request will be forwarded to an entity that has been authenticated by
a different AoR (i.e. identity). Since the local domain. However, Kerberos support in SIP user agents To header is not widespread, and moreover SIP uses other means (such as Digest) changed
in responses to
perform key authentication functions already. An ideal solution
would adapt existing a SIP security mechanisms to address this problem.

Peterson Expires August 2, 2003 [Page 4]

Internet-Draft SIP Identity February 2003

Therefore, this document defines a new logical role for SIP network
intermediaries called an 'authentication service'. Once an
authentication service request, the UAC has verified no way of discovering that
new AoR. This is generally known as the "response identity" or
"connected party" problem.

4. Requirements

This draft addresses the following requirements:

The mechanism must allow a UAC to provide a strong cryptographic
identity of assurance to the originator of UAS in a request, as described above, it creates request.

The mechanism must allow a UAS to provide a strong cryptographic token
identity assurance to the UAC in a response.

User agents that
contains receive identity assurances must be able to
validate these assurances without performing any network lookup.

Proxy servers must be capable of adding this identity assurance to
requests or responses.

The mechanism must prevent replay of the authenticated identity assurance by an
attacker.

The mechanism must be capable of protecting the user, and which has some
reference integrity with of SIP
message bodies (to ensure that media offers and answers are linked
to the request itself. This token can then signaling identity).

It must be
added possible for a user to have multiple AoRs (i.e.
accounts or aliases) under which it is known at a SIP request domain, and inspected for
the UAC to assert one identity while authenticating itself as
another, related, identity, as permitted by recipients the local policy of
the domain.

It must be possible, in cases where a request who
need has been retargeted
to a cryptographic guarantee of different AoR than the identity of one designated in the user.

One possible format To header field,
for such tokens is the Authenticated UAC to ascertain the AoR to which the request has been

Peterson & Jennings Expires November 15, 2004 [Page 5]

Internet-Draft SIP Identity
Body (AIB) May 2004

sent.

5. Overview of Operations

This section provides an informative (non-normative) high-level
overview of the mechanisms described in [4]. Other token formats are a matter for
further investigation. Throughout this document, document.

Imagine the use case where Alice, who has the home proxy of AIB
format for example.com
and the token is considered exclusively. Only tokens that are
suitable address-of-record sip:alice@example.com, wants to be carried in a MIME body are considered in this
document.

2. Terminology

In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", communicate
with sip:bob@example.org.

Alice generates an INVITE and "OPTIONAL" are to be interpreted as
described places her identity in RFC2119 [2] and indicate requirement levels for
compliant SIP implementations.

3. Using an Authentication Service

A SIP user agents the From header
field of the request. She then sends requests to an authentication service in
order INVITE over TLS to receive an authentication token for the request. How
exactly the association with an
authentication service is learned or
configured is an implementation-specific matter proxy for the user agent -
it might be implemented with a pre-loaded Route header. her domain.

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
services authenticates requests. Since Digest authentication MUST be
supported Alice (possibly by all SIP entities, the use of sending a
Digest for this purpose authentication challenge) and validates that she is
RECOMMENDED for compatibility with authorized
to populate the maximum set value of user agents.

4. How to Share Verified Identities

When an authentication service has authenticated the user, From header field (which may be Alice's
AoR, or it must
construct an identity URI for that user that will may be contained in the
token. It is RECOMMENDED some other value that these identities take the form of SIP

Peterson Expires August 2, 2003 [Page 5]

Internet-Draft SIP Identity February 2003

address-of-record URI (as opposed to contact addresses), as they are
defined in Section 10 of RFC3261; in other words, URIs policy of the form
'sip:alice@atlanta.com'.

This identity must be expressed in the authentication token that will
be signed by the authentication service. For example, if the
Authenticated Identity Body (AIB) format described in [4] is used, proxy
server permits her to use). It then for an INVITE this identity would be stored in computes a hash over some
particular headers, including the From header 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
subject of and the certificate SHOULD be assigned bodies in one of
the two
following ways:

An authentication service MAY use a common certificate, such as a
site certificate, for its administrative domain. The
subjectAltName of this certificate MUST correspond message. This hash is signed with the host
portion of certificate for the From domain
(example.com, in Alice's case) and inserted in a header field of the identity (the
new Identity header) in the
authentication token (if SIP message. The proxy, as the identity were
'sip:alice@atlanta.com', holder
the subjectAltName private key of its domain, is asserting that the certificate
would be 'atlanta.com'); originator of
this should be the same certificate request has been authenticated and that she is authorized to
claim the authentication service provides when proving its own identity
(via TLS or some similar protocol).

An authentication service MAY hold (the SIP address-of-record) which appears in the
From header field. The proxy also inserts a certificate corresponding companion header field
that tells Bob how to
each user in acquire its administrative domain (in other words, a
certificate whose subjectAltName contains certificate, if he doesn't already
have it.

When Bob returns a URI equivalent response to the
address-of-record URI INVITE (such as a 200 OK), a
similar set of steps happen. Bob's home proxy asserts his identity
in the user). response. In this case, the appropriate
certificate for instance, the authenticated user will be used proxy has to sign the
authentication token. Maintaining individual certificates for
each user is RECOMMENDED, since insert the name subordination rules
involved with
header directly into the use request - redirection of a common certificate for the domain can
become complicated.

After the authentication token has been signed, the authentication
token MUST somehow be integrated with any existing MIME bodies in the
request, if necessary by transitioning the outermost MIME body to a
'multipart/mixed' format, before responses is not
possible. When Alice receives the response, she verifies Bob's
identity.

If Alice's request can be forwarded. Three
options are considered for ways that an authentication token could be
added Bob were retargeted, one of two things might
happened. If it were retargeted to a SIP message: one in which the authentication service
pushes domain that was also the token back
responsibility of Bob's home proxy (for example, retargeted from
sip:bob@example.com to sip:carol@example.com), then the client for resubmission, one in which
the authentication service adds the token itself, request would
proceed normally and one in which
the client anticipates a URI at which the authentication service will
make receive an Identity. If Bob's home proxy would
retarget the token available. Authentication services MUST support request to some other domain (e.g.
sip:bob@example.ORG), then his home proxy would redirect the
mechanism in Section 4.1 request
rather than proxying it, and MAY support the mechanism in Section
4.2; the mechanism in Section 4.3 is included to illustrate Alice would send a new request that
could receive a future
direction. response with an Identity from the new domain.

Peterson & Jennings Expires August 2, 2003 November 15, 2004 [Page 6]

Internet-Draft SIP Identity February 2003

4.1 Body Added by Client

In this case, the authentication service returns the authentication
token May 2004

6. User Agent Behavior: Sending Messages

This mechanism requires one important change to the originating user agent, prompting the existing user agent
behavior for sending requests and responses: user agents using this
mechanism to
retry the request send requests or responses MUST support TLS; moreover,
they MUST be capable of establishing a persistent TLS connection with the
a proxy server that acts as an authentication token attached. No
existing SIP mechanism can perform this function. Therefore, service. Additionally,
there are several practices that should be highlighted in the context
of this
document defines identity solution.

When a 428 "Use Authentication Token" response code.

After UAC sends a user has been authenticated (in the Digest example, with request, it MUST accurately populate the
407 response) an authentication service sends a 428 with a MIME body
in order to request header
field that asserts its identity (for a user agent add SIP request, this is the enclosed MIME body to
their From
header field). In a request and retry the request. A 428 it MUST have at most set the URI portion of its From
header to match a
single MIME body. This MIME body SIP, SIPS or TEL URI AoR under which the UAC can
register (including anonymous URIs, as described in RFC 3323 [3]).
The UAC MUST also be signed by the capable of sending requests through an
'outbound' proxy (the authentication service.

The use service), and of 428 without any MIME body is also defined course MUST
support the Digest authentication mechanism described in RFC3261.
Because this
document. It can be sent by any server to reject a request because
the request mechanism does not contain an provide integrity protection for the
first hop to the authentication token. A user agent
receiving this rejection SHOULD retry their request through service, the same
server after acquiring a token from UAC MUST send requests
to an authentication service.

In service only over a TLS connection.
Additionally, in order to signal to the authentication services and other
intermediaries that the originating provide identity for responses, user agent supports the receipt
of the 428 response code, a new option-tag has been defined, the
'auth-id' option-tag. User agents SHOULD supply the 'auth-id'
option-tag in
MUST form a Supported header whenever they provide credentials persistent TLS connection to a proxy server (for example, in Digest authentication, whenever when a Proxy-
Authorization header
REGISTER is added to sent.

Since a UAS cannot send a request).

Using the 428 response code may introduce extra round-trip times for
messages, delaying the setup of requests. However, there are some
circumstances under which extra RTTs may that does not impede performance. If replicate the originating user agent possesses a non-stale nonce (assuming
Digest authentication) from
contents of the authentication service, it can pre-
emptively include a Proxy-Authorization header, eliminating one RTT
(the one resulting from a 407). With regard to To and From header fields in the second RTT, note
that corresponding
request, UAS response-sending behavior is unchanged. Again, because
this mechanism does not provide integrity protection for the request needn't necessarily go through first
hop of the authentication
service again once response path, the UAS SHOULD send responses only over a
TLS connection.

7. Authentication Service Behavior

The authentication token has been added - it could
go directly to its destination, which reduce service authenticates the impact identity of the second
RTT.

There are two good reasons to think message
sender and validates that the originating user agent
should identity given in the message can
legitimately be asserted by the party responsible for adding sender. Then it computes a signature
over the authentication token
to canonical form of several headers and all the request. Firstly, because bodies, and
inserts this gives signature into the client message.

First, an authentication service MUST extract the
opportunity to inspect identity of the body itself (perhaps only
sender. For requests, it inspects the From header field; for
responses, the To header field (henceforth the result of this
inspection will be referred to see whether as the "identity field). If the
identity field contains a SIP or not it is encrypted; see [4]) SIPS URI, the authentication service
MUST extract the hostname portion of the URI in order to verify that header field,
and compare this to the domain(s) for which it is responsible. If
the
authenticated identity corresponds with field uses the provided credentials and TEL URI scheme, the user's preferences. Secondly, policy of the client can provide a signature

Peterson & Jennings Expires August 2, 2003 November 15, 2004 [Page 7]

Internet-Draft SIP Identity February 2003

over the entire body of the message (either with S/MIME May 2004

authentication service determines whether 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

Another possibility not it is that responsible
for this identity. Some example policies are described in [TODO].
If the authentication service could add the
body to is not responsible for the request itself before forwarding the request. However, identity in
question, it MAY handle the authentication service role is usually played by entities that
act request as a normal proxy servers server; see
below for most requests, and proxy servers cannot
modify message bodies (see RFC3261 Section 16.6). In order to add an more information on authentication token, service handling of an
existing Identity header.

Second, the authentication service needs to act as a
transparent back-to-back user agent, effectively terminating must determine whether or not the
sender of the request and re-originating it with a new body appended is authorized to any
existing MIME bodies (again, transposing claim the identity given in
the identity field. In order to various MIME multipart
forms as necessary).

This mechanism has some potential advantages over pushing do so, the authentication token back to service
MUST authenticate the originating user agent. For one, it
saves one additional round-trip time that would be used by sender of the 428
response. It also requires no new SIP mechanisms, whereas message. Some possible ways in
which this authentication might be performed include:

For requests, challenging the 428 request with a 407 response necessitates option-tag support.

However, there are proposed SIP integrity mechanisms that place code
using the Digest authentication scheme (or viewing a
signature over Proxy-
Authentication header sent in the entire message body request which was sent in
anticipation of a SIP message header. Were challenge using cached credentials, as described
in RFC 3261 Section 22.3)

For requests and responses that are sent over a server to modify persistent TLS
connection, relying on some prior authentication that was
performed at the body formation of the connection (most likely, the
authentication service previously challenged a message that REGISTER request
sent after the TLS connection was protected by such
signature, formed, or possibly a prior
challenged INVITE that would be perceived as an integrity violation by
downstream recipients was sent over the TLS connection)

Authorization of the message. Presumably, assertion of a back-to-back
user agent function would have to sacrifice this end-to-end
integrity. The notion particular username in the From
header field 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

Work is currently underway in the SIP WG to define a content
indirection [8] mechanism matter of local policy for SIP, a mechanism by the
authorization service which a MIME body
in a SIP request can refer, with a URL, to a document that it hosted
somewhere depends greatly on the manner in which
authentication is performed. A RECOMMENDED policy is as follows: the network. This raises another interesting
possibility for
username asserted during Digest authentication token transport MUST correspond
exactly to the username in SIP.

A the From header field of the SIP user agent could create message.
However, there are many cases in which a content indirection MIME body (using user might manage multiple
accounts in the RFC2017 [9] URL MIME External-Body Access-Type) that contains same administrative domain. Accordingly, provided
the authentication service is aware of the relationships between
these accounts, it might allow a
URL that identities user providing credentials for one
account to assert a resource username associated with another account
controlled by the authentication
service, anticipating that user name. Furthermore, if the authentication service will make AoR asserted in the
authentication token available at
From header field is anonymous (per RFC3323), then the proxy should
authenticate that URL. This URL could be pushed
by the user is any valid user in the domain and insert
the signature over the From header field as usual.

Third, the authentication service MUST form the identity signature,
as described in Section 10, and add an Identity header to the UAC when request
containing this signature. After the Identity header has been added
to the request, the authentication service MUST also add an Identity-
Info header. The Identity-Info header contains a URI from which its
certificate can be acquired. Details are provided in section Section

Peterson & Jennings Expires August 2, 2003 November 15, 2004 [Page 8]

Internet-Draft SIP Identity February 2003

service challenges the UAC (as a new header in May 2004

10.

Finally, the 407 response).
Once an authentication service has validated the request, it simply
makes the authentication token available at the anticipated URL;
recipients of MUST forward the message would then dereference the URL
normally.

7.1 UAs acting as an Authentication service

There are some instances in order to
inspect the token.

This approach could allow which a user agents to have full control over the
integrity of SIP requests, while still requiring the extra RTT caused
by agent may hold the use private
key of the 428 response code. It also has numerous advantages
over other ways of handling authentication tokens issued domain Certificate for SIP
response messages (see Section 5).

5. Identity in Responses

Many of its address-of-record. In these
cases, the practices described in UA MAY perform the preceding sections can be
applied to responses as well as requests, with some important
differences. Primarily, services, and add the distinction is headers, 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
authentication service would normally add.

8. Verifying Identity

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 or proxy that server receives
requests for the user's administrative domain, is in a reasonable
position to act as SIP message containing
an authentication service for responses.

Note that Identity header, it can inspect the signature to verify the
identity in of the sender of the message. If an authentication token Identity header is not
present in a request, and one is required by local policy, then a 428
Use Identity response
almost certainly will is sent. If an Identity header is not correspond with the identity asserted present
in a response, and one is required by local policy, then the From header field
recipient of the response (which is copied from the
request); MUST communicate this lapse to its user,
and MAY immediately terminate any created dialog or ignore
transactions, as policy dictates.

In order to verify the identity in of the authentication token represents sender of a
different entity. For many requests, message, the identity in user
agent or proxy server MUST first acquire the
authentication token certificate for the
signing domain. Implementations supporting this specification should
have some means of a response will correspond retaining domain certificates (in accordance with
normal practices for certificate lifetimes and revocation) in order
to prevent themselves from needlessly downloading the To 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 of value.

Provided that the request, but there are numerous legitimate 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
requests can be retargeted in which this will it has not be the case.

An authentication service expired, that also acts as a registrar and inbound
proxy can add the chain
is valid back to a response an authentication token trusted CA, and that corresponds
to it does not appear on
revocation lists.

Subsequently, the identity of recipient MUST verify the originator of that response signature in roughly the
same manner described in Section 4.2 - Identity
header, and compare the authentication service
adds identity of the authentication token to a response before it forwards signer (the subjectAltName of
the
response towards certificate) with the originator domain portion of the request. There is no way for
an authentication service to perform a function for responses
comparable to URI in the mechanism From
header field of the request as described in Section 4.1; however,
content indirection (see 11.
Additionally, the Date, Contact and Call-ID headers MUST be analyzed
in the manner described in Section 4.3 could provide an alternative 11; recipients that would allow the client wish to retain end-to-end integrity properties
on responses. verify
Identity signatures MUST support all of the operations described

Peterson & Jennings Expires August 2, 2003 November 15, 2004 [Page 9]

Internet-Draft SIP Identity February 2003

6. Receiving an Authentication Token

The manner in which an authentication token is handled is dependent
on May 2004

there. Any discrepancies or violations MUST be reported to the nature of the token itself; rules for handling user.

When the originating user agent of a request receives a response
containing an Authenticated Identity Body (AIB) format are given [4].

6.1 Authentication Service Handling (AIB, see [4]), it SHOULD
compare the identity in the From header field of Authentication Tokens

SIP intermediaries generally should not attempt to inspect MIME
bodies; following the rules AIB of RFC3261 Section 16.6, MIME bodies may
be encrypted end-to-end or have other properties that make them
unsuitable for consumption by intermediaries. However,
intermediaries that implement the authentication service logical role
MAY inspect MIME bodies in order to find one
response with a Content-
Disposition the original value of 'auth-id'.

For the most part, To header field in the actual value
request. If these represent different identities, the user agent
SHOULD render the identity in the AIB of an authenticated the response to its user.
Note that a discrepancy in these identity fields is not likely to be necessary an
indication of interest a security breach; normal retargeting may simply have
directed the request to a proxy server, though different final destination. Implementers
therefore may consider it MAY refuse unnecessary to process alert the user of a security
violation in this case.

9. Proxy Server Behavior

In most respects, a proxy server behaves normally when it receives a
SIP request that does not contain or response containing an Identity header. This
mechanism is fully backwards-compatible with existing RFC3261 proxy
behavior. However, if a valid authentication
token (using the 428 request, proxy intends to act as described in Section 4.1). However, an authentication services MAY additionally maintain lists of known
problem users that are banned from making requests to their
administrative domain,
service for example, and subsequently reject some responses to requests after comparing their authenticated identities it receives, it must exhibit some
additional behavior to such
access control lists.

7. Selective Sharing of ensure that retargeting requests are handled
properly. Essentially, a proxy server MUST NOT provide an Identity

Most of the time, there
header for a request that it retargets to a different administrative
domain. It is no need the responsibility of that administrative domain to restrict
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.

If a proxy server intends to act as an authentication service for a
response to a SIP request that it is forwarding, it MUST do ALL of
the following:

Ascertain if it is responsible for the domain indicated in the
Request-URI field of the request. If not, it MUST forward the
request normally. If so, it must then:

Determine the route set of targets to which this request might be
forwarded. From that target list, the proxy must determine which
contact addresses are associated with persistent TLS connections
that have been established to the proxy server. It places all
such targets (if any) into a primary route set for the call, and
places remaining targets into a secondary route set for the call.
It performs this operations irrespective of any qvalues associated

Peterson & Jennings Expires November 15, 2004 [Page 10]

Internet-Draft SIP Identity May 2004

with the contact addresses.

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.

If there are no appropriate responses from the primary route set
for the proxy server to forward upstream, it moves on to the
secondary route set (essentially, the proxy server forks
sequentially, exploring the primary route set as one cluster, and
then moves on to the secondary set). The proxy server is unable
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.

In order to build the primary route set for the call, the location
service associated with the domain of the proxy server MUST implement
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.

Additionally, domain policy may require proxy servers to inspect and
verify the identity provided in SIP requests. The proxy server may
wish to ascertain the identity of the sender of the message to
provide spam prevention or call control services. Even if a proxy
server does not act as an authentication service, it MAY verify the
signature present in an Identity header before it makes a forwarding
decision for a request. Proxy servers MUST NOT remove or modify the
Identity or Identity-Info headers.

Peterson & Jennings Expires November 15, 2004 [Page 11]

Internet-Draft SIP Identity May 2004

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.

Peterson & Jennings Expires November 15, 2004 [Page 12]

Internet-Draft SIP Identity May 2004

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).

Peterson & Jennings Expires November 15, 2004 [Page 13]

Internet-Draft SIP Identity May 2004

The identity field indicates the propagation identity of
verified identities in the network. User agents sender of the
message. The Date and intermediaries
benefit from receiving verified identities. However, Contact headers provide reference integrity
and replay protection, as described in some cases
intermediaries might want to restrict the distribution RFC3261 Section 23.4.2.
Implementations of identity
information, for example if

o the authenticated identity body contains this specification MUST NOT consider valid a
request with an identity that outdated Date header field (the RECOMMENDED interval
is only
meaningful as an internal identifier within that the Date header must indicate a particular service
provider's network, or,

o time within 3600 seconds of
the originating user agent has requested privacy, 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
unrestricted distribution duration of a single Date
interval (i.e. 3600 seconds). Accordingly, if an Identity header is
replayed within the authenticated identity body would
violate Date interval, receivers will recognize that request.

If it
is not appropriate to share an authenticated identity invalid because of a
user has requested privacy, Call-ID duplication; if an authenticated identity body SHOULD NOT
be created and distributed. However, in some cases there may be
other entities in the administrative domain of Identity header is
replayed after the authentication
service Date interval, receivers will recognize that are consumers of it is
invalid because the authenticated identity. If, for
example, each of these servers needed Date is stale. The Contact header field is
included to challenge tie the user

Peterson Expires August 2, 2003 [Page 10]

Internet-Draft SIP Identity February 2003

individually for identity, it might significantly delay the
processing of the request. For that reason, it may be appropriate header to
circulate authenticated identity bodies among a controlled set of
entities. For particular device instance
that purpose, generated the request. Were an encryption mechanism for
authenticated identities is required.

7.1 Requesting Privacy

When users authenticate themselves active attacker to intercept a
request containing an authentication service, they
MAY explicitly notify Identity header, and cut-and-paste the service that they do not wish Identity
header field into their
authenticated identity to be circulated. Usually, own request (reusing the user in
question would also be taking other steps to preserve their privacy
(perhaps by including an anonymous From header identity fields,
Contact, Date and Call-ID fields that appear in the original
message), they would not be eligible to receive SIP request,
and following other standard privacy practices).

Authentication services MUST support requests from the privacy mechanism described
called user agent, since those requests are routed to the URI
identified in RFC3323 [3]. Users requesting privacy should the Contact header field.

This mechanism also support provides a signature over the
mechanisms described bodies of SIP
requests. The most important reason for doing so is to protect SDP
bodies carried in that document.

In particular, this document uses an identity-specific priv-value
that can appear SIP requests. There is little purpose in
establishing the Privacy header, a value identity of 'id', which was
registered by RFC3325 [6]. This Privacy value requests the user agent that provided the
results of authentication should not be shared by
signaling if a man-in-the-middle can change the authenticating
intermediary. An authentication service SHOULD NOT create SDP and direct media
to an alternate address. Note however that this is not perfect end-
to-end security. The authentication token service itself, when
instantiated at a intermediary, can change the SDP (and SIP headers,
for that matter) before providing a request when 'id' privacy has been
requested. If such signature. Thus, while this
mechanism reduces the chance that a token is created, man-in-the-middle will interfere
with sessions, it MUST be encrypted or
rendered confidential in does not eliminate it entirely. Since it is
assumed that the manner most appropriate user trusts their local domain to the token.
Guidelines vouch for encrypting AIBs are given in [4], and these mechanisms
MUST be supported by any authentication their
security, they must also trust the service that uses AIBs.

8. Security Considerations not to violate the
integrity of their message bodies without good reason.

Users SHOULD NOT provide credentials to an authentication service to
which they cannot initiate a direct connection, preferably one
secured by a network or transport layer security protocol such as TLS. If a user does not receive a certificate from the
authentication service over this lower-layer protocol TLS that corresponds to the expected
domain (especially when they receive a challenge via a mechanism such
as Digest), then it is possible that a rogue server is attempting to
pose as a authentication service for a domain that it does not
control, possibly in an attempt to collect shared secrets for that
domain. If a user cannot connect directly to the desired
authentication service, the user SHOULD at least use a SIPS URI to

Peterson & Jennings Expires November 15, 2004 [Page 14]

Internet-Draft SIP Identity May 2004

ensure that mutual TLS authentication will be used to reach the
remote server.

Relying on an authentication token Identity header generated by a remote administrative
domain assumes that the issuing domain uses some trustworthy

Peterson Expires August 2, 2003 [Page 11]

Internet-Draft SIP Identity February 2003 practice
to authenticate its users. However, it is possible that some domains
will implement policies that effectively make users unaccountable
(such as accepting unauthenticated registrations from arbitrary
users). Therefore, it is RECOMMENDED that authentication
tokens contain some indication of the specific practice (for example,
Digest) that was used to authenticate this request as a rough
indicator of credential strength. No manner The value of describing
authentication practices an Identity header for such domains is specified in this document.

If
questionable.

Since a common domain certificate is used by an authentication service
(rather than individual certificates for each identity), certain
problems can arise with name subordination. For example, if an
authentication service holds a common certificate for the hostname
'sip.atlanta.com', can it legitimately sign a token containing an
identity of 'sip:alice@atlanta.com'? It is difficult for the
recipient of a request to ascertain whether or not 'sip.atlanta.com'
is authoritative for the 'atlanta.com' domain unless the recipient
has some foreknowledge of the administration of 'atlanta.com'.
Therefore, it is RECOMMEND RECOMMENDED that user agent recipients of
authentication tokens notify end users if there is ANY discrepancy
between the subjectAltName of the signers certificate and the
identity within the authentication token.

Authentication tokens MUST have some form of replay protection. The
best protection is to copy Minor discrepancies MAY be
characterized as such. Additionally, relying parties MAY follow the SIP request
procedures in its entirety (via RFC3264 to look up on the
'message/sip' MIME type) into domain portion of the authentication token -
identity in that way,
it will be clear that this token has been issued the From header field in the DNS, and compare the SIP
services listed for this request,
since collectively that domain with the headers subjectAltName of a SIP request provide a unique
identifier. However, SIP requests the
certificate; this can be large, and it is reasonable
to include only give the relying party a subset better sense of the
canonical 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 services for including particular headers in a sipfrag, see [4]. that domain.

Because the common domain certificates that can be used by authentication
services need to assert only the hostname of the authentication
service, existing certificate authorities can provide adequate
certificates for this mechanism. However, not all proxy servers and
user agents will be able support the root certificates of all
certificate authorities, and moreover there are some significant
differences in the policies by which certificate authorities issue
their certificates. This document makes no recommendations for the
usage of particular certificate authorities, nor does it describe any
particular policies that certificate authorities should follow, but
it is anticipated that operational experience will create de facto
standards for the purposes of authentication services. Some
federations of service providers, for example, might only trust
certificates that have been provided by a certificate authority
operated by the federation.

Peterson & Jennings Expires August 2, 2003 November 15, 2004 [Page 12] 15]

Internet-Draft SIP Identity February 2003

operated by the federation.

9. May 2004

12. IANA Considerations

This document specifies two new SIP headers: Identity and Identity-
Info. Their syntax is given in Section 10. This document requests
that IANA add these headers to the SIP header registry.

This document also defines a new SIP status response code, '428 Use Authentication
Token'. The use of this status code is further 428 "Use
Identity", as described in Section
4.1. 8.

Normative References

[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.

[2] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", RFC 2119, March 1997.

[3] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November 2002.

[4] Peterson, J., "SIP Authenticated Identity Body (AIB) Format",
draft-ietf-sip-authid-body-01 (work in progress), October 2002.

Informative References

[5] Kohl, J. and C. Neumann, "The Kerberos Network Authentication
Service (V5)", RFC 1510, September 1993.

[6] Jennings, C., Peterson, J. and M. Watson, "Private Extensions to
the Session Initiation Protocol (SIP) for Asserted Identity
within Trusted Networks", RFC 3325, November 2002.

[7] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420,
November 2002.

[8] Olson, S., "A Mechanism for Content Indirection in SIP
Messages", draft-ietf-sip-content-indirect-mech-01 (work in
progress), August 2002.

[9] Freed, N., "Definition of the URL MIME External-Body Access-
Type", RFC 2017, November 1996.

Peterson & Jennings Expires August 2, 2003 November 15, 2004 [Page 13] 16]

Internet-Draft SIP Identity February 2003

Author's Address May 2004

Authors' Addresses

Jon Peterson
NeuStar, Inc.
1800 Sutter St
Suite 570
Concord, CA 94520
US

Phone: +1 925/363-8720
EMail: jon.peterson@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

The authors would like to thank Eric Rescorla, Rohan Mahy, Robert
Sparks, Jonathan Rosenberg, Mark Watson and Patrik Faltstrom for
their comments. Cullen Jennings assisted greatly in the development
of the content indirection mechanism considered in Section 4.3.

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:

- Split off child draft-ietf-sip-authid-body-00 for defining of
the AIB

- Clarified scope in introduction

Peterson & Jennings Expires November 15, 2004 [Page 17]

Internet-Draft SIP Identity May 2004

- Removed a lot of text that was redundant with RFC3261
(especially about authentication practices)

- Added mention of content indirection mechanism for adding token
to requests and responses

- Improved Security Considerations (added piece about credential
strength)

Changes from draft-peterson-sip-identity-00:

- Added a section on authenticated identities in responses

- Removed hostname convention for authentication services

- Added text about using 'message/sip' or 'message/sipfrag' in
authenticated identity bodies, also RECOMMENDED a few more headers
in sipfrags to increase reference integrity

Peterson Expires August 2, 2003 [Page 14]

Internet-Draft SIP Identity February 2003

- Various other editorial corrections

Peterson & Jennings Expires August 2, 2003 November 15, 2004 [Page 15] 18]

Internet-Draft SIP Identity February 2003 May 2004

Full Copyright Statement

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC Editor function is currently provided by the
Internet Society.

Peterson & Jennings Expires August 2, 2003 November 15, 2004 [Page 16] 19]

----