SIP WG                                                       C. Jennings
Internet-Draft                                             Cisco Systems
Expires: November 25, 2002                                   J. Peterson
                                                           NeuStar, Inc.
                                                               M. Watson
                                                         Nortel Networks
                                                            May 27, 2002


    Extensions to the Session Initiation Protocol (SIP) for Asserted
                    Identity within Trusted Networks
                  draft-ietf-sip-asserted-identity-00

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 November 25, 2002.

Copyright Notice

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

Abstract

   This document describes private extensions to SIP that enable a
   network of trusted SIP servers to assert the identity of end users or
   end systems, and the application of existing privacy mechanisms to
   the identity problem.  The use of these extensions is only applicable
   inside an administrative domain with previously agreed-upon policies
   for generation, transport and usage of such information.  This
   document does NOT offer a general privacy or identity model suitable



Jennings, et al.        Expires November 25, 2002               [Page 1]


Internet-Draft            SIP Asserted Identity                 May 2002


   for inter-domain use, or use in the Internet at large.

Table of Contents

   1.   Applicability Statement  . . . . . . . . . . . . . . . . . .   3
   2.   Conventions  . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.   Overview . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.   Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . .   6
   6.   Hints for Multiple Identities  . . . . . . . . . . . . . . .   6
   7.   Requesting Privacy . . . . . . . . . . . . . . . . . . . . .   6
   8.   User Agent Server Behavior . . . . . . . . . . . . . . . . .   7
   9.   Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . .   8
   9.1  The P-Asserted-Identity Header . . . . . . . . . . . . . . .   8
   9.2  The "id" Privacy Type  . . . . . . . . . . . . . . . . . . .   8
   10.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . .   9
   10.1 Network Asserted Identity passed to trusted gateway  . . . .   9
   10.2 Network Asserted Identity Withheld . . . . . . . . . . . . .  10
   11.  Example of Spec(T) . . . . . . . . . . . . . . . . . . . . .  12
   11.1 Protocol requirements  . . . . . . . . . . . . . . . . . . .  12
   11.2 Authentication requirements  . . . . . . . . . . . . . . . .  13
   11.3 Security requirements  . . . . . . . . . . . . . . . . . . .  13
   11.4 Scope of Trust Domain  . . . . . . . . . . . . . . . . . . .  13
   11.5 Implicit handling when no Privacy header is present  . . . .  13
   12.  Security Considerations  . . . . . . . . . . . . . . . . . .  13
   13.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  14
   13.1 Registration of "P-Asserted-Identity" SIP header field . . .  14
   13.2 Registration of "id" privacy type for SIP Privacy header . .  14
   14.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  14
        Normative References . . . . . . . . . . . . . . . . . . . .  14
        Informational References . . . . . . . . . . . . . . . . . .  15
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  15
        Full Copyright Statement . . . . . . . . . . . . . . . . . .  17


















Jennings, et al.        Expires November 25, 2002               [Page 2]


Internet-Draft            SIP Asserted Identity                 May 2002


1. Applicability Statement

   This document describes private extensions to SIP [1] that enable a
   network of trusted SIP servers to assert the identity of end users or
   end systems, and to convey indications of end-user requested privacy.
   The use of these extensions is only applicable inside a 'Trust
   Domain' as defined in Short term requirements for Network Asserted
   Identity [5].  Nodes in such a Trust Domain are explicitly trusted by
   its users and end-systems to publicly assert the identity of each
   party, and to be responsible for withholding that identity outside of
   the Trust Domain when privacy is requested.  The means by which the
   network determines the identity to assert is outside the scope of
   this document (though it commonly entails some form of
   authentication).

   A key requirement of [5] is that the behavior of all nodes within a
   given Trust Domain 'T' is known to comply to a certain set of
   specifications known as 'Spec(T)'.  Spec(T) MUST specify behavior for
   the following:

   1.  The manner in which users are authenticated

   2.  The mechanisms used to secure the communication among nodes
       within the Trust Domain

   3.  The mechanisms used to secure the communication between UAs and
       nodes within the Trust Domain

   4.  The manner used to determine which hosts are part of the Trust
       Domain

   5.  The default privacy handling when no Privacy header field is
       present

   6.  That nodes in the Trust Domain are compliant to SIP [1]

   7.  That nodes in the Trust Domain are compliant to this document

   8.  Privacy handling for identity as described in Section 7.

   An example of a suitable Spec(T) is shown in Section 11.

   This document does NOT offer a general privacy or identity model
   suitable for inter-domain use or use in the Internet at large.  Its
   assumptions about the trust relationship between the user and the
   network may not apply in many applications.  For example, these
   extensions do not accommodate a model whereby end users can
   independently assert their identity by use of the extensions defined



