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.

Copyright Notice

   Copyright (C) The Internet Society (2003). (2004).  All Rights Reserved.

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.

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

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
   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
   local registration.  What  For the purposes of determining
   whether or not the 'return address' of a request can legitimately be
   asserted as the identity of the user, SIP entities in other domains really want to know about
   your identity is
   require an assurance that you are capable the sender of authenticating yourself a message is capable of
   authenticating themselves to a registrar in
   your 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
   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 to authenticate themselves to the local domain,
   and receive some kind of token that they can share with recipients cryptographic
   assurance of
   requests that lets them know that the user has been authenticated by
   the local domain.  However, Kerberos support end-user identity in SIP user agents is
   not widespread, and moreover SIP uses other means (such as Digest) to
   perform key authentication functions already.  An ideal solution
   would adapt existing SIP security mechanisms to address this problem.

   Therefore, an intradomain context.
   Furthermore, this document defines a new logical role mechanism must work for both SIP network
   intermediaries called an 'authentication service'.  Once requests and
   responses.  However, there is an
   authentication service has verified the additional wrinkle specific to
   providing identity of the originator of in a request, as described above, it creates response.  While the original address-of-
   record to which a cryptographic token that
   contains request is sent is stored in the authenticated identity To header field of
   the user, and which has some
   reference integrity with request, it is possible, due to retargeting at intermediaries, it
   is possible that the request itself.  This token can then will be
   added forwarded to an entity that has
   a SIP request and inspected by recipients different AoR (i.e.  identity).  Since the To header is not changed
   in responses to a SIP request, the UAC has no way of discovering that
   new AoR.  This is generally known as the "response identity" or
   "connected party" problem.

4. Requirements

   This draft addresses the following requirements:

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

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

      User agents that 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 identity assurance by an
      attacker.

      The mechanism must be capable of protecting the integrity of SIP
      message bodies (to ensure that media offers and answers are linked
      to the signaling identity).

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

      It must be possible, in cases where a request has been retargeted
      to a different AoR than the one designated in the To header field,
      for the UAC to ascertain the AoR to which the request has been
      sent.

5. Overview of Operations

   This section provides an informative (non-normative) high-level
   overview of the mechanisms described in this document.

   Imagine the case where Alice, who has the home proxy of example.com
   and the address-of-record sip:alice@example.com, wants to communicate
   with sip:bob@example.org.

   Alice generates an INVITE and places her identity in the From header
   field of the request.  She then sends an INVITE over TLS to an
   authentication service proxy for her domain.

   The authentication service authenticates Alice (possibly by sending a
   Digest authentication challenge) and validates that she is authorized
   to populate the value of the From header field (which may be Alice's
   AoR, or it may be some other value that the policy of the proxy
   server permits her to use).  It then computes a hash over some
   particular headers, including the From header field and the bodies in
   the message.  This hash is signed with the certificate for the domain
   (example.com, in Alice's case) and inserted in a header field (the
   new Identity header) in the SIP message.  The proxy, as the holder
   the private key of its domain, is asserting that the originator of
   this request has been authenticated and that she is authorized to
   claim the identity (the SIP address-of-record) which appears in the
   From header field.  The proxy also inserts a companion header field
   that tells Bob how to acquire its certificate, if he doesn't already
   have it.

   When Bob returns a response to the INVITE (such as a 200 OK), a
   similar set of steps happen.  Bob's home proxy asserts his identity
   in the response.  In this instance, the proxy has to insert the
   header directly into the request - redirection of responses is not
   possible.  When Alice receives the response, she verifies Bob's
   identity.

   If Alice's request for Bob were retargeted, one of two things might
   happened.  If it were retargeted to a domain that was also the
   responsibility of Bob's home proxy (for example, retargeted from
   sip:bob@example.com to sip:carol@example.com), then the request would
   proceed normally and receive an Identity.  If Bob's home proxy would
   retarget the request to some other domain (e.g.
   sip:bob@example.ORG), then his home proxy would redirect the request
   rather than proxying it, and Alice would send a new request that
   could receive a response with an Identity from the new domain.

