GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3325

Network Working Group C. Jennings Request for Comments: 3325 Cisco Systems Category: Informational J. Peterson

                                                         NeuStar, Inc.
                                                             M. Watson
                                                       Nortel Networks
                                                         November 2002
  Private Extensions to the Session Initiation Protocol (SIP) for
             Asserted Identity within Trusted Networks

Status of this Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

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

Abstract

 This document describes private extensions to the Session Initiation
 Protocol (SIP) that enable a network of trusted SIP servers to assert
 the identity of authenticated users, 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 for use between different trust domains,
 or use in the Internet at large.

Table of Contents

 1.   Applicability Statement  . . . . . . . . . . . . . . . . . .   2
 2.   Conventions  . . . . . . . . . . . . . . . . . . . . . . . .   3
 3.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   4
 4.   Overview . . . . . . . . . . . . . . . . . . . . . . . . . .   5
 5.   Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . .   5
 6.   Hints for Multiple Identities  . . . . . . . . . . . . . . .   6
 7.   Requesting Privacy . . . . . . . . . . . . . . . . . . . . .   6
 8.   User Agent Server Behavior . . . . . . . . . . . . . . . . .   7
 9.   Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . .   7
      9.1  The P-Asserted-Identity Header  . . . . . . . . . . . .   8
      9.2  The P-Preferred-Identity Header . . . . . . . . . . . .   8
      9.3  The "id" Privacy Type . . . . . . . . . . . . . . . . .   9

Jennings, et. al. Informational [Page 1] RFC 3325 SIP Asserted Identity November 2002

 10.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . .   9
      10.1 Network Asserted Identity passed to trusted gateway . .   9
      10.2 Network Asserted Identity Withheld  . . . . . . . . . .  11
 11.  Example of Spec(T) . . . . . . . . . . . . . . . . . . . . .  13
 12.  Security Considerations  . . . . . . . . . . . . . . . . . .  14
 13.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  14
      13.1 Registration of new SIP header fields . . . . . . . . .  14
      13.2 Registration of "id" privacy type for SIP Privacy header 15
 14.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  15
      Normative References . . . . . . . . . . . . . . . . . . . .  15
      Informational References . . . . . . . . . . . . . . . . . .  16
      Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  17
      Full Copyright Statement . . . . . . . . . . . . . . . . . .  18

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

Jennings, et. al. Informational [Page 2] RFC 3325 SIP Asserted Identity November 2002

 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
 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 BCP 14, 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).

Jennings, et. al. Informational [Page 3] RFC 3325 SIP Asserted Identity November 2002

 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
 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 discover 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 provide a network asserted identity service
 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 are typically
 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.

Jennings, et. al. Informational [Page 4] RFC 3325 SIP Asserted Identity November 2002

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.

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 and it wishes to add a P-
 Asserted-Identity header field, the proxy MUST authenticate the
 originator of the message, and use the identity which results from
 this authentication to insert a 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.
 If there is no P-Asserted-Identity header field present, a proxy MAY
 add one containing at most one SIP or SIPS URI, and at most one tel
 URL.  If the proxy received the message from an element that it does
 not trust and there is a P-Asserted-Identity header present which
 contains a SIP or SIPS URI, the proxy MUST replace that SIP or SIPS
 URI with a single SIP or SIPS URI or remove this header field.
 Similarly, if the proxy received the message from an element that it
 does not trust and there is a P-Asserted-Identity header present
 which contains a tel URI, the proxy MUST replace that tel URI with a
 single tel URI or remove the header field.
 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