Jennings, et al.        Expires November 25, 2002               [Page 3]


Internet-Draft            SIP Asserted Identity                 May 2002


   here.  Furthermore, since the asserted identities are not
   cryptographically certified, they are subject to forgery, replay, and
   falsification in any architecture that does not meet the requirements
   of [5].

   The asserted identities also lack an indication of who specifically
   is asserting the identity, and so it must be assumed that the Trust
   Domain is asserting the identity.  Therefore, the information is only
   meaningful when securely received from a node known to be a member of
   the Trust Domain.

   Despite these limitations, there are sufficiently useful specialized
   deployments that meet the assumptions described above, and can accept
   the limitations that result, to warrant informational publication of
   this mechanism.  An example deployment would be a closed network
   which emulates a traditional circuit switched telephone network.

2. Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [3].

   Throughout this document requirements for or references to proxy
   servers or proxy behavior apply similarly to other intermediaries
   within a Trust Domain (ex: B2BUAs).

   The terms Identity, Network Asserted Identity and Trust Domain in
   this document have meanings as defined in [5].

3. Introduction

   Various providers offering a telephony service over IP networks have
   selected SIP as a call establishment protocol.  Their environments
   require a way for trusted network elements operated by the service
   providers (for example SIP proxy servers) to communicate the identity
   of the subscribers to such a service, yet also need to withhold this
   information from entities that are not trusted when necessary.  Such
   networks typically assume some level of transitive trust amongst
   providers and the devices they operate.

   These networks need to support certain traditional telephony services
   and meet basic regulatory and public safety requirements.  These
   include Calling Identity Delivery services, Calling Identity Delivery
   Blocking, and the ability to trace the originator of a call.  While
   baseline SIP can support each of these services independently,
   certain combinations cannot be supported without the extensions
   described in this document.  For example, a caller that wants to



Jennings, et al.        Expires November 25, 2002               [Page 4]


Internet-Draft            SIP Asserted Identity                 May 2002


   maintain privacy and consequently provides limited information in the
   SIP From header field will not be identifiable by recipients of the
   call unless they rely on some other means to discovery the identity
   of the caller.  Masking identity information at the originating user
   agent will prevent certain services, e.g., call trace, from working
   in the Public Switched Telephone Network (PSTN) or being performed at
   intermediaries not privy to the authenticated identity of the user.

   This document attempts to address this requirement using a very
   limited, simple mechanism, based on requirements in [5].  This work
   is derived from a previous attempt, [6], to solve several problems
   related to privacy and identity in Trust Domains .  A more
   comprehensive mechanism, [7] which uses cryptography to address this
   problem is the subject of current study by the SIP working group.

   Providing privacy in a SIP network is more complicated than in the
   PSTN.  In SIP networks, the participants in a session typically are
   normally able to exchange IP traffic directly without involving any
   SIP service provider.  The IP addresses used for these sessions may
   themselves reveal private information.  A general purpose mechanism
   for providing privacy in a SIP environment is discussed in [2].  This
   document applies that privacy mechanism to the problem of network
   asserted identity.