6. User Agent Behavior: Sending Messages

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

   When a UAC sends a request, it MUST accurately populate the header
   field that asserts its identity (for a SIP request, this is the From
   header field).  In a request it MUST set the URI portion of its From
   header to match a 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 capable of sending requests through an
   'outbound' proxy (the authentication service), and of course MUST
   support the Digest authentication mechanism described in RFC3261.
   Because this mechanism does not provide integrity protection for the
   first hop to the authentication service, the UAC MUST send requests
   to an authentication service only over a TLS connection.
   Additionally, in order to provide identity for responses, user agents
   MUST form a persistent TLS connection to a proxy server when a
   REGISTER is sent.

   Since a UAS cannot send a response that does not replicate the
   contents of the To and From header fields in the corresponding
   request, UAS response-sending behavior is unchanged.  Again, because
   this mechanism does not provide integrity protection for the first
   hop of the response path, the UAS SHOULD send responses only over a
   TLS connection.

7. Authentication Service Behavior

   The authentication service authenticates the identity of the request who
   need message
   sender and validates that the identity given in the message can
   legitimately be asserted by the sender.  Then it computes a cryptographic guarantee signature
   over the canonical form of several headers and all the bodies, and
   inserts this signature into the message.

   First, an authentication service MUST extract the identity of the user.

   One possible format for such tokens is
   sender.  For requests, it inspects the Authenticated Identity
   Body (AIB) described in [4].  Other token formats are a matter From header field; for
   further investigation.  Throughout
   responses, the To header field (henceforth the result of this document,
   inspection will be referred to as the use "identity field).  If the
   identity field contains a SIP or SIPS URI, the authentication service
   MUST extract the hostname portion of AIB
   format the URI in that header field,
   and compare this to the domain(s) for which it is responsible.  If
   the token identity field uses the TEL URI scheme, the policy of the
   authentication service determines whether or not it is considered exclusively.  Only tokens that responsible
   for this identity.  Some example policies are
   suitable to be carried described in a MIME body are considered [TODO].
   If the authentication service is not responsible for the identity in this
   document.

2. Terminology

   In this document,
   question, it MAY handle the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
   RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted request as
   described in RFC2119 [2] and indicate requirement levels a normal proxy server; see
   below for
   compliant SIP implementations.

3. Using an Authentication Service

   A SIP user agents sends requests to more information on authentication service handling of an
   existing Identity header.

   Second, the authentication service must determine whether or not the
   sender of the request is authorized to claim the identity given in
   the identity field.  In order to receive an authentication token for the request.  How
   exactly do so, the association with an authentication service is learned or
   configured is an implementation-specific matter for
   MUST authenticate the user agent -
   it sender of the message.  Some possible ways in
   which this authentication might be implemented performed include:

      For requests, challenging the request with a pre-loaded Route header.  The
   guidelines given 407 response code
      using the Digest authentication scheme (or viewing a Proxy-
      Authentication header sent in RFC3261 Sections 26.3.2.1 the request which was sent in
      anticipation of a challenge using cached credentials, as described
      in RFC 3261 Section 22.3)

      For requests and 26.3.2.2 should be
   used when connecting to an responses that are sent over a persistent TLS
      connection, relying on some prior authentication service; ideally, an that was
      performed at the formation of the connection (most likely, the
      authentication service should be one hop away from a user agent, it
   should use previously challenged a lower-layer security protocol such as REGISTER request
      sent after the TLS connection was formed, or IPSec to
   authenticate possibly a prior
      challenged INVITE that was sent over 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 by all SIP entities, TLS connection)

   Authorization of the use assertion of Digest for this purpose a particular username in the From
   header field of a SIP message is
   RECOMMENDED a matter of local policy for compatibility with the maximum set of user agents.

4. How to Share Verified Identities

   When an authentication
   authorization service has authenticated which depends greatly on the user, it must
   construct an identity URI for that user that will be contained manner in the
   token.  It which
   authentication is performed.  A RECOMMENDED that these identities take policy is as follows: the form
   username asserted during Digest authentication MUST correspond
   exactly to the username in the From header field of the SIP
   address-of-record URI (as opposed to contact addresses), as they message.
   However, there are
   defined many cases in Section 10 of RFC3261; which a user might manage multiple
   accounts in other words, URIs of the form
   'sip:alice@atlanta.com'.

   This identity must be expressed in same administrative domain.  Accordingly, provided
   the authentication token that will
   be signed service is aware of the relationships between
   these accounts, it might allow a user providing credentials for one
   account to assert a username associated with another account
   controlled by the authentication service.  For example, user name.  Furthermore, if the
   Authenticated Identity Body (AIB) format described AoR asserted in [4] the
   From header field is used, anonymous (per RFC3323), then for an INVITE this identity would be stored the proxy should
   authenticate that the user is any valid user in the domain and insert
   the signature over the From header field within a 'message/sip' or 'message/sipfrag' [7] body that will
   be signed by as usual.

   Third, the authentication service.

   Once service MUST form the token identity signature,
   as described in Section 10, and add an Identity header to the request
   containing this signature.  After the Identity header has been created, added
   to the server MUST sign request, the token. authentication service MUST also add an Identity-
   Info header.  The
   subject of the Identity-Info header contains a URI from which its
   certificate SHOULD can be assigned acquired.  Details are provided in one of section Section
   10.

   Finally, the two
   following ways:

      An authentication service MAY use a common certificate, such MUST forward the message
   normally.

7.1 UAs acting as an Authentication service

   There are some instances in which a
      site certificate, user agent may hold the private
   key of the domain Certificate for its administrative domain.  The
      subjectAltName address-of-record.  In these
   cases, the UA MAY perform the services, and add the headers, that the
   authentication service would normally add.

8. Verifying Identity

   When a user agent or proxy server receives a SIP message containing
   an Identity header, it can inspect the signature to verify the
   identity of this certificate the sender of the message.  If an Identity header is not
   present in a request, and one is required by local policy, then a 428
   Use Identity response is sent.  If an Identity header is not present
   in a response, and one is required by local policy, then the
   recipient of the response MUST correspond with communicate this lapse to its user,
   and MAY immediately terminate any created dialog or ignore
   transactions, as policy dictates.

   In order to verify the host
      portion identity of the From header field sender of a message, the identity in the
      authentication token (if the identity were
      'sip:alice@atlanta.com', the subjectAltName of user
   agent or proxy server MUST first acquire the certificate
      would be 'atlanta.com'); for the
   signing domain.  Implementations supporting this specification should be the same certificate that
      the authentication service provides when proving its own identity
      (via TLS or
   have some similar protocol).

      An authentication service MAY hold a certificate corresponding to
      each user in its administrative means of retaining domain certificates (in other words, a accordance with
   normal practices for certificate whose subjectAltName contains a URI equivalent lifetimes and revocation) in order
   to prevent themselves from needlessly downloading the
      address-of-record URI of same
   certificate every time a request from the user).  In same domain is received.
   Certificates retained in this case, manner should be indexed by the appropriate
      certificate for URI
   given in the authenticated user will be Identity-Info header field value.

   Provided that the domain certificate used to sign the
      authentication token.  Maintaining individual certificates for
      each user this message is RECOMMENDED, since the name subordination rules
      involved with the use of a common
   unknown, SIP entities discover this 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 dereferencing the outermost MIME body to a
   'multipart/mixed' format, before
   Identity-Info header.  The client processes this certificate in the request can be forwarded.  Three
   options are considered for
   usual ways including checking that it has not expired, that an authentication token could be
   added to a SIP message: one in which the authentication service
   pushes the token chain
   is valid back to a trusted CA, and that it does not appear on
   revocation lists.

   Subsequently, the client for resubmission, one in which recipient MUST verify the authentication service adds signature in the token itself, Identity
   header, and one in which compare the client anticipates a URI at which identity of the authentication service will
   make signer (the subjectAltName of
   the token available.  Authentication services MUST support certificate) with the domain portion of the URI in the
   mechanism From
   header field of the request as described in Section 4.1 and MAY support 11.
   Additionally, the mechanism Date, Contact and Call-ID headers MUST be analyzed
   in Section
   4.2; the mechanism manner described in Section 4.3 is included 11; recipients that wish to illustrate a future
   direction.

