[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
SIPPING WG                                                   C. Jennings
Internet-Draft                                       Cisco Systems, Inc.
Expires: October 31, 2002                                    May 2, 2002


    Extensions to the Session Initiation Protocol (SIP) for Network
               Asserted Identity within Trusted Networks
                   draft-jennings-sipping-nai-00.txt

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 October 31, 2002.

Copyright Notice

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

Abstract

   This document describes extensions to SIP 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 are only applicable inside an
   administrative domain, or among federations of administrative domains
   with previously agreed-upon policies for usage of such information.
   This document does NOT offer a general privacy or identity model
   suitable for inter-domain use or use in the Internet at large.






Jennings                Expires October 31, 2002                [Page 1]


Internet-Draft        SIP Network Asserted Identity             May 2002


Table of Contents

   1.    Applicability Statement  . . . . . . . . . . . . . . . . . .  3
   2.    Conventions  . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.    Overview . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   5.    Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . .  5
   6.    User Agent Behavior  . . . . . . . . . . . . . . . . . . . .  6
   7.    Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . .  6
   7.1   The Network-Asserted-ID Header . . . . . . . . . . . . . . .  6
   7.2   The "nai" Privacy Type . . . . . . . . . . . . . . . . . . .  7
   7.3   Examples . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   7.3.1 Network Asserted Identity passed to trusted gateway  . . . .  7
   7.3.2 Network Asserted Identity withheld . . . . . . . . . . . . .  9
   8.    Comparison to Requirements . . . . . . . . . . . . . . . . . 11
   9.    Security Considerations  . . . . . . . . . . . . . . . . . . 11
   10.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . 12
   10.1  Registration of "Network-Asserted-ID" SIP header . . . . . . 12
   10.2  Registration of "nai" privacy type  for SIP Privacy header . 12
   11.   Open Issues: . . . . . . . . . . . . . . . . . . . . . . . . 12
   12.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 13
         Normative References . . . . . . . . . . . . . . . . . . . . 13
         Informational References . . . . . . . . . . . . . . . . . . 13
         Author's Address . . . . . . . . . . . . . . . . . . . . . . 13
         Full Copyright Statement . . . . . . . . . . . . . . . . . . 14


























Jennings                Expires October 31, 2002                [Page 2]


Internet-Draft        SIP Network Asserted Identity             May 2002


1. Applicability Statement

   This document describes 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 are only applicable inside an
   administrative domain, or among federations of administrative domains
   with previously agreed-upon policies for usage of such information.
   Such a "network" is explicitly trusted by its users and end-systems
   to either publicly assert the identity of each party, or be
   responsible for withholding that identity outside of the trusted
   domain or federation of domains if privacy is requested.  The means
   by which the network determines the identity to assert is outside the
   scope of this document.

   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
   here.  Furthermore, since the asserted identities are not
   cryptographically certified, they are subject to forgery, replay, and
   falsification in any architecture that does not provide full
   transitive trust.  The asserted identities also lack an indication of
   who is asserting the identity, and therefore the assertions are not
   useful outside of the federation of domains, where such information
   would be crucial in order to determine the validity or value of the
   assertion.

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

   It should be noted, that the mechanisms described in this draft are
   not intended to be used for user-asserted identity.  As described
   above, the mechanisms are merely intended to enable trusted
   intermediaries to assert an identity for users.

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

   For the purpose of definitions within this document, trust is a



Jennings                Expires October 31, 2002                [Page 3]


Internet-Draft        SIP Network Asserted Identity             May 2002


   transitive property.  If A trusts B and B trusts C, then A,B, and C
   are all in the same trust domain.

   For one node to consider another node trusted, it means that the node
   is willing to delegate to all the nodes in that trust domain the
   requirements and responsibilities that this draft specifies.  It also
   means the node is willing to share the private network identity
   information with all the nodes in the trust domain.  For one node to
   trust another node, it must be sure that it is communicating with the
   correct node, that this node has been administratively added to the
   trust domain, and that this communication can not be intercepted,
   modified, or replayed by any node that is not part of the trust
   domain.

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

3. Introduction

   Various providers which attempt to offer a telephony service over IP
   networks have selected SIP as a base protocol.  These environments
   require a way for trusted network elements (for example SIP proxy
   servers) to communicate the identity of users using such a service,
   yet also need to withhold this information from untrusted entities
   under certain circumstances.  Such networks typically assume some
   level of transitive trust.

   These networks need to interoperate with some basic 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.  For example, a caller that
   wants to maintain privacy and consequently provides unintelligible
   information in the SIP From header field will not be identifiable to
   SIP entities that do not directly perform SIP authentication.
   However, this will prevent certain services, e.g., call trace, from
   working in the 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].  A previous
   attempt to solve this problem ([6]), from which this work was
   derived, has not generated working group consensus.  A more
   comprehensive mechanism ([7]) which uses cryptography to address this
   problem is the subject of future analysis by the SIP working group.