4. Overview

   The mechanism proposed in this document relies on a new header field
   called 'P-Asserted-Identity' that contains a URI (commonly a SIP URI)
   and an optional display-name, for example:


       P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@cisco.com>


   A proxy server which handles a message can, after authenticating the
   originating user in some way (for example: Digest authentication),
   insert such a P-Asserted-Identity header field into the message and
   forward it to other trusted proxies.  A proxy that is about to
   forward a message to a proxy server or UA that it does not trust MUST
   remove all the P-Asserted-Identity header field values if the user
   requested that this information be kept private.  Users can request
   this type of privacy as described in Section 7.

   The formal syntax for the P-Asserted-Identity header is presented in
   Section 9.






Jennings, et al.        Expires November 25, 2002               [Page 5]


Internet-Draft            SIP Asserted Identity                 May 2002


5. Proxy Behavior

   A proxy in a Trust Domain can receive a message from a node that it
   trusts, or a node that it does not trust.  When a proxy receives a
   message from a node it does not trust, the proxy MUST authenticate
   the originator of the message, and use the identity which results
   from this authentication to insert an appropriate P-Asserted-Identity
   header field into the message.

   If the proxy receives a message (request or response) from a node
   that it trusts, it can use the information in the P-Asserted-Identity
   header field, if any, as if it had authenticated the user itself.

   The proxy MAY add a P-Asserted-Identity header field with either a
   single SIP URI or a single SIPS URI.  Likewise, the proxy MAY add a
   P-Asserted-Identity header field with a single tel URL.

   When a proxy forwards a message to another node, it must first
   determine if it trusts that node or not.  If it trusts the node, the
   proxy does not remove any P-Asserted-Identity header fields that it
   generated itself, or that it received from a trusted source.  If it
   does not trust the element, then the proxy MUST examine the Privacy
   header field (if present) to determine if the user requested that
   asserted identity information be kept private.

6. Hints for Multiple Identities

   If an P-Asserted-Identity header is already present in the message
   that a proxy receives from an entity that it does not trust, the
   proxy MAY use this information as a hint suggesting which of multiple
   valid identities for the authenticated user should be asserted.  If
   such a hint does not correspond to any valid identity known to the
   proxy for that user, the proxy MUST not forward the user-provided P-
   Asserted-Identity header.  In this case, the proxy can add an P-
   Asserted-Identity header of its own construction, or it can reject
   the request (for example, with a 403 Forbidden).

   A user agent only sends a hint to proxy server in a Trust Domain;
   user agents MUST NOT populate the P-Asserted-Identity header in a
   message that is not sent directly to a proxy that is trusted by the
   user agent.  Were a user agent to send a message containing a P-
   Asserted-Identity header to a node outside a Trust Domain, then the
   hinted identity might not be managed appropriately by the network,
   which could have negative ramifications for privacy.

7. Requesting Privacy

   Parties who wish to request the removal of P-Asserted-Identity header



Jennings, et al.        Expires November 25, 2002               [Page 6]


Internet-Draft            SIP Asserted Identity                 May 2002


   fields before they are transmitted to an element that is not trusted
   may add the "id" privacy token to the Privacy header field.  If this
   token is present, proxies MUST remove all the P-Asserted-Identity
   header fields before forwarding messages to elements that are not
   trusted.  If the Privacy header field value is set to "none" then the
   proxy MUST NOT remove the P-Asserted-Identity header fields.

   If there is no Privacy header field, the proxy MAY include the P-
   Asserted-Identity header field or it MAY remove it.  This decision is
   a policy matter of the Trust Domain and MUST be specified in Spec(T).
   It is RECOMMENDED that unless local privacy policies prevent it, the
   P-Asserted-Identity header fields SHOULD NOT be removed, since
   removal may cause services based on Asserted Identity to fail.

   However, it should be noted that unless all users of the Trust Domain
   have access to appropriate privacy services, forwarding of the P-
   Asserted-Identity may result in disclosure of information which was
   not requested by and could not be prevented by the user.  It is
   therefore STRONGLY RECOMMENDED that all users have access to privacy
   services as described in this document.

   Formal specification of the "id" Privacy header priv-value is
   described in Section 9.2.  Some general guidelines for when users
   require privacy are given in [2].  Users will typically want to
   request "id" privacy when they are challenged for authentication.

   If multiple P-Asserted-Identity headers field values are present in a
   message, and privacy of the P-Asserted-Identity header field is
   requested, then all instances of the header field values MUST be
   removed.