4.1 Body Added by Client

   In this case, the authentication service returns verify
   Identity signatures MUST support all of the authentication
   token operations described
   there.  Any discrepancies or violations MUST be reported to the originating user agent, prompting user.

   When the originating user agent to
   retry the of a request with the authentication token attached.  No
   existing SIP mechanism can perform this function.  Therefore, this
   document defines receives a 428 "Use Authentication Token" response code.

   After a user has been authenticated (in the Digest example, with the
   407 response)
   containing an authentication service sends a 428 with a MIME body Authenticated Identity Body (AIB, see [4]), it SHOULD
   compare the identity in order to request that a user agent add the enclosed MIME body to
   their request and retry From header field of the request.  A 428 MUST have at most a
   single MIME body.  This MIME body MUST be signed by AIB of the
   authentication service.

   The use
   response with the original value of 428 without any MIME body is also defined the To header field in this
   document.  It can be sent by any server to reject a request because the request does not contain an authentication token.  A
   request.  If these represent different identities, the user agent
   receiving this rejection
   SHOULD retry their request through the same
   server after acquiring a token from an authentication service.

   In order to signal to the authentication services and other
   intermediaries that render the originating user agent supports identity in the receipt AIB of the 428 response code, to its user.
   Note that a new option-tag has been defined, the
   'auth-id' option-tag.  User agents SHOULD supply the 'auth-id'
   option-tag discrepancy in these identity fields is not necessary an
   indication of a security breach; normal retargeting may simply have
   directed the request to a Supported header whenever they provide credentials different final destination.  Implementers
   therefore may consider it unnecessary to alert the user of a server (for example, security
   violation in Digest authentication, whenever this case.

9. Proxy Server Behavior

   In most respects, a Proxy-
   Authorization header is added to proxy server behaves normally when it receives a request).

   Using the 428
   SIP request or response code may introduce extra round-trip times for
   messages, delaying the setup of requests. containing an Identity header.  This
   mechanism is fully backwards-compatible with existing RFC3261 proxy
   behavior.  However, there are some
   circumstances under which extra RTTs may not impede performance.  If
   the originating user agent possesses if a non-stale nonce (assuming
   Digest authentication) from the proxy intends to act as an authentication service,
   service for responses to requests it can pre-
   emptively include receives, it must exhibit some
   additional behavior to ensure that retargeting requests are handled
   properly.  Essentially, a Proxy-Authorization header, eliminating one RTT
   (the one resulting from proxy server MUST NOT provide an Identity
   header for a 407).  With regard request that it retargets to a different administrative
   domain.  It is the second RTT, note responsibility of that administrative domain to
   provide its own identity assertion, if it can.  However, proxying the
   request needn't necessarily go through the authentication
   service again once the authentication token has been added - it could
   go directly to a remote domain where identity services may be provided
   has its destination, which reduce own problems - the impact originator of the second
   RTT.

   There are two good reasons request has no way to think that
   know whether the originating user agent
   should be request was legitimately retargeted, or if any
   responses it receives from the party responsible new domain are spoofed or otherwise
   illegitimate.  It is thus much more secure for adding the authentication token proxy server to the request.  Firstly, because this gives the client the
   opportunity
   redirect in cases where it might otherwise retarget.

   If a proxy server intends to inspect the body itself (perhaps only act as an authentication service for a
   response to see whether
   or not a SIP request that it is encrypted; see [4]) in order to verify that forwarding, it MUST do ALL of
   the following:

      Ascertain if it is responsible for the
   authenticated identity corresponds with domain indicated in the provided credentials and
      Request-URI field of the user's preferences.  Secondly, request.  If not, it MUST forward the client can provide a signature
   over
      request normally.  If so, it must then:

      Determine the entire body route set of targets to which this request might be
      forwarded.  From that target list, the message (either proxy must determine which
      contact addresses are associated with S/MIME or some
   header-based mechanism) so persistent TLS connections
      that have been established to the final recipient of messages can
   be assured that proxy server.  It places all information in
      such targets (if any) into a primary route set for the body is there at call, and
      places remaining targets into a secondary route set for the
   originator's behest.

