diff options
Diffstat (limited to 'doc/rfc/rfc3325.txt')
| -rw-r--r-- | doc/rfc/rfc3325.txt | 1011 |
1 files changed, 1011 insertions, 0 deletions
diff --git a/doc/rfc/rfc3325.txt b/doc/rfc/rfc3325.txt new file mode 100644 index 0000000..071f9f2 --- /dev/null +++ b/doc/rfc/rfc3325.txt @@ -0,0 +1,1011 @@ + + + + + + +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] + |