8. User Agent Server Behavior

   Typically, a user agent renders the value of a P-Asserted-Identity
   header field that it receives to its user.  It may consider the
   identity provided by a Trust Domain to be privileged, or
   intrinsically more trustworthy than the From header field of a
   request.  However, any specific behavior is specific to
   implementations or services.  This document also does not mandate any
   user agent handling for multiple P-Asserted-Identity header field
   values that happen to appear in a message (such as a SIP URI
   alongside a tel URL).

   However, if a User Agent Server receives a message from a previous
   element that it does not trust, it MUST NOT use the P-Asserted-
   Identity header field in any way.

   If a UA is part of the Trust Domain from which it received a message



Jennings, et al.        Expires November 25, 2002               [Page 7]


Internet-Draft            SIP Asserted Identity                 May 2002


   containing a P-Asserted-Identity header field, then it can use the
   value freely but it MUST ensure that it does not forward the
   information to any element that is not part of the Trust Domain.

   If a UA is not part of the Trust Domain from which it received a
   message containing a P-Asserted-Identity header field, then it can
   assume this information does not need to be kept private.

9. Formal Syntax

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in RFC-2234 [4].

9.1 The P-Asserted-Identity Header

   The P-Asserted-Identity header field is used among trusted SIP
   entities (typically intermediaries) to carry the identity of the user
   sending a SIP message as it was verified by authentication.

       PAssertedID = "P-Asserted-Identity" HCOLON ( name-addr / addr-spec )

   A P-Asserted-Identity header field value MUST consist of exactly one
   name-addr or addr-spec.  There may be zero or one P-Asserted-Identity
   headers with either a SIP or SIPS URI and in addition there may be
   zero or one P-Asserted-Identity headers with a tel URL.  It is worth
   noting that proxies can (and will) add and remove this header field.

   This document adds the following entry to Table 2 of [1]:

        Header field         where   proxy   ACK  BYE  CAN  INV  OPT  REG
        ------------         -----   -----   ---  ---  ---  ---  ---  ---
        P-Asserted-Identity           adr     -    o    -    o    o    -


                                             SUB  NOT  REF  INF  UPD  PRA
                                             ---  ---  ---  ---  ---  ---
                                              o    o    o    -    -    -


9.2 The "id" Privacy Type

   This specification adds a new privacy type ("priv-value") to the
   Privacy header, defined in [2].  The presence of this privacy type in
   a Privacy header field indicates that the user would like the Network
   Asserted Identity to be kept private with respect to SIP entities
   outside the Trust Domain or trust federation with which the user
   authenticated.  Note that a user requesting multiple types of privacy
   MUST include all of the requested privacy types in its Privacy header



Jennings, et al.        Expires November 25, 2002               [Page 8]


Internet-Draft            SIP Asserted Identity                 May 2002


   field value.

        priv-value = "id"

        Example:

                Privacy: id



10. Examples