4.2 Body Added by Authentication Service

   Another possibility is that call.
      It performs this operations irrespective of any qvalues associated
      with the authentication service could add contact addresses.

      The proxy then MUST follow normal administrative policies for
      forwarding the
   body request to any targets in the request itself before forwarding primary route set
      (which may involve qvalue calculations or any other behaviors
      described in RFC3261).  Before the request.  However, proxy forwards any responses to
      this request upstream, the authentication service role is usually played by entities that proxy server MUST 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 (as described in Section 7), adding an
      Identity 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 Identity-Info header.

      If there are no appropriate responses from the
   authentication token back to primary route set
      for the originating user agent.  For one, proxy server to forward upstream, 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 moves on to the entire message body in a SIP message header.  Were
   a
      secondary route set (essentially, the proxy server forks
      sequentially, exploring the primary route set as one cluster, and
      then moves on to modify the body of a message that was protected by such
   signature, that would be perceived secondary set).  The proxy server is unable
      to act as an integrity violation by
   downstream recipients of authentication service for those contact addresses.
      Accordingly, the message.  Presumably, proxy server MUST NOT explore these route targets
      itself; instead, it MUST redirect the request with a back-to-back
   user agent function would have 3xx class
      response containing the contact addresses that constitute the
      secondary route set.

   In order to sacrifice this end-to-end
   integrity.  The notion 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 transparent back-to-back user agent persistent TLS connection - this is
   also ill-defined, used to
   determine when the server should act as a proxy and when it is questionable if any SIP intermediaries should interfere with SIP message bodies.