Jennings                Expires October 31, 2002                [Page 4]


Internet-Draft        SIP Network Asserted Identity             May 2002


   Providing privacy in an IP network is more complicated than in the
   PSTN.  In IP networks the participants in a session will normally
   exchange IP traffic directly.  The IP addresses used for these
   sessions may themselves reveal some privacy.  A general purpose
   mechanism for providing privacy in a SIP environment is discussed in
   [2].  This document extends these mechanism to compensate for the
   information it adds.

4. Overview

   The mechanism proposed in this draft results in a header that looks
   like:

        Network-Asserted-ID: "Cullen Jennings" <fluffy@cisco.com>

   An authenticating proxy which receives a message can authenticate the
   user associated with the UAC using an appropriate mechanism (for
   example: Digest authentication, or TLS mutual authentication).  The
   proxy then inserts a Network-Asserted-ID header in the message and
   forwards it on to other trusted proxies.  A proxy that is about to
   forward a message to an untrusted proxy or UA, removes the Network-
   Asserted-ID header if the user requested that this information be
   kept private.  Users can request this type of privacy by including a
   Privacy header with the "nai" privacy type in their request.

5. Proxy Behavior

   When a proxy receives a message it may be from a trusted or untrusted
   SIP entity.  When a proxy receives a request from a untrusted
   element, the proxy SHOULD authenticate the user, and using the
   identity which results from this authentication it MAY insert a
   Network-Asserted ID header.  If a Network-Asserted-ID header is
   already present in the message, 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 discard the user-provided Network-Asserted-ID header.
   In this case, the proxy MAY add a Network-Asserted-ID header of its
   own construction, or it MAY refuse to forward the request and return
   a 403 Forbidden response instead.  If no Network-Asserted-ID header
   is present in the request, and the user has multiple valid identities
   known to the proxy server, the proxy MAY use the From header as a
   similar hint.

   If the proxy receives a message (request or response) from a trusted
   element, it MAY use the information in the Network-Asserted-ID header
   as if it had authenticated the user itself.  For the received message
   to be trusted, the receiving proxy MUST be sure it came from a



Jennings                Expires October 31, 2002                [Page 5]


Internet-Draft        SIP Network Asserted Identity             May 2002


   trusted SIP element,  and that the message was not tampered with in
   transit.

   When a proxy forwards a message to another element, it must first
   determine if that element is trusted or untrusted.  If the element is
   trusted, the proxy MAY include the Network-Asserted-ID header.  If
   the element is not trusted, then the proxy MUST examine the Privacy
   header (if present) to determine if the user requested that this
   information be kept private by specifying the "nai" privacy type.  If
   so, the proxy MUST remove the Network-Asserted-ID header.  In
   addition, for backward compatibility, the proxy SHOULD examine the
   From field for an anonymous value and similarly use this as an
   indication that the user would like this information to remain
   private.  Otherwise the proxy is encouraged to remove the Network-
   Asserted-ID header but MAY choose not to.

6. User Agent Behavior

   In general, a User Agent Client does not need to insert a Network-
   Asserted-ID header.  If a UAC is confident that it is sending a
   request to a trusted outbound proxy, and it has multiple possible
   network asserted identities, it MAY place the identity that it wishes
   the proxy to assert for it as a hint in a Network-Asserted-ID header.
   TLS server authentication provides one possible mechanism by which
   the UAC can determine that the message is going to the correct proxy.

   If a User Agent Server receives a message from an untrusted previous
   hop, it SHOULD ignore any Network-Asserted-ID header, but it MAY
   present the information to the user in the same manner as an
   unverified From address, with a warning that this information is not
   verified in any way.  If a UAS receives a Network-Asserted-ID from a
   trusted entity, then it MAY use the information but it MUST ensure
   that it does not forward the information to any untrusted element.
   For example, in the case of an anonymous call going to a PSTN
   gateway, the gateway MAY pass the Network-Asserted-ID information to
   the PSTN but it must make sure the call is appropriately signaled so
   that this information will not be leaked outside of an appropriate
   trust boundary.