10.1 Network Asserted Identity passed to trusted gateway

   In this example, proxy.cisco.com creates a P-Asserted-Identity header
   field from an identity it discovered from SIP Digest authentication.
   It forwards this information to a trusted proxy which forwards it to
   a trusted gateway.  Note that these examples consist of partial SIP
   messages that illustrate only those headers relevant to the
   authenticated identity problem.  Via header branch parameters are
   omitted for clarity.



   * F1   useragent.cisco.com -> proxy.cisco.com

   INVITE sip:+14085551212@cisco.com SIP/2.0
   Via: SIP/2.0/TCP useragent.cisco.com
   To: <sip:+14085551212@cisco.com>
   From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
   Call-ID: 245780247857024504
   CSeq: 1 INVITE
   Max-Forwards: 70
   Privacy: id

   * F2   proxy.cisco.com -> useragent.cisco.com

   SIP/2.0 407 Proxy Authorization
   Via: SIP/2.0/TCP useragent.cisco.com
   To: <sip:+14085551212@cisco.com>
   From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
   Call-ID: 245780247857024504
   CSeq: 1 INVITE
   Proxy-Authenticate: .... realm="sip.cisco.com"

   * F3   useragent.cisco.com -> proxy.cisco.com

   INVITE sip:+14085551212@cisco.com SIP/2.0



Jennings, et al.        Expires November 25, 2002               [Page 9]


Internet-Draft            SIP Asserted Identity                 May 2002


   Via: SIP/2.0/TCP useragent.cisco.com
   To: <sip:+14085551212@cisco.com>
   From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
   Call-ID: 245780247857024504
   CSeq: 2 INVITE
   Max-Forwards: 70
   Privacy: id
   Proxy-Authorization: .... realm="sip.cisco.com" user="fluffy"

   * F4   proxy.cisco.com -> proxy.pstn.net (trusted)

   INVITE sip:+14085551212@proxy.pstn.net SIP/2.0
   Via: SIP/2.0/TCP useragent.cisco.com
   Via: SIP/2.0/TCP proxy.cisco.com
   To: <sip:+14085551212@cisco.com>
   From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
   Call-ID: 245780247857024504
   CSeq: 2 INVITE
   Max-Forwards: 69
   P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@cisco.com>
   P-Asserted-Identity: tel:+14085264000
   Privacy: id

   * F5   proxy.pstn.net -> gw.pstn.net (trusted)

   INVITE sip:+14085551212@gw.pstn.net SIP/2.0
   Via: SIP/2.0/TCP useragent.cisco.com
   Via: SIP/2.0/TCP proxy.cisco.com
   Via: SIP/2.0/TCP proxy.pstn.net
   To: <sip:+14085551212@cisco.com>
   From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
   Call-ID: 245780247857024504
   CSeq: 2 INVITE
   Max-Forwards: 68
   P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@cisco.com>
   P-Asserted-Identity: tel:+14085264000
   Privacy: id




10.2 Network Asserted Identity Withheld

   In this example, the User Agent sends an INVITE to the first proxy,
   which authenticates this with SIP Digest.  The first proxy creates a
   P-Asserted-Identity header field and forwards it to a trusted proxy
   (outbound.cisco.com).  The next proxy removes the P-Asserted-Identity
   header field, and the request for Privacy before forwarding this



Jennings, et al.        Expires November 25, 2002              [Page 10]


Internet-Draft            SIP Asserted Identity                 May 2002


   request onward to the biloxi.com proxy server which it does not
   trust.



   * F1    useragent.cisco.com -> proxy.cisco.com

   INVITE sip:bob@biloxi.com SIP/2.0
   Via: SIP/2.0/TCP useragent.cisco.com
   To: <sip:bob@biloxi.com>
   From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
   Call-ID: 245780247857024504
   CSeq: 1 INVITE
   Max-Forwards: 70
   Privacy: id

   * F2    proxy.cisco.com -> useragent.cisco.com
   SIP/2.0 407 Proxy Authorization
   Via: SIP/2.0/TCP useragent.cisco.com
   To: <sip:bob@biloxi.com>
   From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
   Call-ID: 245780247857024504
   CSeq: 1 INVITE
   Proxy-Authenticate: .... realm="cisco.com"

   * F3    useragent.cisco.com -> proxy.cisco.com

   INVITE sip:bob@biloxi.com SIP/2.0
   Via: SIP/2.0/TCP useragent.cisco.com
   To: <sip:bob@biloxi.com>
   From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
   Call-ID: 245780247857024504
   CSeq: 2 INVITE
   Max-Forwards: 70

   Privacy: id
   Proxy-Authorization: .... realm="cisco.com" user="fluffy"

   * F4    proxy.cisco.com -> outbound.cisco.com (trusted)

   INVITE sip:bob@biloxi SIP/2.0
   Via: SIP/2.0/TCP useragent.cisco.com
   Via: SIP/2.0/TCP proxy.cisco.com
   To: <sip:bob@biloxi.com>
   From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
   Call-ID: 245780247857024504
   CSeq: 2 INVITE
   Max-Forwards: 69



