draft-ietf-sip-asserted-identity-00.txt   draft-ietf-sip-asserted-identity-01.txt 
SIP WG C. Jennings SIP WG C. Jennings
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Expires: November 25, 2002 J. Peterson Expires: December 5, 2002 J. Peterson
NeuStar, Inc. NeuStar, Inc.
M. Watson M. Watson
Nortel Networks Nortel Networks
May 27, 2002 June 6, 2002
Extensions to the Session Initiation Protocol (SIP) for Asserted Private Extensions to the Session Initiation Protocol (SIP) for
Identity within Trusted Networks Asserted Identity within Trusted Networks
draft-ietf-sip-asserted-identity-00 draft-ietf-sip-asserted-identity-01
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 25, 2002. This Internet-Draft will expire on December 5, 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 SIP 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 systems, and the application of existing privacy mechanisms to authenticated users , and the application of existing privacy
the identity problem. The use of these extensions is only applicable mechanisms to the identity problem. The use of these extensions is
inside an administrative domain with previously agreed-upon policies only applicable inside an administrative domain with previously
for generation, transport and usage of such information. This agreed-upon policies for generation, transport and usage of such
document does NOT offer a general privacy or identity model suitable information. This document does NOT offer a general privacy or
for inter-domain use, or use in the Internet at large. identity model suitable for use between different trust domains, or
use in the Internet at large.
Table of Contents Table of Contents
1. Applicability Statement . . . . . . . . . . . . . . . . . . 3 1. Applicability Statement . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . 6 5. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . 6
6. Hints for Multiple Identities . . . . . . . . . . . . . . . 6 6. Hints for Multiple Identities . . . . . . . . . . . . . . . 6
7. Requesting Privacy . . . . . . . . . . . . . . . . . . . . . 6 7. Requesting Privacy . . . . . . . . . . . . . . . . . . . . . 7
8. User Agent Server Behavior . . . . . . . . . . . . . . . . . 7 8. User Agent Server Behavior . . . . . . . . . . . . . . . . . 7
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 8 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 8
9.1 The P-Asserted-Identity Header . . . . . . . . . . . . . . . 8 9.1 The P-Asserted-Identity Header . . . . . . . . . . . . . . . 8
9.2 The "id" Privacy Type . . . . . . . . . . . . . . . . . . . 8 9.2 The "id" Privacy Type . . . . . . . . . . . . . . . . . . . 9
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1 Network Asserted Identity passed to trusted gateway . . . . 9 10.1 Network Asserted Identity passed to trusted gateway . . . . 9
10.2 Network Asserted Identity Withheld . . . . . . . . . . . . . 10 10.2 Network Asserted Identity Withheld . . . . . . . . . . . . . 11
11. Example of Spec(T) . . . . . . . . . . . . . . . . . . . . . 12 11. Example of Spec(T) . . . . . . . . . . . . . . . . . . . . . 13
11.1 Protocol requirements . . . . . . . . . . . . . . . . . . . 12 11.1 Protocol requirements . . . . . . . . . . . . . . . . . . . 13
11.2 Authentication requirements . . . . . . . . . . . . . . . . 13 11.2 Authentication requirements . . . . . . . . . . . . . . . . 13
11.3 Security requirements . . . . . . . . . . . . . . . . . . . 13 11.3 Security requirements . . . . . . . . . . . . . . . . . . . 13
11.4 Scope of Trust Domain . . . . . . . . . . . . . . . . . . . 13 11.4 Scope of Trust Domain . . . . . . . . . . . . . . . . . . . 13
11.5 Implicit handling when no Privacy header is present . . . . 13 11.5 Implicit handling when no Privacy header is present . . . . 13
12. Security Considerations . . . . . . . . . . . . . . . . . . 13 12. Security Considerations . . . . . . . . . . . . . . . . . . 14
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14
13.1 Registration of "P-Asserted-Identity" SIP header field . . . 14 13.1 Registration of "P-Asserted-Identity" SIP header field . . . 14
13.2 Registration of "id" privacy type for SIP Privacy header . . 14 13.2 Registration of "id" privacy type for SIP Privacy header . . 14
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
Normative References . . . . . . . . . . . . . . . . . . . . 14 Normative References . . . . . . . . . . . . . . . . . . . . 15
Informational References . . . . . . . . . . . . . . . . . . 15 Informational References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16
Full Copyright Statement . . . . . . . . . . . . . . . . . . 17 Full Copyright Statement . . . . . . . . . . . . . . . . . . 17
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
Domain' as defined in Short term requirements for Network Asserted Domain' as defined in Short term requirements for Network Asserted
Identity [5]. Nodes in such a Trust Domain are explicitly trusted by Identity [5]. Nodes in such a Trust Domain are explicitly trusted by
skipping to change at page 5, line 6 skipping to change at page 5, line 6
These networks need to support certain traditional telephony services These networks need to support certain traditional telephony services
and meet basic regulatory and public safety requirements. These and meet basic regulatory and public safety requirements. These
include Calling Identity Delivery services, Calling Identity Delivery include Calling Identity Delivery services, Calling Identity Delivery
Blocking, and the ability to trace the originator of a call. While Blocking, and the ability to trace the originator of a call. While
baseline SIP can support each of these services independently, baseline SIP can support each of these services independently,
certain combinations cannot be supported without the extensions certain combinations cannot be supported without the extensions
described in this document. For example, a caller that wants to described in this document. For example, a caller that wants to
maintain privacy and consequently provides limited information in the maintain privacy and consequently provides limited information in the
SIP From header field will not be identifiable by recipients of the SIP From header field will not be identifiable by recipients of the
call unless they rely on some other means to discovery the identity call unless they rely on some other means to discover the identity of
of the caller. Masking identity information at the originating user the caller. Masking identity information at the originating user
agent will prevent certain services, e.g., call trace, from working agent will prevent certain services, e.g., call trace, from working
in the Public Switched Telephone Network (PSTN) or being performed at in the Public Switched Telephone Network (PSTN) or being performed at
intermediaries not privy to the authenticated identity of the user. intermediaries not privy to the authenticated identity of the user.
This document attempts to address this requirement using a very This document attempts to provide a network asserted identity service
limited, simple mechanism, based on requirements in [5]. This work using a very limited, simple mechanism, based on requirements in [5].
is derived from a previous attempt, [6], to solve several problems This work is derived from a previous attempt, [6], to solve several
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 typically are
normally able to exchange IP traffic directly without involving any normally able to exchange IP traffic directly without involving any
SIP service provider. The IP addresses used for these sessions may SIP 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
skipping to change at page 6, line 9 skipping to change at page 6, line 9
requested that this information be kept private. Users can request requested that this information be kept private. Users can request
this type of privacy as described in Section 7. this type of privacy as described in Section 7.
The formal syntax for the P-Asserted-Identity header is presented in The formal syntax for the P-Asserted-Identity header is presented in
Section 9. Section 9.
5. Proxy Behavior 5. Proxy Behavior
A proxy in a Trust Domain can receive a message from a node that it 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 trusts, or a node that it does not trust. When a proxy receives a
message from a node it does not trust, the proxy MUST authenticate message from a node it does not trust and it wishes to add a P-
the originator of the message, and use the identity which results Asserted-Identity header field, the proxy MUST authenticate the
from this authentication to insert an appropriate P-Asserted-Identity originator of the message, and use the identity which results from
header field into the message. 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 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.
The proxy MAY add a P-Asserted-Identity header field with either a If there is no P-Asserted-Identity header field present, a proxy MAY
single SIP URI or a single SIPS URI. Likewise, the proxy MAY add a add one containing at most one SIP or SIP URIs, and at most one tel
P-Asserted-Identity header field with a single tel URL. 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 SIP URI, the proxy MUST replace that SIP or SIPS
URI with a single SIP or SIP URI or remove it. 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 it.
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 5 skipping to change at page 7, line 13
message that is not sent directly to a proxy that is trusted by the 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- user agent. Were a user agent to send a message containing a P-
Asserted-Identity header to a node outside a Trust Domain, then the Asserted-Identity header to a node outside a Trust Domain, then the
hinted identity might not be managed appropriately by the network, hinted identity might not be managed appropriately by the network,
which could have negative ramifications for privacy. which could have 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. If this may add the "id" privacy token to the Privacy header field. The
token is present, proxies MUST remove all the P-Asserted-Identity Privacy header field is defined in [6]. If this token is present,
header fields before forwarding messages to elements that are not proxies MUST remove all the P-Asserted-Identity header fields before
trusted. If the Privacy header field value is set to "none" then the forwarding messages to elements that are not trusted. If the Privacy
proxy MUST NOT remove the P-Asserted-Identity header fields. header field value is set to "none" then the proxy MUST NOT remove
the P-Asserted-Identity header fields.
If there is no Privacy header field, the proxy MAY include the P- When a proxy is forwarding the request to an element that is not
Asserted-Identity header field or it MAY remove it. This decision is trusted and there is no Privacy header field, the proxy MAY include
a policy matter of the Trust Domain and MUST be specified in Spec(T). the P-Asserted-Identity header field or it MAY remove it. This
It is RECOMMENDED that unless local privacy policies prevent it, the decision is a policy matter of the Trust Domain and MUST be specified
P-Asserted-Identity header fields SHOULD NOT be removed, since in Spec(T). It is RECOMMENDED that unless local privacy policies
removal may cause services based on Asserted Identity to fail. prevent it, the P-Asserted-Identity header fields SHOULD NOT be
removed, since removal may cause services based on Asserted Identity
to 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 was
not requested by and could not be prevented by the user. It is not requested by and could not be prevented by the user. It is
therefore STRONGLY RECOMMENDED that all users have access to privacy therefore STRONGLY RECOMMENDED that all users have access to privacy
services as described in this document. services as 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.2. Some general guidelines for when users described in Section 9.2. Some general guidelines for when users
require privacy are given in [2]. Users will typically want to require privacy are given in [2].
request "id" privacy when they are challenged for authentication.
If multiple P-Asserted-Identity headers field values are present in a If multiple P-Asserted-Identity headers 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. removed before forwarding the request to an entity that is not
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
intrinsically more trustworthy than the From header field of a intrinsically more trustworthy than the From header field of a
request. However, any specific behavior is specific to request. However, any specific behavior is specific to
implementations or services. This document also does not mandate any implementations or services. This document also does not mandate any
user agent handling for multiple P-Asserted-Identity header field user agent handling for multiple P-Asserted-Identity header field
skipping to change at page 8, line 23 skipping to change at page 8, line 34
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].
9.1 The P-Asserted-Identity Header 9.1 The P-Asserted-Identity Header
The P-Asserted-Identity header field is used among trusted SIP The P-Asserted-Identity header field is used among trusted SIP
entities (typically intermediaries) to carry the identity of the user entities (typically intermediaries) to carry the identity of the user
sending a SIP message as it was verified by authentication. sending a SIP message as it was verified by authentication.
PAssertedID = "P-Asserted-Identity" HCOLON ( name-addr / addr-spec ) PAssertedID = "P-Asserted-Identity" HCOLON *(COMMA PAssertedID-value)
PAssertedID-value = name-addr / addr-spec
A P-Asserted-Identity header field value MUST consist of exactly one A P-Asserted-Identity header field value MUST consist of exactly one
name-addr or addr-spec. There may be zero or one P-Asserted-Identity name-addr or addr-spec. There may be one or two P-Asserted-Identity
headers with either a SIP or SIPS URI and in addition there may be values. If there is one value, it MUST be a sip, sips, or tel URI.
zero or one P-Asserted-Identity headers with a tel URL. It is worth If there are two values, one value MUST be a sip or sips URI and the
noting that proxies can (and will) add and remove this header field. 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]: This document adds the following entry to Table 2 of [1]:
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 "id" Privacy Type 9.2 The "id" Privacy Type
This specification adds a new privacy type ("priv-value") to the This specification adds a new privacy type ("priv-value") to the
Privacy header, defined in [2]. The presence of this privacy type in Privacy header, defined in [2]. The presence of this privacy type in
a Privacy header field indicates that the user would like the Network a Privacy header field indicates that the user would like the Network
Asserted Identity to be kept private with respect to SIP entities Asserted Identity to be kept private with respect to SIP entities
outside the Trust Domain or trust federation with which the user outside the Trust Domain with which the user authenticated. Note
authenticated. Note that a user requesting multiple types of privacy that a user requesting multiple types of privacy MUST include all of
MUST include all of the requested privacy types in its Privacy header the requested privacy types in its Privacy header field value.
field value.
priv-value = "id" priv-value = "id"
Example: Example:
Privacy: id Privacy: id
10. Examples 10. Examples
10.1 Network Asserted Identity passed to trusted gateway 10.1 Network Asserted Identity passed to trusted gateway
In this example, proxy.cisco.com creates a P-Asserted-Identity header In this example, proxy.cisco.com creates a P-Asserted-Identity header
field from an identity it discovered from SIP Digest authentication. field from an identity it discovered from SIP Digest authentication.
It forwards this information to a trusted proxy which forwards it to It forwards this information to a trusted proxy which forwards it to
a trusted gateway. Note that these examples consist of partial SIP a trusted gateway. Note that these examples consist of partial SIP
messages that illustrate only those headers relevant to the messages that illustrate only those headers relevant to the
authenticated identity problem. Via header branch parameters are authenticated identity problem.
omitted for clarity.
* F1 useragent.cisco.com -> proxy.cisco.com * F1 useragent.cisco.com -> proxy.cisco.com
INVITE sip:+14085551212@cisco.com SIP/2.0 INVITE sip:+14085551212@cisco.com SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-123
To: <sip:+14085551212@cisco.com> To: <sip:+14085551212@cisco.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748 From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504 Call-ID: 245780247857024504
CSeq: 1 INVITE CSeq: 1 INVITE
Max-Forwards: 70 Max-Forwards: 70
Privacy: id Privacy: id
* F2 proxy.cisco.com -> useragent.cisco.com * F2 proxy.cisco.com -> useragent.cisco.com
SIP/2.0 407 Proxy Authorization SIP/2.0 407 Proxy Authorization
Via: SIP/2.0/TCP useragent.cisco.com Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-123
To: <sip:+14085551212@cisco.com> To: <sip:+14085551212@cisco.com>;tag=123456
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748 From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504 Call-ID: 245780247857024504
CSeq: 1 INVITE CSeq: 1 INVITE
Proxy-Authenticate: .... realm="sip.cisco.com" Proxy-Authenticate: .... realm="sip.cisco.com"
* F3 useragent.cisco.com -> proxy.cisco.com * F3 useragent.cisco.com -> proxy.cisco.com
INVITE sip:+14085551212@cisco.com SIP/2.0 INVITE sip:+14085551212@cisco.com SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-124
To: <sip:+14085551212@cisco.com> To: <sip:+14085551212@cisco.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748 From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504 Call-ID: 245780247857024504
CSeq: 2 INVITE CSeq: 2 INVITE
Max-Forwards: 70 Max-Forwards: 70
Privacy: id Privacy: id
Proxy-Authorization: .... realm="sip.cisco.com" user="fluffy" Proxy-Authorization: .... realm="sip.cisco.com" user="fluffy"
* F4 proxy.cisco.com -> proxy.pstn.net (trusted) * F4 proxy.cisco.com -> proxy.pstn.net (trusted)
INVITE sip:+14085551212@proxy.pstn.net SIP/2.0 INVITE sip:+14085551212@proxy.pstn.net SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-124
Via: SIP/2.0/TCP proxy.cisco.com Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-abc
To: <sip:+14085551212@cisco.com> To: <sip:+14085551212@cisco.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748 From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504 Call-ID: 245780247857024504
CSeq: 2 INVITE CSeq: 2 INVITE
Max-Forwards: 69 Max-Forwards: 69
P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@cisco.com> P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@cisco.com>
P-Asserted-Identity: tel:+14085264000 P-Asserted-Identity: tel:+14085264000
Privacy: id Privacy: id
* F5 proxy.pstn.net -> gw.pstn.net (trusted) * F5 proxy.pstn.net -> gw.pstn.net (trusted)
INVITE sip:+14085551212@gw.pstn.net SIP/2.0 INVITE sip:+14085551212@gw.pstn.net SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-124
Via: SIP/2.0/TCP proxy.cisco.com Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-abc
Via: SIP/2.0/TCP proxy.pstn.net Via: SIP/2.0/TCP proxy.pstn.net;branch=z9hG4bK-a1b2
To: <sip:+14085551212@cisco.com> To: <sip:+14085551212@cisco.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748 From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504 Call-ID: 245780247857024504
CSeq: 2 INVITE CSeq: 2 INVITE
Max-Forwards: 68 Max-Forwards: 68
P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@cisco.com> P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@cisco.com>
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
skipping to change at page 11, line 10 skipping to change at page 11, line 24
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 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
CSeq: 1 INVITE CSeq: 1 INVITE
Max-Forwards: 70 Max-Forwards: 70
Privacy: id Privacy: id
* F2 proxy.cisco.com -> useragent.cisco.com * F2 proxy.cisco.com -> useragent.cisco.com
SIP/2.0 407 Proxy Authorization SIP/2.0 407 Proxy Authorization
Via: SIP/2.0/TCP useragent.cisco.com Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a111
To: <sip:bob@biloxi.com> To: <sip:bob@biloxi.com>;tag=123456
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748 From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504 Call-ID: 245780247857024504
CSeq: 1 INVITE CSeq: 1 INVITE
Proxy-Authenticate: .... realm="cisco.com" Proxy-Authenticate: .... realm="cisco.com"
* F3 useragent.cisco.com -> proxy.cisco.com * F3 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 Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a123
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
CSeq: 2 INVITE CSeq: 2 INVITE
Max-Forwards: 70 Max-Forwards: 70
Privacy: id Privacy: id
Proxy-Authorization: .... realm="cisco.com" user="fluffy" Proxy-Authorization: .... realm="cisco.com" user="fluffy"
* F4 proxy.cisco.com -> outbound.cisco.com (trusted) * F4 proxy.cisco.com -> outbound.cisco.com (trusted)
INVITE sip:bob@biloxi SIP/2.0 INVITE sip:bob@biloxi SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a123
Via: SIP/2.0/TCP proxy.cisco.com Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-b234
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
CSeq: 2 INVITE CSeq: 2 INVITE
Max-Forwards: 69 Max-Forwards: 69
P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@vovida.org> P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@vovida.org>
Privacy: id Privacy: id
* F5 outbound.cisco.com -> proxy.biloxi.com (not trusted) * F5 outbound.cisco.com -> proxy.biloxi.com (not trusted)
INVITE sip:bob@biloxi SIP/2.0 INVITE sip:bob@biloxi SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a123
Via: SIP/2.0/TCP proxy.cisco.com Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-b234
Via: SIP/2.0/TCP outbound.cisco.com Via: SIP/2.0/TCP outbound.cisco.com;branch=z9hG4bK-c345
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
CSeq: 2 INVITE CSeq: 2 INVITE
Max-Forwards: 68 Max-Forwards: 68
Privacy: id Privacy: id
* F6 proxy.biloxi.com -> bobster.biloxi.com * F6 proxy.biloxi.com -> bobster.biloxi.com
INVITE sip:bob@bobster.biloxi.com SIP/2.0 INVITE sip:bob@bobster.biloxi.com SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a123
Via: SIP/2.0/TCP proxy.cisco.com Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-b234
Via: SIP/2.0/TCP outbound.cisco.com Via: SIP/2.0/TCP outbound.cisco.com;branch=z9hG4bK-c345
Via: SIP/2.0/TCP proxy.biloxi.com Via: SIP/2.0/TCP proxy.biloxi.com;branch=z9hG4bK-d456
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
CSeq: 2 INVITE CSeq: 2 INVITE
Max-Forwards: 67 Max-Forwards: 67
Privacy: id Privacy: id
11. Example of Spec(T) 11. Example of Spec(T)
The integrity of the mechanism described in this document relies on The integrity of the mechanism described in this document relies on
skipping to change at page 14, line 45 skipping to change at page 15, line 14
fluffy@cisco.com fluffy@cisco.com
Normative description: Normative description:
Section 9.2 of this document Section 9.2 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 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. and H. Schulzrinne, "SIP: Session Initiation
Protocol", draft-ietf-sip-rfc2543bis-09 (work in progress), Protocol", draft-ietf-sip-rfc2543bis-09 (work in progress),
February 2002. February 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)", draft-ietf-sip-privacy-general-00 (work in
progress), May 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
[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", draft-ietf-sipping-nai-reqs-01 (work in progress),
May 2002. May 2002.
Informational References
[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", draft-ietf-sip-
privacy-04 (work in progress), March 2002. privacy-04 (work in progress), March 2002.
[7] Peterson, J., "Enhancements for Authenticated Identity [7] Peterson, J., "Enhancements for Authenticated Identity
Management in the Session Initiation Protocol (SIP)", draft- Management in the Session Initiation Protocol (SIP)", draft-
peterson-sip-identity-00 (work in progress), April 2002. peterson-sip-identity-00 (work in progress), April 2002.
Authors' Addresses Authors' Addresses
 End of changes. 

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