7. Formal Syntax

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

7.1 The Network-Asserted-ID Header

   The Network-Asserted-ID header is used among trusted SIP entities
   (typically intermediaries) to carry the identity of the user sending



Jennings                Expires October 31, 2002                [Page 6]


Internet-Draft        SIP Network Asserted Identity             May 2002


   a SIP message as it was verified by authentication with a trusted
   entity.

      NetworkAssertedID = "Network-Asserted-ID" HCOLON ( name-addr / addr-spec )


   A Network-Asserted-ID header MUST contain exactly one name-addr or
   addr-spec.  Only a single Network-Asserted-ID header can be present
   in a SIP message.  It is worth noting that Proxies can (and will) add
   and remove this header.

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

        Header field         where   proxy   ACK  BYE  CAN  INV  OPT  REG
        ------------         -----   -----   ---  ---  ---  ---  ---  ---
        Network-Asserted-ID           adr     -    o    -    o    o    -


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


7.2 The "nai" 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 SIP Privacy header 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.

        priv-value = "header" / "session" / "nai" / token

        Example:

                Privacy: nai



7.3 Examples

7.3.1 Network Asserted Identity passed to trusted gateway

   In this example, proxy.cisco.com creates a Network-Asserted-ID header
   from an identity it discovered from SIP Digest authentication.  It



Jennings                Expires October 31, 2002                [Page 7]


Internet-Draft        SIP Network Asserted Identity             May 2002


   forwards this information to a trusted proxy which forwards it to a
   trusted gateway.


   * 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@invalid.address>;tag=9802748
   Call-ID: 245780247857024504
   CSeq: 1 INVITE
   Max-Forwards: 70
   Privacy: nai

   * 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@invalid.address>;tag=9802748
   Call-ID: 245780247857024504
   CSeq: 1 INVITE
   Proxy-Authenticate: .... realm="cisco.com"

   * F3   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@invalid.address>;tag=9802748
   Call-ID: 245780247857024504
   CSeq: 2 INVITE
   Max-Forwards: 70
   Privacy: nai
   Proxy-Authorization: .... realm="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@invalid.address>;tag=9802748
   Call-ID: 245780247857024504
   CSeq: 2 INVITE
   Max-Forwards: 69
   Network-Asserted-ID: "14085264000" <sip:fluffy@cisco.com>



Jennings                Expires October 31, 2002                [Page 8]


Internet-Draft        SIP Network Asserted Identity             May 2002


   Privacy: nai

   * 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@invalid.address>;tag=9802748
   Call-ID: 245780247857024504
   CSeq: 2 INVITE
   Max-Forwards: 68
   Network-Asserted-ID: "14085264000" <sip:fluffy@cisco.com>
   Privacy: nai




7.3.2 Network Asserted Identity withheld

   In this example, the User Agent provides a hint to its first hop
   proxy, which it uses after verifying this identity with SIP Digest
   authentication.  The first proxy creates a Network-Asserted-ID header
   and forwards it to a trusted proxy (outbound.cisco.com).  The next
   proxy removes the Network-Asserted-ID header, and the request for
   Privacy before forwarding this request onward to the untrusted
   biloxi.com proxy server.


   * 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@invalid.address>;tag=9802748
   Call-ID: 245780247857024504
   CSeq: 1 INVITE
   Max-Forwards: 70
   Network-Asserted-ID: "Cullen Jennings" <sip:fluffy@vovida.org>
   Privacy: nai

   * 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@invalid.address>;tag=9802748
   Call-ID: 245780247857024504



Jennings                Expires October 31, 2002                [Page 9]


Internet-Draft        SIP Network Asserted Identity             May 2002


   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@invalid.address>;tag=9802748
   Call-ID: 245780247857024504
   CSeq: 2 INVITE
   Max-Forwards: 70
   Network-Asserted-ID: "Cullen Jennings" <sip:fluffy@vovida.org>
   Privacy: nai
   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@invalid.address>;tag=9802748
   Call-ID: 245780247857024504
   CSeq: 2 INVITE
   Max-Forwards: 69
   Network-Asserted-ID: "Cullen Jennings" <sip:fluffy@vovida.org>
   Privacy: nai

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

   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@invalid.address>;tag=9802748
   Call-ID: 245780247857024504
   CSeq: 2 INVITE
   Max-Forwards: 68

   * 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