Jennings, et. al. Informational [Page 5] RFC 3325 SIP Asserted Identity November 2002

 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 a P-Preferred-Identity header field is 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 can add a P-Asserted-Identity header of its own
 construction, or it can reject the request (for example, with a 403
 Forbidden).  The proxy MUST remove the user-provided P-Preferred-
 Identity header from any message it forwards.
 A user agent only sends a P-Preferred-Identity header field to proxy
 servers in a Trust Domain; user agents MUST NOT populate the P-
 Preferred-Identity header field 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-Preferred-Identity header
 field 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
 fields before they are transmitted to an element that is not trusted
 may add the "id" privacy token defined in this document to the
 Privacy header field.  The Privacy header field is defined in [6].
 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.
 When a proxy is forwarding the request to an element that is not
 trusted and 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 the P-Asserted-Identity header
 fields SHOULD NOT be removed unless local privacy policies prevent
 it, because removal may cause services based on Asserted Identity to
 fail.

Jennings, et. al. Informational [Page 6] RFC 3325 SIP Asserted Identity November 2002

 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 the
 user has not requested and cannot prevent.  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.3.  Some general guidelines for when users
 require privacy are given in [2].
 If multiple P-Asserted-Identity header 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 before forwarding the request to an entity that is not
 trusted.

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
 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
 the user has requested that asserted identity information be kept
 private.
 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].

Jennings, et. al. Informational [Page 7] RFC 3325 SIP Asserted Identity November 2002

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 PAssertedID-value
                    *(COMMA PAssertedID-value)
    PAssertedID-value = name-addr / addr-spec
 A P-Asserted-Identity header field value MUST consist of exactly one
 name-addr or addr-spec.  There may be one or two P-Asserted-Identity
 values.  If there is one value, it MUST be a sip, sips, or tel URI.
 If there are two values, one value MUST be a sip or sips URI and the
 other MUST be a tel URI.  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 P-Preferred-Identity Header

 The P-Preferred-Identity header field is used from a user agent to a
 trusted proxy to carry the identity the user sending the SIP message
 wishes to be used for the P-Asserted-Header field value that the
 trusted element will insert.
    PPreferredID = "P-Preferred-Identity" HCOLON PPreferredID-value
                      *(COMMA PPreferredID-value)
    PPreferredID-value = name-addr / addr-spec
 A P-Preferred-Identity header field value MUST consist of exactly one
 name-addr or addr-spec.  There may be one or two P-Preferred-Identity
 values.  If there is one value, it MUST be a sip, sips, or tel URI.
 If there are two values, one value MUST be a sip or sips URI and the
 other MUST be a tel URI.  It is worth noting that proxies can (and
 will) remove this header field.

Jennings, et. al. Informational [Page 8] RFC 3325 SIP Asserted Identity November 2002

 This document adds the following entry to Table 2 of [1]:
    Header field         where   proxy   ACK  BYE  CAN  INV  OPT  REG
    ------------         -----   -----   ---  ---  ---  ---  ---  ---
    P-Preferred-Identity          adr     -    o    -    o    o    -
                                         SUB  NOT  REF  INF  UPD  PRA
                                         ---  ---  ---  ---  ---  ---
                                          o    o    o    -    -    -

9.3 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 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 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.
  • F1 useragent.cisco.com → proxy.cisco.com
 INVITE sip:+14085551212@cisco.com SIP/2.0
 Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-123
 To: <sip:+14085551212@cisco.com>
 From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
 Call-ID: 245780247857024504
 CSeq: 1 INVITE
 Max-Forwards: 70
 Privacy: id

Jennings, et. al. Informational [Page 9] RFC 3325 SIP Asserted Identity November 2002

  • F2 proxy.cisco.com → useragent.cisco.com
 SIP/2.0 407 Proxy Authorization
 Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-123
 To: <sip:+14085551212@cisco.com>;tag=123456
 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
 Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-124
 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;branch=z9hG4bK-124
 Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-abc
 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

Jennings, et. al. Informational [Page 10] RFC 3325 SIP Asserted Identity November 2002

  • 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;branch=z9hG4bK-124
 Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-abc
 Via: SIP/2.0/TCP proxy.pstn.net;branch=z9hG4bK-a1b2
 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 that indicates it
 would prefer the identity sip:fluffy@cisco.com 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
 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;branch=z9hG4bK-a111
 To: <sip:bob@biloxi.com>
 From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
 Call-ID: 245780247857024504
 CSeq: 1 INVITE
 Max-Forwards: 70
 Privacy: id
 P-Preferred-Identity: "Cullen Jennings" <sip:fluffy@cisco.com>
  • F2 proxy.cisco.com → useragent.cisco.com

