[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 draft-ietf-sip-identity

Network Working Group                                        J. Peterson
Internet-Draft                                                   NeuStar
Expires: December 30, 2002                                  July 1, 2002


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

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 December 30, 2002.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   The existing mechanisms for expressing identity in the Session
   Initiation Protocol oftentimes do not permit an administrative domain
   to verify securely the identity of the originator of a request.  This
   document recommends practices and conventions for authenticating end
   users, and proposes a way to distribute secure authenticated
   identities within SIP messages.








Peterson                Expires December 30, 2002               [Page 1]


Internet-Draft                SIP Identity                     July 2002


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Sending Requests through an Authentication Service . . . . . .  7
   4.  Authentication Practices . . . . . . . . . . . . . . . . . . .  8
   4.1 Issuing Challenges with Realms . . . . . . . . . . . . . . . .  8
   4.2 Determining Identity with Credentials  . . . . . . . . . . . .  9
   4.3 Analyzing Requests . . . . . . . . . . . . . . . . . . . . . .  9
   4.4 Accounting for Authentication  . . . . . . . . . . . . . . . . 10
   4.5 Forwarding the Request . . . . . . . . . . . . . . . . . . . . 10
   5.  Sharing Verified Identities  . . . . . . . . . . . . . . . . . 11
   5.1 Authenticated Identity within a Body . . . . . . . . . . . . . 11
   5.2 Body Added by Authentication Service . . . . . . . . . . . . . 12
   5.3 Body Added by Client . . . . . . . . . . . . . . . . . . . . . 13
   5.4 Example of a Request with an Authenticated Identity Body . . . 14
   6.  Receiving an Authenticated Identity  . . . . . . . . . . . . . 16
   6.1 Proxy Server Handling  . . . . . . . . . . . . . . . . . . . . 17
   6.2 User Agent Handling  . . . . . . . . . . . . . . . . . . . . . 17
   7.  Identity in Responses  . . . . . . . . . . . . . . . . . . . . 19
   8.  Selective Sharing of Identity  . . . . . . . . . . . . . . . . 20
   8.1 Requesting Privacy . . . . . . . . . . . . . . . . . . . . . . 20
   8.2 Encryption of Identity . . . . . . . . . . . . . . . . . . . . 21
   8.3 Example of Encryption  . . . . . . . . . . . . . . . . . . . . 21
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 23
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 24
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 25
   A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 26
   B.  To Do  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
       References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
   C.  Changelog  . . . . . . . . . . . . . . . . . . . . . . . . . . 28
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 29



















Peterson                Expires December 30, 2002               [Page 2]


Internet-Draft                SIP Identity                     July 2002


1. Introduction

   This document provides enhancements to the existing mechanisms for
   authenticated identity management in the Session Initiation Protocol
   (SIP [1]).

   The baseline SIP protocol allows a user agent to express the identity
   of its user in a number of headers.  The primary place for identity
   information asserted by the sender of a request is the From header.
   The From header field contains a URI (like 'sip:alice@atlanta.com')
   and an optional display-name (like "Alice") that identifies the
   originator of the request.  A user may have many identities that are
   used in different contexts.

   Typically, this URI is an address-of-record that can be dereferenced
   in order to contact the originator of the request; specifically, it
   is usually the same address-of-record under which a user registers
   their devices in order to receive incoming requests.  This address-
   of-record is assigned and maintained by the administrator of the SIP
   service in the domain identified by the host portion of the address-
   of-record (which may have any of a number of relationships with the
   end user).  However, the From field of a request can usually be set
   arbitrarily by the user of a SIP user agent; the From header of a
   message provides no internal assurance that the originating user can
   legitimately claim this identity.  Nevertheless many SIP user agents
   will obligingly display the contents of the From field as the
   identity of the originator of a received request (as a sort of
   'Caller-ID' function).

   To satisfy the requirement for a more reliable way of identifying
   parties in a SIP session, a number of cryptographic authentication
   systems are described in the SIP standard, including mechanisms based
   on HTTP Digest, S/MIME and transport or network layer security.
   Among other things, these mechanisms allow a server to verify that a
   user agent can legitimately assert a specific identity.  Whether or
   not the recipient of these credentials can verify them is based on
   whether the credentials are asymmetric, and publicly verifiable by
   third parties, or symmetric, and verifiable only by parties that have
   a pre-existing relationship with the user.

   Symmetric: Authentication with symmetric keys usually entails the
      transmission of some sort of secret credentials (typically a
      username and password) from the client to the server.  Secrets-
      based authentication assumes a pre-existing relationship (an
      agreement on a secret) between the client that originates a
      request and the server that responds with a challenge.  Useful
      secrets-based authentication schemes use cryptography to conceal
      the credentials so they can not be observed and reused by



Peterson                Expires December 30, 2002               [Page 3]


Internet-Draft                SIP Identity                     July 2002


      eavesdroppers on the network.  Secrets are usually memorized by
      end users, and thus do not necessitate any special configuration
      of user agents.

   Asymmetric: Asymmetric credentials require a Public Key
      Infrastructure (PKI) that manages public and private keys.  PKI-
      based authentication usually relies on a certificate authority
      that issues a custom certificate to each entity that would like to
      prove its identity, and a common root certificate to each entity
      that would like to verify the identity of others.  In this system
      there is no need for any pre-existing relationship between the
      clients and servers (unless in the absence of a certificate
      authority self-signed certificates are used).  However, PKI has to
      date only been effective in asserting the identity of a hostname -
      there is a widespread belief that implementing a PKI for
      certificates that assert the identity of individuals is currently
      impractical.  Each host MUST be configured with any certificate
      that asserts its identity.

   Most user agents authenticate themselves with shared secrets.  In
   baseline SIP, the Digest authentication method (which is required for
   all user agents and servers) allows users to provide a username and
   password to authenticate themselves in the context of a particular
   realm (for example, the identity 'alice' within the realm
   'atlanta.com' might have the password 'x63Mdo+').

   Digest therefore works well for functions like SIP registration, in
   which the target of a request is a server within the realm in which a
   user can prove an identity.  However, the credentials with which a
   user proves that they are 'sip:alice@atlanta.com' cannot be verified
   by a server in another realm, like biloxi.com - Alice shares the
   secret with atlanta.com, not biloxi.com.  Thus, if Alice were to send
   a request to a proxy server in the biloxi.com realm, biloxi.com has
   no way of determining whether or not Alice can legitimately claim the
   identity 'sip:alice@atlanta.com'.  biloxi.com is then left only with
   the unreliable From field for ascertaining the identity of the
   originator of interdomain requests.

   However, were Alice to proxy her request through an atlanta.com proxy
   server, atlanta.com might be able to verify her identity before
   passing the request to its destination, biloxi.com.  Therefore, this
   document proposes a new logical role for network intermediaries
   called an authentication service.  The authentication service role
   would most likely be instantiated by the local outbound proxy server
   within an administrative domain.  Once an authentication service has
   verified the identity of the originator of a request, it can add the
   result of the authentication process to the request for the benefit
   of downstream recipients.



Peterson                Expires December 30, 2002               [Page 4]


Internet-Draft                SIP Identity                     July 2002


   User agents can be configured, statically or on a per-call basis, to
   send requests through an authentication service.  After a request has
   passed through an authentication service in a given domain (e.g.
   atlanta.com) downstream recipients (e.g.  in biloxi.com) will be able
   to determine that atlanta.com asserts a specific authenticated
   identity for the originator of this message, like
   'sip:alice@atlanta.com'.

   In some cases, this authenticated identity can be distributed by the
   authentication service to any potential recipients of the request
   without restriction.  In other cases, for reasons of network policy,
   or user privacy constraints, the distribution of the authenticated
   identity will be restricted.

   In summary, the identity that appears in the From field of a SIP
   request provides a way that the originator can be canonically reached
   (and therefore provides some accountability for that user).  The best
   way for a SIP user to prove that they can legitimately claim an
   identity is to provide the same credentials they would need to
   provide in order to register to receive requests for that identity.
   For that purpose, this document defines an authentication service
   that verifies the credentials of an end user in their local
   administrative domain before sending requests to their destinations.
   This authentication service can then sign the identity that results
   from this authentication and make this identity available to
   recipients of the request, thereby proving that the administrative
   domain responsible for the originating user registers has verified
   that user's identity.  Effectively, this allows a user's
   authentication with a single server to be bootstrapped into a
   publicly-verifiable authentication.

   By way of example, the manner in which a user authenticates
   themselves to an authentication service is in this document
   restricted to the mechanisms that are available in [1], specifically
   the Digest authentication scheme, as it is common to all SIP-
   compliant endpoints.  However, these mechanisms have no dependency on
   any particular authentication scheme.














Peterson                Expires December 30, 2002               [Page 5]


Internet-Draft                SIP Identity                     July 2002


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.












































Peterson                Expires December 30, 2002               [Page 6]


Internet-Draft                SIP Identity                     July 2002


3. Sending Requests through an Authentication Service

   An authentication service is a logical role played by a network
   intermediary, such as a SIP proxy server.  Commonly, the
   authentication service function will be instantiated by a local
   outbound proxy server.  Authentication services are capable of
   verifying the identity of users through some means.  Authentication
   services are also capable of sharing this verified identity in a
   secure manner.

   Requests from a user agent are sent through an authentication service
   because the user agent is configured (with a pre-loaded Route header,
   perhaps) to send all requests through the service.

   A user has some incentive to send calls through an authentication
   service, in that:

      Authentication services help to prevent identity theft, and the
      many potential annoyances that could result from being
      impersonated, and,

      Administrative domains could implement policies that reject
      requests from users that have not gone through an authentication
      service appropriate for the administrative domain listed in the
      From header of their messages.

   Optimally, a user should be able to send SIP messages to their
   authentication service directly, without going through any SIP proxy
   servers, since many authentication systems (including Digest) are not
   optimally secure when handled by intermediaries.  An authentication
   service will frequently be co-located with a user agent's first-hop
   local outbound proxy.



















Peterson                Expires December 30, 2002               [Page 7]


Internet-Draft                SIP Identity                     July 2002


4. Authentication Practices

   When a user first forms a connection to a SIP entity that implements
   the authentication service role, the user SHOULD make use of network
   or transport layer security, preferably contacting the authentication
   service without going through any intermediaries.  This document
   recommends the use of Transport Layer Security (TLS) to connect to
   the authentication service.  This in turn allows the authentication
   service to potentially offer a certificate directly to the end user,
   as well as ensuring confidentiality, integrity, and replay protection
   during the challenge phase.  If the user agent is more than one hop
   away from the authentication service, it may make sense to use the
   SIPS URI scheme to improve the security of requests routed through
   the authentication service.

   Any entity that implements the authentication service role MUST
   possess a certificate that has been issued by a certificate
   authority.  The SubjectAltName of the certificate SHOULD be the
   fully-qualified domain name of the device on which the authentication
   service is running.  Only one logical authentication service SHOULD
   operate in a given administrative domain.  The manner in which an
   authentication service can be recognized to be the canonical
   authority for an administrative domain is currently an open issue.

4.1 Issuing Challenges with Realms

   Obviously, all authentication services have their own sets of users
   and corresponding credentials; when a user is challenged by an
   authentication service, that user selects credentials that are
   appropriate for the service in question.  For the purposes of this
   document, following the terminology in Digest authentication, an
   authentication service has a 'realm' which provides a context in
   which a user is asked to authenticate.  For example, when an
   authentication service challenges a user for Digest authentication
   with the 407 status code, the challenge MUST be sent for a realm
   corresponding to the hostname of the authentication service.  Note
   that a user agent SHOULD consider it a cause for concern (though not
   necessarily an error condition) if the realm of a challenge does not
   correspond both with the hostname of the authentication service and
   any certificate presented by the authentication service on connection
   - users SHOULD be notified of this occurrence.

   Once again, note that Digest authentication is used merely by way of
   example.  Other mechanisms within SIP, or out-of-band mechanisms,
   could be used to authenticate the user.  If these authentication
   systems do not explicitly support the concept of realms, the realm in
   which a challenge occurs should be understood by the user agent to be
   the hostname of the authentication service.  Any method of



Peterson                Expires December 30, 2002               [Page 8]


Internet-Draft                SIP Identity                     July 2002


   authentication used by an authentication service, MUST therefore have
   a means of communicating, at the very least, its hostname to a user.
   If these authentication systems do not support credentials that
   express a specific username, then a username SHOULD be taken by the
   authentication service from the username portion of the URI in the
   From header field of the SIP request.

4.2 Determining Identity with Credentials

   If a user agent is challenged (in SIP Digest, for example, with a 401
   or 407 response code) and it has access to credentials for the realm
   in question, these credentials will be provided in a resubmission of
   the request to the authentication service.  In Digest, the
   authentication service MUST extract and verify these credentials from
   the resubmission of the request.

   The username associated with these credentials SHOULD be combined
   with the name of the administrative domain of the authentication
   service in order to form the authenticated identity of the user.  For
   example, if the credentials were valid for the username 'alice', for
   an authentication service within the atlanta.com administrative
   domain, the authenticated identity would be 'sip:alice@atlanta.com'.
   An authentication service MAY also have a particular display-name
   which it associates with particular users that will be included in
   the authenticated identity.

   Note that some user agents MAY provide 'anonymous' credentials with
   no password in a resubmission of a request after a challenge.
   Whether or not an authentication service considers this to be a
   successful authentication is a matter of local policy, but the
   authentication service SHOULD NOT assert this 'anonymous' identity to
   others in the manner described in Section 5.

   The credentials that a user provides to an authentication service
   SHOULD be the same credentials that are provided when the user
   registers in this administrative domain.

4.3 Analyzing Requests

   Some authentication services MAY wish to inspect the contents of the
   From header of an outbound request.  Depending on the policy of the
   authentication service, it might not be appropriate for the From
   header to differ from the authenticated identity that the service has
   verified.  Some authentication services MAY reject requests (with a
   403 Forbidden) that assert an inappropriate identity in the From.

   Authentication services MAY also place restrictions on the display-
   name as well as the URI associated with the From header.



Peterson                Expires December 30, 2002               [Page 9]


Internet-Draft                SIP Identity                     July 2002


   Note that some users MAY supply an anonymous From header (see [3])
   for some requests.  Authentication services generally SHOULD NOT
   consider this to conflict with any identity information learned in
   the authentication process.  For more information on the obligations
   of authentication services with respect to privacy, see Section 8.1.

   It may not be necessary for an authentication service to prevent the
   arbitrary assignment of the From field if the authentication service
   has another way of sharing authenticated identity information (see
   Section 5).  Steps for reconciling the user-asserted From header with
   authenticated identity data are given in Section 6.2.

4.4 Accounting for Authentication

   Authentication services MAY record the successful authentication of a
   request, including its dialog identifiers and Request-URI, in order
   to provide some accountability when administrative requests are made
   for information about the parties participating in a particular
   session.  Some mechanisms by which a user is authenticated and
   authorized may also persist accounting data about the request,
   although such mechanisms are outside the scope of this document.

   Authentication services MAY also wish to log failed authentication
   attempts, especially those that reflect repeated attempts to try
   different credentials for the same username.

4.5 Forwarding the Request

   Once an authentication service has authenticated the originator of a
   request, if it does not wish to provide any further identification
   services, it MUST subsequently forward the request in accordance with
   the conventional request routing logic in the SIP specification.

   If the authentication services also wishes to share the authenticated
   identity it has verified, it can use the mechanisms described in
   Section 5.















Peterson                Expires December 30, 2002              [Page 10]


Internet-Draft                SIP Identity                     July 2002


5. Sharing Verified Identities

   Authenticated identities SHOULD be shared unless the authentication
   service has a reason to do otherwise.  By authenticating themselves,
   originating users must understand that they are giving the
   authentication service the right to share the provided identity with
   others.  If they wish to prevent this, users MUST request privacy for
   their authentication information (see Section 8.1).

   Note that the practices described in this section can also be
   leveraged by a logical authentication service that is instantiated by
   a user agent, provided the user agent holds a certificate that is
   publicly verifiable.

5.1 Authenticated Identity within a Body

   As a way of sharing authenticated identity among parties in the
   network, a special type of MIME body, which will subsequently be
   referred to as an 'authenticated identity body', is defined in this
   section.  An authenticated identity body allows an authentication
   service to cryptographically sign the identity of the originator of
   the message in question.

   An authenticated identity body is a MIME body of type 'message/sip'
   or 'message/sipfrag' (see [4]).  This body MUST have a Content-
   Disposition disposition-type of 'auth-id', a new value defined in
   this document specifically for authenticated identity bodies.  The
   Content-Disposition header SHOULD also contain a 'handling' parameter
   indicating that this MIME body is optional.

   Authenticated identity bodies of the 'message/sipfrag' MIME type MUST
   contain the following headers: From, Date and Call-ID; they SHOULD
   also contain the To, Contact and Cseq header.  The From header field
   MUST be populated by the authentication service with the
   authenticated identity itself, as discussed above in Section 4.2; if
   the authentication service verifies the display-name of the From
   header field, it MUST be included in the authenticated identity body,
   and if it does not verify the display-name of the From header field
   it MUST NOT be included.  Authenticated identity bodies MAY contain
   any other headers that help to uniquely identify the transaction or
   provide related reference integrity.  An example of an authenticated
   identity body is:









Peterson                Expires December 30, 2002              [Page 11]


Internet-Draft                SIP Identity                     July 2002


   Content-Type: message/sipfrag
   Content-Disposition: auth-id; handling=optional

   From: Alice <sip:alice@atlanta.com>
   To: Bob <sip:bob@biloxi.com>
   Contact: <sip:alice@pc33.atlanta.com>
   Date: Thu, 21 Feb 2002 13:02:03 GMT
   Call-ID: a84b4c76e66710
   Cseq: 314159 INVITE

   Once the authenticated identity body has been fully populated, it
   MUST be signed by the authentication service that has created it.  An
   unsigned authenticated identity body MUST NOT be honored by any
   recipients.  An authenticated identity body MUST be signed with the
   public key corresponding to the same certificate that the
   authentication service uses to authenticate itself for the purposes
   of transport of network layer security such as TLS (see Section 4).
   A full example of a message with a signed authenticated identity MIME
   body is given in Section 5.4.

   After the authenticated body has been signed, some entity SHOULD
   added it to any existing MIME bodies in the request, if necessary by
   transitioning the outermost MIME body to a 'multipart/mixed' format.
   But which participant in the dialog should add the authenticated
   identity body, the authentication service or the originating user
   agent? Both options are considered in the following sections.
   Authentication services MUST support the mechanism in Section 5.3 and
   MAY support the mechanism in Section 5.2.

5.2 Body Added by Authentication Service

   The first possibility is that the authentication service could add
   the body to the request itself before forwarding the request.
   However, the authentication service role is usually played by
   entities that act as proxy servers for most requests, and proxy
   servers cannot modify message bodies.  In order to add an
   authenticated identity body, the authentication service needs to act
   as a transparent back-to-back user agent, effectively terminating the
   request and re-originating it with a new body appended to any
   existing MIME bodies.

   This mechanism has some potential advantages over sending the
   authenticated identity body back to the originating user agent.  For
   one, it saves on additional round-trip times for signaling that
   result from passing the body back to the user agent.  It also
   requires no new SIP mechanisms, whereas any method of asking a user
   agent to include a body in a resubmission to the current request
   would introduce new protocol requirements.



Peterson                Expires December 30, 2002              [Page 12]


Internet-Draft                SIP Identity                     July 2002


   However, there are proposed SIP integrity mechanisms that place a
   signature over the entire message body in a SIP message header.  Were
   a server to add to the body of a message that was protected by such
   signature, that could be perceived as an integrity violation by
   downstream recipients of the message.

5.3 Body Added by Client

   Alternatively, the authentication service could in some fashion
   return the authenticated identity MIME body to the originating user
   agent, prompting the user agent to retry the request with the
   authenticated identity MIME body attached.  No existing SIP mechanism
   performs this function.  Therefore, this document defines a 428 "Use
   Authenticated Identity" response code.

   An authentication service sends a 428 with a MIME body in order to
   request that a user agent add the enclosed MIME body to their request
   and retry the request.  A 428 MUST have at most a single MIME body.
   This MIME body MUST be signed by the authentication service.

   The use of 428 without any MIME body is also defined in this
   document.  It can be sent by any server to reject a request because
   the request does not contain an authenticated identity body.  A user
   agent receiving this rejection SHOULD retry their request through an
   authentication service.

   In order to signal to the authentication services that the
   originating 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 a Supported header
   whenever they provide credentials to a server (for example, in Digest
   authentication, whenever a Proxy-Authorization header is added to a
   request).

   Using the 428 response code may introduce extra round-trip times for
   messages, delaying the setup of requests (one RTT for the 407,
   another for the 428).  However, there are some circumstances under
   which extra RTTs may not impede performance.  If the originating user
   agent possesses a non-stale nonce (assuming Digest authentication)
   from the authentication service, it can pre-emptively include a
   Proxy-Authorization header, eliminating one RTT.  With regard to the
   second RTT, note that the request needn't necessarily go through the
   authentication service again once the authenticated identity body has
   been added - it could go directly to its destination, which reduce
   the impact of the second RTT.

   There are two reasons why the originating user agent should be the
   party responsible for adding the authenticated identity body to the



Peterson                Expires December 30, 2002              [Page 13]


Internet-Draft                SIP Identity                     July 2002


   request.  Firstly, because this gives the client the opportunity to
   inspect the body itself (perhaps only to see whether or not it is
   encrypted; see Section 8.2) in order to verify that the authenticated
   identity corresponds with the provided credentials and the user's
   preferences.  Secondly, the client can provide a signature over the
   entire body of the message (either with S/MIME or some header-based
   mechanism) so that the final recipient of messages can be assured
   that all information in the body is there at the originator's behest.

5.4 Example of a Request with an Authenticated Identity Body

   The following shows a full SIP INVITE request with an authenticated
   identity body (one that has been added by the originating user
   agent):

   INVITE sip:bob@biloxi.com SIP/2.0
   Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
   To: Bob <sip:bob@biloxi.com>
   From: Alice <sip:alice@atlanta.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 314159 INVITE
   Max-Forwards: 70
   Date: Thu, 21 Feb 2002 13:02:03 GMT
   Contact: <sip:alice@pc33.atlanta.com>
   Content-Type: multipart/mixed; boundary=unique-boundary-1

   --unique-boundary-1

   Content-Type: application/sdp
   Content-Length: 147

   v=0
   o=UserA 2890844526 2890844526 IN IP4 here.com
   s=Session SDP
   c=IN IP4 pc33.atlanta.com
   t=0 0
   m=audio 49172 RTP/AVP 0
   a=rtpmap:0 PCMU/8000

   --unique-boundary-1
   Content-Type: multipart/signed;
     protocol="application/pkcs7-signature";
     micalg=sha1; boundary=boundary42
   Content-Length: 608

   --boundary42
   Content-Type: message/sipfrag
   Content-Disposition: auth-id; handling=optional



Peterson                Expires December 30, 2002              [Page 14]


Internet-Draft                SIP Identity                     July 2002


   From: Alice <sip:alice@atlanta.com>
   To: Bob <sip:bob@biloxi.com>
   Contact: <sip:alice@pc33.atlanta.com>
   Date: Thu, 21 Feb 2002 13:02:03 GMT
   Call-ID: a84b4c76e66710
   Cseq: 314159 INVITE

   --boundary42
   Content-Type: application/pkcs7-signature; name=smime.p7s
   Content-Transfer-Encoding: base64
   Content-Disposition: attachment; filename=smime.p7s;
      handling=required

   ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
   4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
   n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
   7GhIGfHfYT64VQbnj756

   --boundary42--

   --unique-boundary-1--






























Peterson                Expires December 30, 2002              [Page 15]


Internet-Draft                SIP Identity                     July 2002


6. Receiving an Authenticated Identity

   There are a number of ways that identity information can be presented
   in a SIP request, and all of them must be reconcilable - that is,
   there must be a way to arrive at the identity that should be
   displayed to the user as the caller's identity, and so forth.

   It is therefore RECOMMENDED in this document that these forms of
   identity be reduced into two broad categories: suspect and valid
   identities.  All of the following SHOULD be considered suspect by
   recipients:

   o  Recipients may receive a normal From header field in the SIP
      message - unsigned and unverified.  All SIP requests must contain
      such a header, but in some cases it may not purport to contain a
      usable value (it may assert an anonymous identity), and no other
      identity might be asserted by the request.

   o  Recipients may receive a From header in an authenticated identity
      body that was signed by a self-signed certificate that is
      unrecognized and/or untrusted by the user, or signed by an
      authentication service using a certificate authority that the user
      cannot verify.

   o  Recipients may receive a From header in an authenticated identity
      body that has been signed by an authentication service with a
      valid certificate, but which has internal consistency problems:
      the hostname asserted by the certificate may not correspond to the
      domain in the From header, the Date may be obviously stale, the
      Call-ID may be a repeat of a recently received value, or mandatory
      headers may be missing from the authenticated identity body.

   Recipients may also unknowingly receive From headers in encrypted
   bodies which they cannot decrypt (see Section 8.2) that, of course,
   cannot be usable identities.

   The following are identities that SHOULD be considered valid by a
   recipient:

   o  Recipients may receive a From header in an authenticated identity
      body that has been signed by a self-signed certificate that is
      recognized and trusted by the recipient.

   o  Recipients may receive a From header in an authenticated identity
      body that has been signed by an end-user certificate issued by a
      certificate authority that is recognized and trusted by the
      recipient.




Peterson                Expires December 30, 2002              [Page 16]


Internet-Draft                SIP Identity                     July 2002


   o  Recipients may receive a From header in an authenticated identity
      body that has been signed by an authentication service that
      properly follows the practices described in Section 4.

   The exact behavior that is followed on receipt of a suspect or valid
   identity varies with the role of the recipient.

6.1 Proxy Server Handling

   Proxy servers generally should not attempt to inspect MIME bodies.
   However, intermediaries that implement the authentication service
   logical role MAY inspect MIME bodies in order to find one with a
   Content-Disposition of 'auth-id'.

   For the most part, the actual value of an authenticated identity is
   not likely to be of interest to a proxy server, though it MAY refuse
   to process a request that does not contain a valid authenticated
   identity body (using the 428 request, as described in Section 5.3).
   However, proxy servers MAY additionally maintain lists of known
   problem users that are banned from making requests, for example, and
   subsequently reject some requests after comparing their authenticated
   identities to this list.

6.2 User Agent Handling

   A user agent needs to determine which identity for the originator of
   a request should be displayed to the user, perhaps as a 'Caller-ID'
   function.  The following is a RECOMMENDED set of precedence rules for
   arriving at a single identity that should be displayed.

   If one valid form of identity is present, the user agent displays
   that identity.  If both valid forms of identity are present, the
   authenticated identity (rather than a recognized self-signed S/MIME
   signature) is preferred, but both potentially are viewable by a user.

   If neither of the valid forms of identity are available, the user
   agent displays the normal From field in the SIP message, but other
   identities are viewable by a user.  However, if that From field would
   display an anonymous identity, the user agent SHOULD display another
   value instead (probably an identity in a signed S/MIME body).

   When it displays an identity to its user, a user agent SHOULD also
   have some way of designating between a valid and suspect identity
   that is easy for the user to distinguish.

   Note that user agents also need to determine the identity of the
   originator of a request for the purposes of per-user blocking or
   screening before the user is alerted and any identity is displayed.



Peterson                Expires December 30, 2002              [Page 17]


Internet-Draft                SIP Identity                     July 2002


   Generally, if any of the asserted identities in a request match an
   identity that is blocked, the user should not be alerted and the
   request SHOULD be rejected.
















































Peterson                Expires December 30, 2002              [Page 18]


Internet-Draft                SIP Identity                     July 2002


7. Identity in Responses

   Many of the practices described in the preceding sections can be
   applied to responses as well as requests, with some important
   differences.  Primarily, the distinction is that a response cannot be
   challenged or resubmitted in the same manner as a request.  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 the registrar is in a reasonable position to act as an
   authentication service for responses.

   An authentication service that acts as a registrar can add to a
   response an authenticated identity body that corresponds to the
   identity of the originator of that response in roughly the same
   manner described in Section 5.2 - the authentication service adds the
   authenticated identity body to a response before it forwards the
   response towards the originator of the request.  There is no way for
   an authentication service to perform a function for responses
   comparable to the mechanism described in Section 5.3.

   The same rules for the creation of the authentication identity body
   for requests given in Section 5.1 apply to responses, including the
   mandatory and optional inclusion of various headers in
   'message/sipfrag' bodies, with the following exception - when the
   authentication service creates the authenticated identity body, it
   should substitute the actual identity of the user (derived, as
   described in Section 4.2, from the username and realm for which the
   user has registered) for any conflicting value in the To header field
   of the response before signing the response.

   When the originating user agent of a request receives a response
   containing an authenticated identity body, it SHOULD compare the
   identity in the To header field of the authenticated identity body of
   the response with the original value of the To header field in the
   request.  If these represent different identities, the user agent
   SHOULD render the identity in the authenticated identity body of the
   response to its user.  Note that a discrepancy in these identity
   fields is not necessary an indication of a security breach; normal
   retargeting may simply have directed the request to a different final
   destination.  User agents might furthermore indicate that this
   identity is suspect or valid in accordance with the guidelines given
   in Section 6.








Peterson                Expires December 30, 2002              [Page 19]


Internet-Draft                SIP Identity                     July 2002


8. Selective Sharing of Identity

   Most of the time, there is no need to restrict the propagation of
   verified identities in the network.  User agents and intermediaries
   benefit from receiving verified identities.  However, in some cases
   intermediaries wish to restrict the distribution of identity
   information, for example if

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

   o  the originating user agent has requested privacy, and the
      unregulated distribution of the authenticated identity body would
      violate that request.

   If it is not appropriate to share an authenticated identity, an
   authenticated identity body SHOULD NOT be created and distributed.
   However, in some cases there may be other entities in the
   administrative domain of the authentication service 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 the request.  For that
   reason, it may be appropriate to circulate authenticated identity
   bodies among a controlled set of entities.  For that purpose, an
   encryption mechanism for authenticated identities is provided.

8.1 Requesting Privacy

   When users provide credentials to an authentication service, they MAY
   explicitly notify the service that they do not wish their
   authenticated identity to be circulated.  Usually, the user in
   question would also be taking other steps to preserve their privacy
   (perhaps by including an anonymous From header).

   Therefore, authentication services MUST support the privacy
   mechanisms described in [3].  Users requesting privacy should also
   support the mechanisms described in that document.

   In particular, this document uses an identity-specific priv-value
   that can appear in the Privacy header, a value of 'id'.  This Privacy
   value requests that the results of authentication should not be
   shared by the authenticating server.  An authentication service
   SHOULD NOT create an authenticated identity body for a request when
   'id' privacy has been requested.  If such a body is created, it MUST
   be encrypted.





Peterson                Expires December 30, 2002              [Page 20]


Internet-Draft                SIP Identity                     July 2002


8.2 Encryption of Identity

   Many SIP entities that support the use of S/MIME for signatures will
   also support S/MIME encryption.  Encryption of a body prevents any
   parties other those that hold the decryption key from inspecting the
   body.  Note that the key used for encryption SHOULD be unrelated to
   the public key in a certificate that is used by an authentication
   service to prove its identity.

   While encryption of an authenticated identity body entails that only
   the holder of a specific key can decrypt the body, that single key
   could be distributed throughout a network of hosts that exist under
   common policies.  The security of the body is therefore predicated on
   the secure distribution of the key.  However, for some networks (in
   which there are federations of trusted hosts under a common policy),
   the widespread distribution of a decryption key could be appropriate.
   Some telephone networks, for example, might require this model.

   When an authenticated identity is encrypted, the authenticated
   identity body SHOULD always be encrypted before it is signed.  Note
   that this means that the recipients of the request, even if they are
   unable to inspect the authenticated identity body, will still be able
   to see which authentication service signed that body (although it
   will not necessarily be obvious that the body contains an
   authenticated identity).  An example of a signed and encrypted
   authenticated identity MIME body follows:

8.3 Example of Encryption

   The following is an example of an encrypted and signed authenticated
   identity body (without any of the preceding SIP headers).  In a
   rendition of this body sent over the wire, the text wrapped in
   asterisks would be encrypted.


















Peterson                Expires December 30, 2002              [Page 21]


Internet-Draft                SIP Identity                     July 2002


   Content-Type: multipart/signed;
     protocol="application/pkcs7-signature";
     micalg=sha1; boundary=boundary42
   Content-Length: 568

   --boundary42

   Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
     name=smime.p7m
   Content-Transfer-Encoding: base64
   Content-Disposition: attachment; filename=smime.p7m
     handling=required
   Content-Length: 231

   ***********************************************************
   * Content-Type: message/sipfrag                           *
   * Content-Disposition: auth-id; handling=optional         *
   *                                                         *
   * From: sip:alice@atlanta.com                             *
   * Call-ID: a84b4c76e66710                                 *
   * Date: Thu, 21 Feb 2002 13:02:03 GMT                     *
   ***********************************************************

   --boundary42

   Content-Type: application/pkcs7-signature; name=smime.p7s
   Content-Transfer-Encoding: base64
   Content-Disposition: attachment; filename=smime.p7s;
      handling=required

   ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
   4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
   n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
   7GhIGfHfYT64VQbnj756

   --boundary42--















Peterson                Expires December 30, 2002              [Page 22]


Internet-Draft                SIP Identity                     July 2002


9. Security Considerations

   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 that
   corresponds to the realm in a challenge, then it is possible that a
   rogue server is attempting to pose as a authentication service for a
   realm that it does not control, possibly in an attempt to collect
   valid user passwords for that realm.

   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 will be used to reach the remote server.

   The certificates that are required to operate an authentication
   service need to assert only the hostname of the authentication
   service, and for that reason, existing certificate authorities could
   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                Expires December 30, 2002              [Page 23]


Internet-Draft                SIP Identity                     July 2002


10. IANA Considerations

   This document defines a new MIME Content-Disposition disposition-type
   value of 'auth-id'.  This value is reserved for MIME bodies that
   contain an authenticated identity, as described in section Section
   5.1.

   This document also defines a new SIP status code, 428 Use
   Authenticated Identity.  The use of this status code is further
   described below in Section 5.3.

   Finally, this document also uses a new priv-value for the Privacy
   header specified in [3], the token 'id'.  This is further described
   in Section 8.1.





































Peterson                Expires December 30, 2002              [Page 24]


Internet-Draft                SIP Identity                     July 2002


References

   [1]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
        Session Initiation Protocol", draft-ietf-sip-rfc2543bis-09 (work
        in progress), February 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)", draft-peterson-sip-privacy-00 (work in
        progress), April 2002.

   [4]  Sparks, R., "Internet Media Types message/sip and
        message/sipfrag", draft-sparks-sip-mimetypes-01 (work in
        progress), March 2002.


Author's Address

   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/




















Peterson                Expires December 30, 2002              [Page 25]


Internet-Draft                SIP Identity                     July 2002


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.














































Peterson                Expires December 30, 2002              [Page 26]


Internet-Draft                SIP Identity                     July 2002


Appendix B. To Do

   S/MIME authentication: If the authentication between the client and
      server is performed with S/MIME, possibly using a shared secret, a
      number of optimizations could be realized for this mechanism
      (essentially, the client could provide a version of the token that
      it asks the server to sign and/or encrypt).

   Priority of encryption/signing: When privacy is requested, should an
      auth service encrypt then sign, or sign then encrypt? In the
      former case, you may lose some integrity protection.  In the
      latter case, the certificate of the authentication service is
      associated with the message.  Need more analysis - sign then
      encrypt may be preferable.

   Identifying a canonical auth service: A lot of resistance was offered
      to the concept of a hostname convention for authentication
      services.  However, there must be some way for a recipient of an
      authenticated identity body to know that it was generated by a
      (the?) canonical authentication service of a particular
      administrative domain.  How can this be communicated? Perhaps with
      a certificate attribute?

   Assertion roles: Do we need a way to tie an authenticated identity
      body to a particular form of identity (called, calling,
      forwarding, referring, etc)? Currently, an authenticated identity
      body represents the identity of the originator of the message.
























Peterson                Expires December 30, 2002              [Page 27]


Internet-Draft                SIP Identity                     July 2002


Appendix C. Changelog

   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






































Peterson                Expires December 30, 2002              [Page 28]


Internet-Draft                SIP Identity                     July 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  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.



















Peterson                Expires December 30, 2002              [Page 29]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/