Jennings                Expires October 31, 2002               [Page 10]


Internet-Draft        SIP Network Asserted Identity             May 2002


   To: <sip:bob@biloxi.com>
   From: "Anonymous" <sip:anonymous@invalid.address>;tag=9802748
   Call-ID: 245780247857024504
   CSeq: 2 INVITE
   Max-Forwards: 67





8. Comparison to Requirements

   Some other approaches have suggested that the header should also
   include information about who asserted it.  Inside the trust domain,
   this is well known, the trust domain asserted it.  Outside the trust
   domain, this information can not be trusted and therefore should not
   be used.  Since there was no use for it in either case, it was not
   included.

   The requirements request that the identity of the calling and the
   called users are supported.  This is determined from the context of
   the messages.  If the message is going from the UAC to the UAS, then
   the network-ID header asserts the identity of the UAC while for
   messages going the other direction it asserts the identity of the
   UAS.

   The requirements only require the ability to assert a single identity
   though they mention it may be possible to extend to more later.  This
   was explicitly not done in this document because it is unnecessarily
   complicated.

9. 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 conceal their
   identities from the network.  Information which the user designates
   as 'private' can be inspected by any intermediaries participating in
   the trusted network.   This information is passed by transitive
   trust, which is only as reliable as the weakest link in the chain of
   trust.

   When a trusted entity has determined the identity information for a
   user that wishes to remain private, and the trusted entity then sends
   a message to any destination with that party's identity in a Network-
   Asserted-ID header, the entity MUST take precautions to protect the
   identity information from eavesdropping and interception to protect
   the confidentiality and integrity of that identity information.  The



Jennings                Expires October 31, 2002               [Page 11]


Internet-Draft        SIP Network Asserted Identity             May 2002


   use of transport or network layer hop-by-hop security mechanisms,
   such as TLS or IPSec, can satisfy this requirement.

   Finally, a user agent or proxy can only assume that a privacy request
   will be honored if it is sent to a trusted entity.  Thus, if a user
   agent or proxy does not know if its SIP message (request or response)
   is sent to a trusted entity (proxy or UA), it should assume that a
   privacy request for that message will not be honored.

10. IANA Considerations

10.1 Registration of "Network-Asserted-ID" SIP header

   Name of Header:          Network-Asserted-ID

   Short form:              none

   Registrant:              Cullen Jennings
                            fluffy@cisco.com

   Normative description:   section 7.1 of this document


10.2 Registration of "nai" privacy type  for SIP Privacy header

   Name of privacy type:    nai

   Short Description:       Privacy requested for the Network-Asserted-ID header

   Registrant:              Cullen Jennings
                            fluffy@cisco.com

   Normative description:   section 7.2 of this document


11. Open Issues:

   Should an options tag be required so that the UA knows the proxy will
   support this?  It seemed like if you know you could trust the proxy
   you would already know this so it did not seem valuable.

   Should a proxy sending a message to a untrusted element be REQUIRED
   to remove the Network-ID header?

   Would "Proxy-From" be a better name for this header?






Jennings                Expires October 31, 2002               [Page 12]


Internet-Draft        SIP Network Asserted Identity             May 2002


12. Acknowledgments

   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.

Normative References

   [1]  Rosenberg, J. and H. Schulzrinne, "SIP: Session Initiation
        Protocol", draft-ietf-sip-rfc2543bis-09 (work in progress),
        February 2002.

   [2]  Peterson, J., "A Privacy Mechanism for the Session Initiation
        Protocol (SIP)", draft-peterson-sip-privacy-longterm-00 (work in
        progress), April 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.

Informational References

   [5]  Watson, M., "Short Term Requirements for Network Asserted
        Identity", draft-watson-sipping-nai-reqs-00.txt (work in
        progress), May 2002.

   [6]  Marshall, W., "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.


Author's Address

   Cullen Jennings
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   EMail: fluffy@cisco.com





Jennings                Expires October 31, 2002               [Page 13]


Internet-Draft        SIP Network 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                Expires October 31, 2002               [Page 14]