4.3 Using Content Indirection

   Work is currently underway in
   redirect.  When the SIP WG to define a content
   indirection [8] mechanism for SIP, a mechanism by which a MIME body
   in registrar receives a SIP REGISTER request can refer, with a URL, to over a document that
   persistent TLS connection, it hosted
   somewhere MUST compare any contact addresses
   appearing in Contact header fields to the network.  This raises another interesting
   possibility for authentication token transport topmost Via header field in SIP.

   A SIP user agent could create a content indirection MIME body (using
   the RFC2017 [9] URL MIME External-Body Access-Type) that contains a
   URL that identities a resource controlled by REGISTER request.  If the authentication
   service, anticipating that host portion of a contact address
   matches the authentication service will make hostname given in the
   authentication token available at topmost Via header field, then that URL.  This URL could
   contact address is said to be pushed
   by "associated" with the authentication service to persistent TLS
   connection over which the UAC 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 authentication
   service challenges the UAC (as
   primary route set by a new header in the 407 response).
   Once proxy server that wishes to act as an
   authentication service has validated for responses.

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

10. Header Syntax

   This approach could allow user agents to have full control over the
   integrity document specifies two new SIP headers: Identity and Identity-
   Info.  Each of these headers can appear only once in a SIP requests, while still requiring the extra RTT caused
   by 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 use contents of the 428 response code.  It also has numerous advantages
   over other ways signed-identity-digest, the following
   elements of handling authentication tokens issued for a SIP
   response messages (see Section 5).

