Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks
RFC 3325
Document | Type | RFC - Informational (December 2002; Errata) | |
---|---|---|---|
Authors | Jon Peterson , Cullen Jennings , Mark Watson | ||
Last updated | 2020-01-21 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized with errata bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3325 (Informational) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Allison Mankin | ||
Send notices to | <rohan@cisco.com> |
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 TrustShow full document text