Jennings, et al.        Expires November 25, 2002              [Page 11]


Internet-Draft            SIP Asserted Identity                 May 2002


   P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@vovida.org>
   Privacy: id

   * F5   outbound.cisco.com -> proxy.biloxi.com (not trusted)

   INVITE sip:bob@biloxi SIP/2.0
   Via: SIP/2.0/TCP useragent.cisco.com
   Via: SIP/2.0/TCP proxy.cisco.com
   Via: SIP/2.0/TCP outbound.cisco.com
   To: <sip:bob@biloxi.com>
   From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
   Call-ID: 245780247857024504
   CSeq: 2 INVITE
   Max-Forwards: 68
   Privacy: id

   * F6   proxy.biloxi.com -> bobster.biloxi.com

   INVITE sip:bob@bobster.biloxi.com SIP/2.0
   Via: SIP/2.0/TCP useragent.cisco.com
   Via: SIP/2.0/TCP proxy.cisco.com
   Via: SIP/2.0/TCP outbound.cisco.com
   Via: SIP/2.0/TCP proxy.biloxi.com
   To: <sip:bob@biloxi.com>
   From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
   Call-ID: 245780247857024504
   CSeq: 2 INVITE
   Max-Forwards: 67
   Privacy: id




11. Example of Spec(T)

   The integrity of the mechanism described in this document relies on
   one node knowing (through configuration) that all of the nodes in a
   Trust Domain will behave in a predetermined way.  This requires the
   predetermined behavior to be clearly defined and for all nodes in the
   Trust Domain to be compliant.  The specification set that all nodes
   in a Trust Domain T must comply with is termed 'Spec(T)'.

   The remainder of this section presents an example Spec(T), which is
   not normative in any way.

11.1 Protocol requirements

   The following specifications MUST be supported:



Jennings, et al.        Expires November 25, 2002              [Page 12]


Internet-Draft            SIP Asserted Identity                 May 2002


   1.  SIP [1]

   2.  This document.


11.2 Authentication requirements

   Users MUST be authenticated using SIP Digest Authentication.

11.3 Security requirements

   Connections between nodes within the Trust Domain and between UAs and
   nodes in the Trust Domain MUST use TLS using a cipher suite of
   RSA_WITH_AES_128_CBC_SHA1.  Mutual authentication between nodes in
   the trust domain MUST be performed and confidentiality MUST be
   negotiated.

11.4 Scope of Trust Domain

   The Trust Domain specified in this agreement consists of hosts which
   posses a valid certificate which is a) signed by examplerootca.org;
   b) whose subjectAltName ends with one of the following domain names:
   trusted.div1.carrier-a.net, trusted.div2.carrier-a.net, sip.carrier-
   b.com; and c) whose domain name corresponds to the hostname in the
   subjectAltName in the certificate.

11.5 Implicit handling when no Privacy header is present

   The elements in the trust domain must support the 'id' privacy
   service therefore absence of a Privacy header can be assumed to
   indicate that the user is not requesting any privacy.  If no Privacy
   header field is present in a request, elements in this Trust Domain
   MUST act as if no privacy is requested.