5. Identity message MUST placed in Responses

   Many of the practices described string in the preceding sections can be
   applied to responses as well as requests, with some important
   differences.  Primarily, the distinction is that order
   specified here, separated by a response cannot be
   challenged colon:

      The AoR of the UA sending the message, or resubmitted in the same manner as 'identity field'.
      For a request, and
   therefore the mechanism in Section 4.1 is not usable.  However, when
   a user agent registers under a particular identity, and thereby
   becomes eligible to receive requests and send responses associated
   with that identity, it provides credentials that prove its identity,
   and thus if the registrar this is co-located with the proxy that receives
   requests addr-spec from the From header field;
      for responses, the user's administrative domain, is addr-spec of the To header field.  This needs
      to be in a reasonable
   position lower case and to act be represented as an authentication service a SIP URI.

      The callid from Call-Id header field.

      The Date header field, with exactly one space each for responses.

   Note that each SP and
      the identity weekday and month items case set as shown in an authentication token BNF in a response
   almost certainly will not correspond with 3261.  The
      first letter is upper case and the identity asserted in rest of the From letters are lower
      case.

      The addr-spec component of the Contact header field value.

      The body content of the response (which is copied from the
   request); message with the identity bits exactly as they are
      in the authentication token represents a
   different entity. message.

   For many requests, the identity in more information on the
   authentication token security properties of a response will correspond to 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 To first addr-spec MUST be taken from the From
   header field of value, and the request, but there are numerous legitimate ways that
   requests can be retargeted in which this will not second addr-spec from the Contact header
   field value.

   After the digest-string is formed, it MUST be hashed and signed with
   the case.

   An authentication service that also acts certificate for the domain, as a registrar and inbound
   proxy can add to a response an authentication token that corresponds
   to follows: compute the identity results of
   signing this string with sha1WithRSAEncryption as described in RFC
   3370 and base64 encode the originator of that response results as specified in roughly RFC 3548.  Put the
   same manner described
   result in Section 4.2 - the authentication service
   adds Identity header.

   Note on this choice: Assuming a 1024 bit RSA key, the authentication token to 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 response before SIPS
   URI.  If it forwards contains an HTTPS URI, the
   response towards URI must dereference to a
   resource that contains a single MIME body containing the originator certificate
   of the request.  There authentication service.  If it is no way for
   an a SIPS URI, then the
   authentication service to perform a function intends for responses
   comparable a user agent that wishes to fetch
   the mechanism described in Section 4.1; however,
   content indirection (see Section 4.3 could provide an alternative certificate to form a TLS connection to that would allow URI, acquire the client
   certificate during normal TLS negotiation, and close the connection.

   This document adds the following entries to retain end-to-end integrity properties
   on responses.

6. Receiving an Authentication Token

   The manner in 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 an authentication token is handled is dependent
   on provides a signature over
   the nature Contact, Date, Call-ID, and 'identity fields' (addr-spec of the token itself; rules
   From header field for handling the
   Authenticated Identity Body (AIB) format are given [4].

6.1 Authentication Service Handling requests, and To header field for responses) of Authentication Tokens
   SIP intermediaries generally should not attempt to inspect MIME
   bodies; following messages.  While a signature over the rules of RFC3261 Section 16.6, MIME bodies may identity field alone would
   be encrypted end-to-end or have other properties that sufficient to secure a URI alone, the additional headers provide
   replay protection and reference integrity necessary to make them
   unsuitable for consumption by intermediaries.  However,
   intermediaries sure that implement
   the authentication service logical role
   MAY inspect MIME bodies Identity header will not be used in order cut-and-paste attacks.  In
   general, the considerations related to find one with a Content-
   Disposition the security of 'auth-id'.

   For these headers
   are the most part, same as those given in RFC3261 for including headers in
   tunneled 'message/sip' MIME bodies (see Section 23 in particular).

   The identity field indicates the actual value of an authenticated identity is
   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
   token (using the 428 request, sender of the
   message.  The Date and Contact headers provide reference integrity
   and replay protection, as described in RFC3261 Section 4.1).  However,
   authentication services MAY additionally maintain lists 23.4.2.
   Implementations of known
   problem users this specification MUST NOT consider valid a
   request with an outdated Date header field (the RECOMMENDED interval
   is that are banned from making requests to their
   administrative domain, for example, and subsequently reject some
   requests after comparing their authenticated identities to such
   access control lists.

7. Selective Sharing of Identity

   Most of the time, there is no need to restrict Date header must indicate a time within 3600 seconds of
   the propagation receipt of
   verified identities a message).  Implementations MUST also record Call-IDs
   received in the network.  User agents valid requests containing an Identity header, and intermediaries
   benefit from receiving verified identities.  However, in some cases
   intermediaries might want to restrict MUST
   remember those Call-IDs for at least the distribution duration of identity
   information, for example a single Date
   interval (i.e.  3600 seconds).  Accordingly, if

   o  the authenticated identity body contains an identity that Identity header is only
      meaningful as an internal identifier
   replayed within a particular service
      provider's network, or,

   o  the originating user agent has requested privacy, and the
      unrestricted distribution of 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 the authenticated identity.  If, for
   example, each of these servers needed to challenge the user
   individually for identity, it might significantly delay the
   processing of is
   invalid because the request.  For that reason, it may be appropriate Date is stale.  The Contact header field is
   included to
   circulate authenticated identity bodies among a controlled set of
   entities.  For tie the Identity header to a 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 Identity
   header field into their own request (reusing the identity fields,
   Contact, Date and Call-ID fields that appear in the original
   message), they do would not wish their
   authenticated identity to be circulated.  Usually, eligible to receive SIP requests from the
   called user in
   question would also be taking other steps agent, since those requests are routed to preserve their privacy
   (perhaps by including an anonymous From header in the SIP request,
   and following other standard privacy practices).

   Authentication services MUST support URI
   identified in the privacy Contact header field.

   This mechanism described
   in RFC3323 [3].  Users requesting privacy should 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
   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 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.

9.

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.

Author's Address

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

      - Various other editorial corrections

Full Copyright Statement

   Copyright (C) The Internet Society (2003). (2004).  All Rights Reserved.

   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.