draft-ietf-sip-asserted-identity-02.txt   rfc3325.txt 
SIP WG C. Jennings Network Working Group C. Jennings
Internet-Draft Cisco Systems Request for Comments: 3325 Cisco Systems
Expires: December 20, 2002 J. Peterson Category: Informational J. Peterson
NeuStar, Inc. NeuStar, Inc.
M. Watson M. Watson
Nortel Networks Nortel Networks
June 21, 2002 November 2002
Private Extensions to the Session Initiation Protocol (SIP) for Private Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks Asserted Identity within Trusted Networks
draft-ietf-sip-asserted-identity-02
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This memo provides information for the Internet community. It does
all provisions of Section 10 of RFC2026. not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
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 December 20, 2002.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract Abstract
This document describes private extensions to SIP that enable a This document describes private extensions to the Session Initiation
network of trusted SIP servers to assert the identity of Protocol (SIP) that enable a network of trusted SIP servers to assert
authenticated users, and the application of existing privacy the identity of authenticated users, and the application of existing
mechanisms to the identity problem. The use of these extensions is privacy mechanisms to the identity problem. The use of these
only applicable inside an administrative domain with previously extensions is only applicable inside an administrative domain with
agreed-upon policies for generation, transport and usage of such previously agreed-upon policies for generation, transport and usage
information. This document does NOT offer a general privacy or of such information. This document does NOT offer a general privacy
identity model suitable for use between different trust domains, or or identity model suitable for use between different trust domains,
use in the Internet at large. or use in the Internet at large.
Table of Contents Table of Contents
1. Applicability Statement . . . . . . . . . . . . . . . . . . 3 1. Applicability Statement . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . 6 5. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . 5
6. Hints for Multiple Identities . . . . . . . . . . . . . . . 6 6. Hints for Multiple Identities . . . . . . . . . . . . . . . 6
7. Requesting Privacy . . . . . . . . . . . . . . . . . . . . . 7 7. Requesting Privacy . . . . . . . . . . . . . . . . . . . . . 6
8. User Agent Server Behavior . . . . . . . . . . . . . . . . . 7 8. User Agent Server Behavior . . . . . . . . . . . . . . . . . 7
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 8 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 7
9.1 The P-Asserted-Identity Header . . . . . . . . . . . . . . . 8 9.1 The P-Asserted-Identity Header . . . . . . . . . . . . 8
9.2 The P-Preferred-Identity Header . . . . . . . . . . . . . . 9 9.2 The P-Preferred-Identity Header . . . . . . . . . . . . 8
9.3 The "id" Privacy Type . . . . . . . . . . . . . . . . . . . 9 9.3 The "id" Privacy Type . . . . . . . . . . . . . . . . . 9
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1 Network Asserted Identity passed to trusted gateway . . . . 10 10.1 Network Asserted Identity passed to trusted gateway . . 9
10.2 Network Asserted Identity Withheld . . . . . . . . . . . . . 11 10.2 Network Asserted Identity Withheld . . . . . . . . . . 11
11. Example of Spec(T) . . . . . . . . . . . . . . . . . . . . . 13 11. Example of Spec(T) . . . . . . . . . . . . . . . . . . . . . 13
11.1 Protocol requirements . . . . . . . . . . . . . . . . . . . 14
11.2 Authentication requirements . . . . . . . . . . . . . . . . 14
11.3 Security requirements . . . . . . . . . . . . . . . . . . . 14
11.4 Scope of Trust Domain . . . . . . . . . . . . . . . . . . . 14
11.5 Implicit handling when no Privacy header is present . . . . 14
12. Security Considerations . . . . . . . . . . . . . . . . . . 14 12. Security Considerations . . . . . . . . . . . . . . . . . . 14
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14
13.1 Registration of new SIP header fields . . . . . . . . . . . 15 13.1 Registration of new SIP header fields . . . . . . . . . 14
13.2 Registration of "id" privacy type for SIP Privacy header . . 15 13.2 Registration of "id" privacy type for SIP Privacy header 15
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
Normative References . . . . . . . . . . . . . . . . . . . . 16 Normative References . . . . . . . . . . . . . . . . . . . . 15
Informational References . . . . . . . . . . . . . . . . . . 16 Informational References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17
Full Copyright Statement . . . . . . . . . . . . . . . . . . 18 Full Copyright Statement . . . . . . . . . . . . . . . . . . 18
1. Applicability Statement 1. Applicability Statement
This document describes private extensions to SIP [1] that enable a This document describes private extensions to SIP [1] that enable a
network of trusted SIP servers to assert the identity of end users or network of trusted SIP servers to assert the identity of end users or
end systems, and to convey indications of end-user requested privacy. end systems, and to convey indications of end-user requested privacy.
The use of these extensions is only applicable inside a 'Trust The use of these extensions is only applicable inside a 'Trust
skipping to change at page 3, line 27 skipping to change at page 2, line 40
this document (though it commonly entails some form of this document (though it commonly entails some form of
authentication). authentication).
A key requirement of [5] is that the behavior of all nodes within a 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 given Trust Domain 'T' is known to comply to a certain set of
specifications known as 'Spec(T)'. Spec(T) MUST specify behavior for specifications known as 'Spec(T)'. Spec(T) MUST specify behavior for
the following: the following:
1. The manner in which users are authenticated 1. The manner in which users are authenticated
2. The mechanisms used to secure the communication among nodes 2. The mechanisms used to secure the communication among nodes within
within the Trust Domain the Trust Domain
3. The mechanisms used to secure the communication between UAs and 3. The mechanisms used to secure the communication between UAs and
nodes within the Trust Domain nodes within the Trust Domain
4. The manner used to determine which hosts are part of the Trust 4. The manner used to determine which hosts are part of the Trust
Domain Domain
5. The default privacy handling when no Privacy header field is 5. The default privacy handling when no Privacy header field is
present present
6. That nodes in the Trust Domain are compliant to SIP [1] 6. That nodes in the Trust Domain are compliant to SIP [1]
7. That nodes in the Trust Domain are compliant to this document 7. That nodes in the Trust Domain are compliant to this document
skipping to change at page 4, line 25 skipping to change at page 3, line 45
Despite these limitations, there are sufficiently useful specialized Despite these limitations, there are sufficiently useful specialized
deployments that meet the assumptions described above, and can accept deployments that meet the assumptions described above, and can accept
the limitations that result, to warrant informational publication of the limitations that result, to warrant informational publication of
this mechanism. An example deployment would be a closed network this mechanism. An example deployment would be a closed network
which emulates a traditional circuit switched telephone network. which emulates a traditional circuit switched telephone network.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [3]. document are to be interpreted as described in BCP 14, RFC 2119 [3].
Throughout this document requirements for or references to proxy Throughout this document requirements for or references to proxy
servers or proxy behavior apply similarly to other intermediaries servers or proxy behavior apply similarly to other intermediaries
within a Trust Domain (ex: B2BUAs). within a Trust Domain (ex: B2BUAs).
The terms Identity, Network Asserted Identity and Trust Domain in The terms Identity, Network Asserted Identity and Trust Domain in
this document have meanings as defined in [5]. this document have meanings as defined in [5].
3. Introduction 3. Introduction
skipping to change at page 5, line 20 skipping to change at page 4, line 42
intermediaries not privy to the authenticated identity of the user. intermediaries not privy to the authenticated identity of the user.
This document attempts to provide a network asserted identity service This document attempts to provide a network asserted identity service
using a very limited, simple mechanism, based on requirements in [5]. using a very limited, simple mechanism, based on requirements in [5].
This work is derived from a previous attempt, [6], to solve several This work is derived from a previous attempt, [6], to solve several
problems related to privacy and identity in Trust Domains . A more problems related to privacy and identity in Trust Domains . A more
comprehensive mechanism, [7] which uses cryptography to address this comprehensive mechanism, [7] which uses cryptography to address this
problem is the subject of current study by the SIP working group. problem is the subject of current study by the SIP working group.
Providing privacy in a SIP network is more complicated than in the Providing privacy in a SIP network is more complicated than in the
PSTN. In SIP networks, the participants in a session typically are PSTN. In SIP networks, the participants in a session are typically
normally able to exchange IP traffic directly without involving any able to exchange IP traffic directly without involving any SIP
SIP service provider. The IP addresses used for these sessions may service provider. The IP addresses used for these sessions may
themselves reveal private information. A general purpose mechanism themselves reveal private information. A general purpose mechanism
for providing privacy in a SIP environment is discussed in [2]. This for providing privacy in a SIP environment is discussed in [2]. This
document applies that privacy mechanism to the problem of network document applies that privacy mechanism to the problem of network
asserted identity. asserted identity.
4. Overview 4. Overview
The mechanism proposed in this document relies on a new header field The mechanism proposed in this document relies on a new header field
called 'P-Asserted-Identity' that contains a URI (commonly a SIP URI) called 'P-Asserted-Identity' that contains a URI (commonly a SIP URI)
and an optional display-name, for example: and an optional display-name, for example:
skipping to change at page 6, line 20 skipping to change at page 5, line 40
Asserted-Identity header field, the proxy MUST authenticate the Asserted-Identity header field, the proxy MUST authenticate the
originator of the message, and use the identity which results from originator of the message, and use the identity which results from
this authentication to insert a P-Asserted-Identity header field into this authentication to insert a P-Asserted-Identity header field into
the message. the message.
If the proxy receives a message (request or response) from a node 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 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. 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 If there is no P-Asserted-Identity header field present, a proxy MAY
add one containing at most one SIP or SIP URIs, and at most one tel 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 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 not trust and there is a P-Asserted-Identity header present which
contains a SIP or SIP URI, the proxy MUST replace that SIP or SIPS contains a SIP or SIPS URI, the proxy MUST replace that SIP or SIPS
URI with a single SIP or SIP URI or remove it. Similarly, if the URI with a single SIP or SIPS URI or remove this header field.
proxy received the message from an element that it does not trust and Similarly, if the proxy received the message from an element that it
there is a P-Asserted-Identity header present which contains a tel does not trust and there is a P-Asserted-Identity header present
URI, the proxy MUST replace that tel URI with a single tel URI or which contains a tel URI, the proxy MUST replace that tel URI with a
remove it. single tel URI or remove the header field.
When a proxy forwards a message to another node, it must first 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 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 proxy does not remove any P-Asserted-Identity header fields that it
generated itself, or that it received from a trusted source. If it generated itself, or that it received from a trusted source. If it
does not trust the element, then the proxy MUST examine the Privacy does not trust the element, then the proxy MUST examine the Privacy
header field (if present) to determine if the user requested that header field (if present) to determine if the user requested that
asserted identity information be kept private. asserted identity information be kept private.
6. Hints for Multiple Identities 6. Hints for Multiple Identities
skipping to change at page 7, line 14 skipping to change at page 6, line 34
directly to a proxy that is trusted by the user agent. Were a user 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 agent to send a message containing a P-Preferred-Identity header
field to a node outside a Trust Domain, then the hinted identity field to a node outside a Trust Domain, then the hinted identity
might not be managed appropriately by the network, which could have might not be managed appropriately by the network, which could have
negative ramifications for privacy. negative ramifications for privacy.
7. Requesting Privacy 7. Requesting Privacy
Parties who wish to request the removal of P-Asserted-Identity header Parties who wish to request the removal of P-Asserted-Identity header
fields before they are transmitted to an element that is not trusted fields before they are transmitted to an element that is not trusted
may add the "id" privacy token to the Privacy header field. The may add the "id" privacy token defined in this document to the
Privacy header field is defined in [6]. If this token is present, Privacy header field. The Privacy header field is defined in [6].
proxies MUST remove all the P-Asserted-Identity header fields before If this token is present, proxies MUST remove all the P-Asserted-
forwarding messages to elements that are not trusted. If the Privacy Identity header fields before forwarding messages to elements that
header field value is set to "none" then the proxy MUST NOT remove are not trusted. If the Privacy header field value is set to "none"
the P-Asserted-Identity header fields. 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 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 trusted and there is no Privacy header field, the proxy MAY include
the P-Asserted-Identity header field or it MAY remove it. This 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 decision is a policy matter of the Trust Domain and MUST be specified
in Spec(T). It is RECOMMENDED that unless local privacy policies in Spec(T). It is RECOMMENDED that the P-Asserted-Identity header
prevent it, the P-Asserted-Identity header fields SHOULD NOT be fields SHOULD NOT be removed unless local privacy policies prevent
removed, since removal may cause services based on Asserted Identity it, because removal may cause services based on Asserted Identity to
to fail. fail.
However, it should be noted that unless all users of the Trust Domain However, it should be noted that unless all users of the Trust Domain
have access to appropriate privacy services, forwarding of the P- have access to appropriate privacy services, forwarding of the P-
Asserted-Identity may result in disclosure of information which was Asserted-Identity may result in disclosure of information which the
not requested by and could not be prevented by the user. It is user has not requested and cannot prevent. It is therefore STRONGLY
therefore STRONGLY RECOMMENDED that all users have access to privacy RECOMMENDED that all users have access to privacy services as
services as described in this document. described in this document.
Formal specification of the "id" Privacy header priv-value is Formal specification of the "id" Privacy header priv-value is
described in Section 9.3. Some general guidelines for when users described in Section 9.3. Some general guidelines for when users
require privacy are given in [2]. require privacy are given in [2].
If multiple P-Asserted-Identity headers field values are present in a If multiple P-Asserted-Identity header field values are present in a
message, and privacy of the P-Asserted-Identity header field is message, and privacy of the P-Asserted-Identity header field is
requested, then all instances of the header field values MUST be requested, then all instances of the header field values MUST be
removed before forwarding the request to an entity that is not removed before forwarding the request to an entity that is not
trusted. trusted.
8. User Agent Server Behavior 8. User Agent Server Behavior
Typically, a user agent renders the value of a P-Asserted-Identity Typically, a user agent renders the value of a P-Asserted-Identity
header field that it receives to its user. It may consider the header field that it receives to its user. It may consider the
identity provided by a Trust Domain to be privileged, or identity provided by a Trust Domain to be privileged, or
skipping to change at page 8, line 18 skipping to change at page 7, line 41
values that happen to appear in a message (such as a SIP URI values that happen to appear in a message (such as a SIP URI
alongside a tel URL). alongside a tel URL).
However, if a User Agent Server receives a message from a previous 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- element that it does not trust, it MUST NOT use the P-Asserted-
Identity header field in any way. Identity header field in any way.
If a UA is part of the Trust Domain from which it received a message 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 containing a P-Asserted-Identity header field, then it can use the
value freely but it MUST ensure that it does not forward 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. 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 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 message containing a P-Asserted-Identity header field, then it can
assume this information does not need to be kept private. assume this information does not need to be kept private.
9. Formal Syntax 9. Formal Syntax
The following syntax specification uses the augmented Backus-Naur The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in RFC-2234 [4]. Form (BNF) as described in RFC-2234 [4].
skipping to change at page 9, line 15 skipping to change at page 8, line 34
Header field where proxy ACK BYE CAN INV OPT REG Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- --- ------------ ----- ----- --- --- --- --- --- ---
P-Asserted-Identity adr - o - o o - P-Asserted-Identity adr - o - o o -
SUB NOT REF INF UPD PRA SUB NOT REF INF UPD PRA
--- --- --- --- --- --- --- --- --- --- --- ---
o o o - - - o o o - - -
9.2 The P-Preferred-Identity Header 9.2 The P-Preferred-Identity Header
The P-Preferred-Identity header field is used from an user agent to a 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 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 wishes to be used for the P-Asserted-Header field value that the
trusted element will insert. trusted element will insert.
PPreferredID = "P-Preferred-Identity" HCOLON PPreferredID-value PPreferredID = "P-Preferred-Identity" HCOLON PPreferredID-value
*(COMMA PPreferredID -value) *(COMMA PPreferredID -value)
PPreferredID-value = name-addr / addr-spec PPreferredID-value = name-addr / addr-spec
A P-Preferred-Identity header field value MUST consist of exactly one 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 name-addr or addr-spec. There may be one or two P-Preferred-Identity
skipping to change at page 11, line 48 skipping to change at page 11, line 26
P-Asserted-Identity: tel:+14085264000 P-Asserted-Identity: tel:+14085264000
Privacy: id Privacy: id
10.2 Network Asserted Identity Withheld 10.2 Network Asserted Identity Withheld
In this example, the User Agent sends an INVITE that indicates it In this example, the User Agent sends an INVITE that indicates it
would prefer the identity sip:fluffy@cisco.com to the first proxy, would prefer the identity sip:fluffy@cisco.com to the first proxy,
which authenticates this with SIP Digest. The first proxy creates a which authenticates this with SIP Digest. The first proxy creates a
P-Asserted-Identity header field and forwards it to a trusted proxy P-Asserted-Identity header field and forwards it to a trusted proxy
(outbound.cisco.com). The next proxy removes the P-Asserted-Identity (outbound.cisco.com). The next proxy removes the P-Asserted-Identity
header field, and the request for Privacy before forwarding this header field and the request for Privacy before forwarding this
request onward to the biloxi.com proxy server which it does not request onward to the biloxi.com proxy server which it does not
trust. trust.
* F1 useragent.cisco.com -> proxy.cisco.com * F1 useragent.cisco.com -> proxy.cisco.com
INVITE sip:bob@biloxi.com SIP/2.0 INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a111 Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a111
To: <sip:bob@biloxi.com> To: <sip:bob@biloxi.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748 From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504 Call-ID: 245780247857024504
skipping to change at page 14, line 5 skipping to change at page 13, line 30
The integrity of the mechanism described in this document relies on The integrity of the mechanism described in this document relies on
one node knowing (through configuration) that all of the nodes in a one node knowing (through configuration) that all of the nodes in a
Trust Domain will behave in a predetermined way. This requires the Trust Domain will behave in a predetermined way. This requires the
predetermined behavior to be clearly defined and for all nodes in the predetermined behavior to be clearly defined and for all nodes in the
Trust Domain to be compliant. The specification set that all nodes Trust Domain to be compliant. The specification set that all nodes
in a Trust Domain T must comply with is termed 'Spec(T)'. in a Trust Domain T must comply with is termed 'Spec(T)'.
The remainder of this section presents an example Spec(T), which is The remainder of this section presents an example Spec(T), which is
not normative in any way. not normative in any way.
11.1 Protocol requirements 1. Protocol requirements
The following specifications MUST be supported: The following specifications MUST be supported:
1. SIP [1] 1. RFC 3261
2. This document. 2. RFC 3325
11.2 Authentication requirements 2. Authentication requirements
Users MUST be authenticated using SIP Digest Authentication. Users MUST be authenticated using SIP Digest Authentication.
11.3 Security requirements 3. Security requirements
Connections between nodes within the Trust Domain and between UAs and Connections between nodes within the Trust Domain and between
nodes in the Trust Domain MUST use TLS using a cipher suite of UAs and nodes in the Trust Domain MUST use TLS using a cipher
RSA_WITH_AES_128_CBC_SHA1. Mutual authentication between nodes in suite of RSA_WITH_AES_128_CBC_SHA1. Mutual authentication
the trust domain MUST be performed and confidentiality MUST be between nodes in the trust domain MUST be performed and
negotiated. confidentiality MUST be negotiated.
11.4 Scope of Trust Domain 4. Scope of Trust Domain
The Trust Domain specified in this agreement consists of hosts which The Trust Domain specified in this agreement consists of hosts
posses a valid certificate which is a) signed by examplerootca.org; which posses a valid certificate which is a) signed by
b) whose subjectAltName ends with one of the following domain names: examplerootca.org; b) whose subjectAltName ends with one of the
trusted.div1.carrier-a.net, trusted.div2.carrier-a.net, sip.carrier- following domain names: trusted.div1.carrier-a.net,
b.com; and c) whose domain name corresponds to the hostname in the trusted.div2.carrier-a.net, sip.carrier-b.com; and c) whose
subjectAltName in the certificate. domain name corresponds to the hostname in the subjectAltName
in the certificate.
11.5 Implicit handling when no Privacy header is present 5. Implicit handling when no Privacy header is present
The elements in the trust domain must support the 'id' privacy The elements in the trust domain must support the 'id' privacy
service therefore absence of a Privacy header can be assumed to service therefore absence of a Privacy header can be assumed to
indicate that the user is not requesting any privacy. If no Privacy indicate that the user is not requesting any privacy. If no
header field is present in a request, elements in this Trust Domain Privacy header field is present in a request, elements in this
MUST act as if no privacy is requested. Trust Domain MUST act as if no privacy is requested.
12. Security Considerations 12. Security Considerations
The mechanism provided in this document is a partial consideration of The mechanism provided in this document is a partial consideration of
the problem of identity and privacy in SIP. For example, these the problem of identity and privacy in SIP. For example, these
mechanisms provide no means by which end users can securely share mechanisms provide no means by which end users can securely share
identity information end-to-end without a trusted service provider. identity information end-to-end without a trusted service provider.
Identity information which the user designates as 'private' can be Identity information that the user designates as 'private' can be
inspected by any intermediaries participating in the Trust Domain. inspected by any intermediaries participating in the Trust Domain.
This information is secured by transitive trust, which is only as This information is secured by transitive trust, which is only as
reliable as the weakest link in the chain of trust. reliable as the weakest link in the chain of trust.
When a trusted entity sends a message to any destination with that When a trusted entity sends a message to any destination with that
party's identity in a P-Asserted-Identity header field, the entity party's identity in a P-Asserted-Identity header field, the entity
MUST take precautions to protect the identity information from MUST take precautions to protect the identity information from
eavesdropping and interception to protect the confidentiality and eavesdropping and interception to protect the confidentiality and
integrity of that identity information. The use of transport or integrity of that identity information. The use of transport or
network layer hop-by-hop security mechanisms, such as TLS or IPSec network layer hop-by-hop security mechanisms, such as TLS or IPSec
with appropriate cipher suites, can satisfy this requirement. with appropriate cipher suites, can satisfy this requirement.
13. IANA Considerations 13. IANA Considerations
13.1 Registration of new SIP header fields 13.1 Registration of new SIP header fields
This document defines two new private SIP header fields, "P-Asserted- This document defines two new private SIP header fields, "P-
Identity" and "P-Preferred-Identity". As recommended by the policy Asserted-Identity" and "P-Preferred-Identity". As recommended by the
of the Transport Area, these headers should be registered by the IANA policy of the Transport Area, these headers have been registered by
in the SIP header registry, using the RFC number of this document as the IANA in the SIP header registry, using the RFC number of this
its reference. document as its reference.
Name of Header: P-Asserted-Identity Name of Header: P-Asserted-Identity
Short form: none Short form: none
Registrant: Cullen Jennings Registrant: Cullen Jennings
fluffy@cisco.com fluffy@cisco.com
Normative description: Normative description:
Section 9.1 of this document Section 9.1 of this document
skipping to change at page 15, line 47 skipping to change at page 15, line 29
Registrant: Cullen Jennings Registrant: Cullen Jennings
fluffy@cisco.com fluffy@cisco.com
Normative description: Normative description:
Section 9.2 of this document Section 9.2 of this document
13.2 Registration of "id" privacy type for SIP Privacy header 13.2 Registration of "id" privacy type for SIP Privacy header
Name of privacy type: id Name of privacy type: id
Short Description: Privacy requested for Third-Party Asserted Identity Short Description: Privacy requested for Third-Party Asserted
Identity
Registrant: Cullen Jennings Registrant: Cullen Jennings
fluffy@cisco.com fluffy@cisco.com
Normative description: Normative description:
Section 9.3 of this document Section 9.3 of this document
14. Acknowledgements 14. Acknowledgements
Thanks to Bill Marshall and Flemming Andreason[6], Mark Watson[5], Thanks to Bill Marshall and Flemming Andreason[6], Mark Watson[5],
and Jon Peterson[7] for authoring drafts which represent the bulk of and Jon Peterson[7] for authoring drafts which represent the bulk of
the text making up this document. Thanks to many people for useful the text making up this document. Thanks to many people for useful
comments including Jonathan Rosenberg, Rohan Mahy and Paul Kyzivat. comments including Jonathan Rosenberg, Rohan Mahy and Paul Kyzivat.
skipping to change at page 16, line 16 skipping to change at page 15, line 47
14. Acknowledgements 14. Acknowledgements
Thanks to Bill Marshall and Flemming Andreason[6], Mark Watson[5], Thanks to Bill Marshall and Flemming Andreason[6], Mark Watson[5],
and Jon Peterson[7] for authoring drafts which represent the bulk of and Jon Peterson[7] for authoring drafts which represent the bulk of
the text making up this document. Thanks to many people for useful the text making up this document. Thanks to many people for useful
comments including Jonathan Rosenberg, Rohan Mahy and Paul Kyzivat. comments including Jonathan Rosenberg, Rohan Mahy and Paul Kyzivat.
Normative References Normative References
[1] Rosenberg, J. and H. Schulzrinne, "SIP: Session Initiation [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Protocol", draft-ietf-sip-rfc2543bis-09 (work in progress), Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
February 2002. Session Initiation Protocol", RFC 3261, June 2002.
[2] Peterson, J., "A Privacy Mechanism for the Session Initiation [2] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", draft-ietf-sip-privacy-general-00 (work in Protocol (SIP)", RFC 3323, November 2002.
progress), May 2002.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[4] Crocker, D. and P. Overell, "Augmented BNF for Syntax [4] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
Informational References Informational References
[5] Watson, M., "Short term requirements for Network Asserted [5] Watson, M., "Short Term Requirements for Network Asserted
Identity", draft-ietf-sipping-nai-reqs-01 (work in progress), Identity", RFC 3324, November 2002.
May 2002.
[6] Andreasen, F., "SIP Extensions for Network-Asserted Caller [6] Andreasen, F., "SIP Extensions for Network-Asserted Caller
Identity and Privacy within Trusted Networks", draft-ietf-sip- Identity and Privacy within Trusted Networks", Work in Progress.
privacy-04 (work in progress), March 2002.
[7] Peterson, J., "Enhancements for Authenticated Identity [7] Peterson, J., "Enhancements for Authenticated Identity Management
Management in the Session Initiation Protocol (SIP)", draft- in the Session Initiation Protocol (SIP)", Work in Progress.
peterson-sip-identity-00 (work in progress), April 2002.
Authors' Addresses Authors' Addresses
Cullen Jennings Cullen Jennings
Cisco Systems Cisco Systems
170 West Tasman Drive 170 West Tasman Drive
MS: SJC-21/3 MS: SJC-21/3
San Jose, CA 95134 San Jose, CA 95134
USA USA
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/