12. Security Considerations

   The mechanism provided in this document is a partial consideration of
   the problem of identity and privacy in SIP.  For example, these
   mechanisms provide no means by which end users can securely share
   identity information end-to-end without a trusted service provider.
   Identity information which the user designates as 'private' can be
   inspected by any intermediaries participating in the Trust Domain.
   This information is secured by transitive trust, which is only as
   reliable as the weakest link in the chain of trust.

   When a trusted entity sends a message to any destination with that
   party's identity in a P-Asserted-Identity header field, the entity
   MUST take precautions to protect the identity information from



Jennings, et al.        Expires November 25, 2002              [Page 13]


Internet-Draft            SIP Asserted Identity                 May 2002


   eavesdropping and interception to protect the confidentiality and
   integrity of that identity information.  The use of transport or
   network layer hop-by-hop security mechanisms, such as TLS or IPSec
   with appropriate cipher suites, can satisfy this requirement.

13. IANA Considerations

13.1 Registration of "P-Asserted-Identity" SIP header field

   This document defines a new private SIP header field, "P-Asserted-
   Identity".  As recommended by the policy of the Transport Area, this
   header should be registered by the IANA in the SIP header registry,
   using the RFC number of this document as its reference.

   Name of Header:          P-Asserted-Identity

   Short form:              none

   Registrant:              Cullen Jennings
                            fluffy@cisco.com

   Normative description:
   Section 9.1 of this document


13.2 Registration of "id" privacy type for SIP Privacy header

   Name of privacy type:    id

   Short Description:       Privacy requested for Third-Party Asserted Identity

   Registrant:              Cullen Jennings
                            fluffy@cisco.com

   Normative description:
   Section 9.2 of this document


14. Acknowledgements

   Thanks to Bill Marshall and Flemming Andreason[6], Mark Watson[5],
   and Jon Peterson[7] for authoring drafts which represent the bulk of
   the text making up this document.  Thanks to many people for useful
   comments including Rohan Mahy and Paul Kyzivat.

Normative References

   [1]  Rosenberg, J. and H. Schulzrinne, "SIP: Session Initiation



Jennings, et al.        Expires November 25, 2002              [Page 14]


Internet-Draft            SIP Asserted Identity                 May 2002


        Protocol", draft-ietf-sip-rfc2543bis-09 (work in progress),
        February 2002.

   [2]  Peterson, J., "A Privacy Mechanism for the  Session Initiation
        Protocol (SIP)", draft-ietf-sip-privacy-general-00 (work in
        progress), May 2002.

   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [4]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.

   [5]  Watson, M., "Short term requirements for Network Asserted
        Identity", draft-ietf-sipping-nai-reqs-01 (work in progress),
        May 2002.

Informational References

   [6]  Andreasen, F., "SIP Extensions for Network-Asserted Caller
        Identity and Privacy within  Trusted Networks", draft-ietf-sip-
        privacy-04 (work in progress), March 2002.

   [7]  Peterson, J., "Enhancements for Authenticated Identity
        Management in the Session  Initiation Protocol (SIP)", draft-
        peterson-sip-identity-00 (work in progress), April 2002.


Authors' Addresses

   Cullen Jennings
   Cisco Systems
   170 West Tasman Drive
   MS: SJC-21/3
   San Jose, CA  95134
   USA

   Phone: +1 408 527-9132
   EMail: fluffy@cisco.com












Jennings, et al.        Expires November 25, 2002              [Page 15]


Internet-Draft            SIP Asserted Identity                 May 2002


   Jon Peterson
   NeuStar, Inc.
   1800 Sutter Street, Suite 570
   Concord, CA  94520
   USA

   Phone: +1 925/363-8720
   EMail: Jon.Peterson@NeuStar.biz


   Mark Watson
   Nortel Networks
   Maidenhead Office Park (Bray House)
   Westacott Way
   Maidenhead, Berkshire
   England

   Phone: +44 (0)1628-434456
   EMail: mwatson@nortelnetworks.com
































Jennings, et al.        Expires November 25, 2002              [Page 16]


Internet-Draft            SIP Asserted Identity                 May 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.



















Jennings, et al.        Expires November 25, 2002              [Page 17]