draft-ietf-sip-asserted-identity-01.txt   draft-ietf-sip-asserted-identity-02.txt 
SIP WG C. Jennings SIP WG C. Jennings
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Expires: December 5, 2002 J. Peterson Expires: December 20, 2002 J. Peterson
NeuStar, Inc. NeuStar, Inc.
M. Watson M. Watson
Nortel Networks Nortel Networks
June 6, 2002 June 21, 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-01 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 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 December 5, 2002. 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 SIP that enable a
network of trusted SIP servers to assert the identity of network of trusted SIP servers to assert the identity of
authenticated users , and the application of existing privacy authenticated users , and the application of existing privacy
skipping to change at page 2, line 19 skipping to change at page 2, line 19
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 . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . 9 9.2 The P-Preferred-Identity Header . . . . . . . . . . . . . . 9
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.3 The "id" Privacy Type . . . . . . . . . . . . . . . . . . . 9
10.1 Network Asserted Identity passed to trusted gateway . . . . 9 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1 Network Asserted Identity passed to trusted gateway . . . . 10
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 . . . . . . . . . . . . . . . . . . . 13 11.1 Protocol requirements . . . . . . . . . . . . . . . . . . . 14
11.2 Authentication requirements . . . . . . . . . . . . . . . . 13 11.2 Authentication requirements . . . . . . . . . . . . . . . . 14
11.3 Security requirements . . . . . . . . . . . . . . . . . . . 13 11.3 Security requirements . . . . . . . . . . . . . . . . . . . 14
11.4 Scope of Trust Domain . . . . . . . . . . . . . . . . . . . 13 11.4 Scope of Trust Domain . . . . . . . . . . . . . . . . . . . 14
11.5 Implicit handling when no Privacy header is present . . . . 13 11.5 Implicit handling when no Privacy header is present . . . . 14
12. Security Considerations . . . . . . . . . . . . . . . . . . 14 12. Security Considerations . . . . . . . . . . . . . . . . . . 14
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15
13.1 Registration of "P-Asserted-Identity" SIP header field . . . 14 13.1 Registration of new SIP header fields . . . . . . . . . . . 15
13.2 Registration of "id" privacy type for SIP Privacy header . . 14 13.2 Registration of "id" privacy type for SIP Privacy header . . 15
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
Normative References . . . . . . . . . . . . . . . . . . . . 15 Normative References . . . . . . . . . . . . . . . . . . . . 16
Informational References . . . . . . . . . . . . . . . . . . 15 Informational References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17
Full Copyright Statement . . . . . . . . . . . . . . . . . . 17 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
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
its users and end-systems to publicly assert the identity of each its users and end-systems to publicly assert the identity of each
skipping to change at page 6, line 40 skipping to change at page 6, line 40
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
If an P-Asserted-Identity header is already present in the message If a P-Preferred-Identity header field is present in the message that
that a proxy receives from an entity that it does not trust, the a proxy receives from an entity that it does not trust, the proxy MAY
proxy MAY use this information as a hint suggesting which of multiple use this information as a hint suggesting which of multiple valid
valid identities for the authenticated user should be asserted. If identities for the authenticated user should be asserted. If such a
such a hint does not correspond to any valid identity known to the hint does not correspond to any valid identity known to the proxy for
proxy for that user, the proxy MUST not forward the user-provided P- that user, the proxy can add a P-Asserted-Identity header of its own
Asserted-Identity header. In this case, the proxy can add an P- construction, or it can reject the request (for example, with a 403
Asserted-Identity header of its own construction, or it can reject Forbidden). The proxy MUST remove the user-provided P-Preferred-
the request (for example, with a 403 Forbidden). Identity header from any message it forwards.
A user agent only sends a hint to proxy server in a Trust Domain; A user agent only sends a P-Preferred-Identity header field to proxy
user agents MUST NOT populate the P-Asserted-Identity header in a servers in a Trust Domain; user agents MUST NOT populate the P-
message that is not sent directly to a proxy that is trusted by the Preferred-Identity header field in a message that is not sent
user agent. Were a user agent to send a message containing a P- directly to a proxy that is trusted by the user agent. Were a user
Asserted-Identity header to a node outside a Trust Domain, then the agent to send a message containing a P-Preferred-Identity header
hinted identity might not be managed appropriately by the network, field to a node outside a Trust Domain, then the hinted identity
which could have negative ramifications for privacy. might not be managed appropriately by the network, 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. The may add the "id" privacy token to the Privacy header field. The
Privacy header field is defined in [6]. If this token is present, Privacy header field is defined in [6]. If this token is present,
proxies MUST remove all the P-Asserted-Identity header fields before proxies MUST remove all the P-Asserted-Identity header fields before
forwarding messages to elements that are not trusted. If the Privacy forwarding messages to elements that are not trusted. If the Privacy
header field value is set to "none" then the proxy MUST NOT remove header field value is set to "none" then the proxy MUST NOT remove
skipping to change at page 7, line 37 skipping to change at page 7, line 38
to fail. 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.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 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 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
skipping to change at page 8, line 34 skipping to change at page 8, line 35
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 *(COMMA PAssertedID-value) PAssertedID = "P-Asserted-Identity" HCOLON PAssertedID-value
*(COMMA PAssertedID-value)
PAssertedID-value = name-addr / addr-spec 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 one or two P-Asserted-Identity 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. 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 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 other MUST be a tel URI. It is worth noting that proxies can (and
will) add and remove this header field. 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 P-Preferred-Identity Header
The P-Preferred-Identity header field is used from an 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.
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 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 with which the user authenticated. Note outside the Trust Domain with which the user authenticated. Note
that a user requesting multiple types of privacy MUST include all of that a user requesting multiple types of privacy MUST include all of
the requested privacy types in its Privacy header field value. the requested privacy types in its Privacy header field value.
priv-value = "id" priv-value = "id"
skipping to change at page 11, line 13 skipping to change at page 11, line 43
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
In this example, the User Agent sends an INVITE to the first proxy, 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 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
CSeq: 1 INVITE CSeq: 1 INVITE
Max-Forwards: 70 Max-Forwards: 70
Privacy: id Privacy: id
P-Preferred-Identity: "Cullen Jennings" <sip:fluffy@cisco.com>
* 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;branch=z9hG4bK-a111 Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a111
To: <sip:bob@biloxi.com>;tag=123456 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;branch=z9hG4bK-a123 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
P-Preferred-Identity: "Cullen Jennings" <sip:fluffy@cisco.com>
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;branch=z9hG4bK-a123 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 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
skipping to change at page 14, line 27 skipping to change at page 15, line 15
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 "P-Asserted-Identity" SIP header field 13.1 Registration of new SIP header fields
This document defines a new private SIP header field, "P-Asserted- This document defines two new private SIP header fields, "P-Asserted-
Identity". As recommended by the policy of the Transport Area, this Identity" and "P-Preferred-Identity". As recommended by the policy
header should be registered by the IANA in the SIP header registry, of the Transport Area, these headers should be registered by the IANA
using the RFC number of this document as its reference. in the SIP header registry, using the RFC number of this 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
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 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.2 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.
Normative References Normative References
 End of changes. 

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