SIP/2.0 407 Proxy Authorization

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

Jennings, et. al. Informational [Page 11] RFC 3325 SIP Asserted Identity November 2002

  • F3 useragent.cisco.com → proxy.cisco.com
 INVITE sip:bob@biloxi.com SIP/2.0
 Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a123
 To: <sip:bob@biloxi.com>
 From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
 Call-ID: 245780247857024504
 CSeq: 2 INVITE
 Max-Forwards: 70
 Privacy: id
 P-Preferred-Identity: "Cullen Jennings" <sip:fluffy@cisco.com>
 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;branch=z9hG4bK-a123
 Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-b234
 To: <sip:bob@biloxi.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@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;branch=z9hG4bK-a123
 Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-b234
 Via: SIP/2.0/TCP outbound.cisco.com;branch=z9hG4bK-c345
 To: <sip:bob@biloxi.com>
 From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
 Call-ID: 245780247857024504
 CSeq: 2 INVITE
 Max-Forwards: 68
 Privacy: id

Jennings, et. al. Informational [Page 12] RFC 3325 SIP Asserted Identity November 2002

  • F6 proxy.biloxi.com → bobster.biloxi.com
 INVITE sip:bob@bobster.biloxi.com SIP/2.0
 Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a123
 Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-b234
 Via: SIP/2.0/TCP outbound.cisco.com;branch=z9hG4bK-c345
 Via: SIP/2.0/TCP proxy.biloxi.com;branch=z9hG4bK-d456
 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.
    1. Protocol requirements
       The following specifications MUST be supported:
       1. RFC 3261
       2. RFC 3325
    2. Authentication requirements
       Users MUST be authenticated using SIP Digest Authentication.
    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.

Jennings, et. al. Informational [Page 13] RFC 3325 SIP Asserted Identity November 2002

    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.
    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 that 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
 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 new SIP header fields

 This document defines two new private SIP header fields, "P-
 Asserted-Identity" and "P-Preferred-Identity".  As recommended by the
 policy of the Transport Area, these headers have been registered by
 the IANA in the SIP header registry, using the RFC number of this
 document as its reference.

Jennings, et. al. Informational [Page 14] RFC 3325 SIP Asserted Identity November 2002

 Name of Header:          P-Asserted-Identity
 Short form:              none
 Registrant:              Cullen Jennings
                          fluffy@cisco.com
 Normative description:
 Section 9.1 of this document
 Name of Header:          P-Preferred-Identity
 Short form:              none
 Registrant:              Cullen Jennings
                          fluffy@cisco.com
 Normative description:
 Section 9.2 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.3 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 Jonathan Rosenberg, Rohan Mahy and Paul Kyzivat.

Normative References

 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
     Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
     Session Initiation Protocol", RFC 3261, June 2002.
 [2] Peterson, J., "A Privacy Mechanism for the Session Initiation
     Protocol (SIP)", RFC 3323, November 2002.

Jennings, et. al. Informational [Page 15] RFC 3325 SIP Asserted Identity November 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", RFC 3324, November 2002.
 [6] Andreasen, F., "SIP Extensions for Network-Asserted Caller
     Identity and Privacy within Trusted Networks", Work in Progress.
 [7] Peterson, J., "Enhancements for Authenticated Identity Management
     in the Session Initiation Protocol (SIP)", Work in Progress.

Jennings, et. al. Informational [Page 16] RFC 3325 SIP Asserted Identity November 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
 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. Informational [Page 17] RFC 3325 SIP Asserted Identity November 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. Informational [Page 18]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3325.txt · Last modified: 2002/12/03 19:08 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki