draft-ietf-stir-rfc4474bis-12.txt   draft-ietf-stir-rfc4474bis-13.txt 
Network Working Group J. Peterson Network Working Group J. Peterson
Internet-Draft NeuStar Internet-Draft NeuStar
Intended status: Standards Track C. Jennings Obsoletes: 4474 (if approved) C. Jennings
Expires: March 13, 2017 Cisco Intended status: Standards Track Cisco
E. Rescorla Expires: April 2, 2017 E. Rescorla
RTFM, Inc. RTFM, Inc.
C. Wendt C. Wendt
Comcast Comcast
September 9, 2016 September 29, 2016
Authenticated Identity Management in the Session Initiation Protocol Authenticated Identity Management in the Session Initiation Protocol
(SIP) (SIP)
draft-ietf-stir-rfc4474bis-12.txt draft-ietf-stir-rfc4474bis-13.txt
Abstract Abstract
The baseline security mechanisms in the Session Initiation Protocol The baseline security mechanisms in the Session Initiation Protocol
(SIP) are inadequate for cryptographically assuring the identity of (SIP) are inadequate for cryptographically assuring the identity of
the end users that originate SIP requests, especially in an the end users that originate SIP requests, especially in an
interdomain context. This document defines a mechanism for securely interdomain context. This document defines a mechanism for securely
identifying originators of SIP requests. It does so by defining a identifying originators of SIP requests. It does so by defining a
SIP header field for conveying a signature used for validating the SIP header field for conveying a signature used for validating the
identity, and for conveying a reference to the credentials of the identity, and for conveying a reference to the credentials of the
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on March 13, 2017. This Internet-Draft will expire on April 2, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 22 skipping to change at page 2, line 22
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Architectural Overview . . . . . . . . . . . . . . . . . . . 4 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 4
4. Identity Header Field Syntax . . . . . . . . . . . . . . . . 6 4. Identity Header Field Syntax . . . . . . . . . . . . . . . . 6
4.1. PASSporT Construction . . . . . . . . . . . . . . . . . . 7 4.1. PASSporT Construction . . . . . . . . . . . . . . . . . . 7
4.1.1. 'canon' and PASSporT . . . . . . . . . . . . . . . . 9 4.1.1. Example Full and Compact Forms of PASSporT in
5. Example of Operations . . . . . . . . . . . . . . . . . . . . 10 Identity . . . . . . . . . . . . . . . . . . . . . . 9
5. Example of Operations . . . . . . . . . . . . . . . . . . . . 9
5.1. Example Identity Header Construction . . . . . . . . . . 11 5.1. Example Identity Header Construction . . . . . . . . . . 11
6. Signature Generation and Validation . . . . . . . . . . . . . 13 6. Signature Generation and Validation . . . . . . . . . . . . . 12
6.1. Authentication Service Behavior . . . . . . . . . . . . . 13 6.1. Authentication Service Behavior . . . . . . . . . . . . . 12
6.2. Verifier Behavior . . . . . . . . . . . . . . . . . . . . 16 6.1.1. Handling Repairable Errors . . . . . . . . . . . . . 15
6.2. Verifier Behavior . . . . . . . . . . . . . . . . . . . . 15
6.2.1. Authorization of Requests . . . . . . . . . . . . . . 17 6.2.1. Authorization of Requests . . . . . . . . . . . . . . 17
6.2.2. Response Codes Sent by a Verification Service . . . . 18 6.2.2. Failure Response Codes Sent by a Verification Service 18
6.2.3. Handling 'canon' parameters . . . . . . . . . . . . . 19 6.2.3. Handling the full form of PASSporT . . . . . . . . . 19
7. Credentials . . . . . . . . . . . . . . . . . . . . . . . . . 20 7. Credentials . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Credential Use by the Authentication Service . . . . . . 20 7.1. Credential Use by the Authentication Service . . . . . . 20
7.2. Credential Use by the Verification Service . . . . . . . 21 7.2. Credential Use by the Verification Service . . . . . . . 21
7.3. 'info' parameter URIs . . . . . . . . . . . . . . . . . . 22 7.3. 'info' parameter URIs . . . . . . . . . . . . . . . . . . 22
7.4. Credential System Requirements . . . . . . . . . . . . . 22 7.4. Credential System Requirements . . . . . . . . . . . . . 22
8. Identity Types . . . . . . . . . . . . . . . . . . . . . . . 24 8. Identity Types . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Differentiating Telephone Numbers from URIs . . . . . . . 24 8.1. Differentiating Telephone Numbers from URIs . . . . . . . 24
8.2. Authority for Telephone Numbers . . . . . . . . . . . . . 25 8.2. Authority for Telephone Numbers . . . . . . . . . . . . . 25
8.3. Telephone Number Canonicalization Procedures . . . . . . 25 8.3. Telephone Number Canonicalization Procedures . . . . . . 25
8.4. Authority for Domain Names . . . . . . . . . . . . . . . 26 8.4. Authority for Domain Names . . . . . . . . . . . . . . . 26
8.5. URI Normalization . . . . . . . . . . . . . . . . . . . . 27 8.5. URI Normalization . . . . . . . . . . . . . . . . . . . . 27
9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 28 9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 28
10. Backwards Compatibililty with RFC4474 . . . . . . . . . . . . 29 10. Backwards Compatibility with RFC4474 . . . . . . . . . . . . 29
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 29 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 29
12. Security Considerations . . . . . . . . . . . . . . . . . . . 31 12. Security Considerations . . . . . . . . . . . . . . . . . . . 31
12.1. Protected Request Fields . . . . . . . . . . . . . . . . 32 12.1. Protected Request Fields . . . . . . . . . . . . . . . . 31
12.1.1. Protection of the To Header and Retargeting . . . . 33 12.1.1. Protection of the To Header and Retargeting . . . . 33
12.2. Unprotected Request Fields . . . . . . . . . . . . . . . 34 12.2. Unprotected Request Fields . . . . . . . . . . . . . . . 34
12.3. Malicious Removal of Identity Headers . . . . . . . . . 35 12.3. Malicious Removal of Identity Headers . . . . . . . . . 34
12.4. Securing the Connection to the Authentication Service . 35 12.4. Securing the Connection to the Authentication Service . 35
12.5. Authorization and Transitional Strategies . . . . . . . 36 12.5. Authorization and Transitional Strategies . . . . . . . 36
12.6. Display-Names and Identity . . . . . . . . . . . . . . . 37 12.6. Display-Names and Identity . . . . . . . . . . . . . . . 37
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
13.1. SIP Header Fields . . . . . . . . . . . . . . . . . . . 38 13.1. SIP Header Fields . . . . . . . . . . . . . . . . . . . 37
13.2. SIP Response Codes . . . . . . . . . . . . . . . . . . . 38 13.2. SIP Response Codes . . . . . . . . . . . . . . . . . . . 37
13.3. Identity-Info Parameters . . . . . . . . . . . . . . . . 38 13.3. Identity-Info Parameters . . . . . . . . . . . . . . . . 38
13.4. Identity-Info Algorithm Parameter Values . . . . . . . . 38 13.4. Identity-Info Algorithm Parameter Values . . . . . . . . 38
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38
15. Changes from RFC4474 . . . . . . . . . . . . . . . . . . . . 38 15. Changes from RFC4474 . . . . . . . . . . . . . . . . . . . . 38
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
16.1. Normative References . . . . . . . . . . . . . . . . . . 39 16.1. Normative References . . . . . . . . . . . . . . . . . . 39
16.2. Informative References . . . . . . . . . . . . . . . . . 40 16.2. Informative References . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
skipping to change at page 4, line 16 skipping to change at page 4, line 16
means of signing portions of SIP requests in order to provide an means of signing portions of SIP requests in order to provide an
identity assurance. However, RFC4474 was in several ways misaligned identity assurance. However, RFC4474 was in several ways misaligned
with deployment realities (see [I-D.rosenberg-sip-rfc4474-concerns]). with deployment realities (see [I-D.rosenberg-sip-rfc4474-concerns]).
Most significantly, RFC4474 did not deal well with telephone numbers Most significantly, RFC4474 did not deal well with telephone numbers
as identifiers, despite their enduring use in SIP deployments. as identifiers, despite their enduring use in SIP deployments.
RFC4474 also provided a signature over material that intermediaries RFC4474 also provided a signature over material that intermediaries
in existing deployments commonly altered. This specification in existing deployments commonly altered. This specification
therefore deprecates the RFC4474 syntax and behavior, reconsidering therefore deprecates the RFC4474 syntax and behavior, reconsidering
the problem space in light of the threat model in [RFC7375] and the problem space in light of the threat model in [RFC7375] and
aligning the signature format with PASSporT [I-D.ietf-stir-passport]. aligning the signature format with PASSporT [I-D.ietf-stir-passport].
Backwards compatibility considerations are given in Section 10.
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in RFC 2119 [RFC2119]. described in RFC 2119 [RFC2119].
In addition, this document uses three terms specific to the In addition, this document uses three terms specific to the
mechanism: mechanism:
Identity: An identifier for the user of a communications service; Identity: An identifier for the user of a communications service;
for the purposes of SIP, either a SIP URI or a telephone number. for the purposes of SIP, either a SIP URI or a telephone number.
Identities are derived from an "identity field" a SIP request such Identities are derived from an "identity field" in a SIP request
as the From header field. such as the From header field.
Authentication Service: A logical role played by a SIP entity that Authentication Service: A logical role played by a SIP entity that
adds Identity headers to SIP requests. adds Identity headers to SIP requests.
Verification Service (or "Verifier"): A logical role played by a Verification Service (or "Verifier"): A logical role played by a
SIP entity that validates Identity headers in a SIP request. SIP entity that validates Identity headers in a SIP request.
3. Architectural Overview 3. Architectural Overview
The identity architecture for SIP defined in this specification The identity architecture for SIP defined in this specification
skipping to change at page 5, line 50 skipping to change at page 5, line 51
the domain owner's credentials, or the user agent must possess the domain owner's credentials, or the user agent must possess
credentials that prove in some fashion that the domain owner has credentials that prove in some fashion that the domain owner has
given the user agent the right to a name. given the user agent the right to a name.
In order to share a cryptographic assurance of end-user SIP identity In order to share a cryptographic assurance of end-user SIP identity
in an interdomain or intradomain context, an authentication service in an interdomain or intradomain context, an authentication service
constructs tokens based on the PASSporT [I-D.ietf-stir-passport] constructs tokens based on the PASSporT [I-D.ietf-stir-passport]
format, a JSON [RFC7159] object comprising values derived from format, a JSON [RFC7159] object comprising values derived from
certain header field values in the SIP request. The authentication certain header field values in the SIP request. The authentication
service computes a signature over those JSON elements as PASSporT service computes a signature over those JSON elements as PASSporT
specifies. That signature is then placed in the SIP Identity header specifies. An encoding of the resulting PASSporT is then placed in
field. In order to assist in the validation of the Identity header the SIP Identity header field. In order to assist in the validation
field, this specification also describes a parameter of the Identity of the Identity header field, this specification also describes a
header field that can be used by the recipient of a request to parameter of the Identity header field that can be used by the
recover the credentials of the signer. recipient of a request to recover the credentials of the signer.
Note that the scope of this document is limited to providing an Note that the scope of this document is limited to providing an
identity assurance for SIP requests; solving this problem for SIP identity assurance for SIP requests; solving this problem for SIP
responses is outside the scope of this work (see [RFC4916]). Future responses is outside the scope of this work (see [RFC4916]). Future
work might specify ways that a SIP implementation could gateway work might specify ways that a SIP implementation could gateway
PASSporT objects to other protocols. PASSporTs to other protocols.
4. Identity Header Field Syntax 4. Identity Header Field Syntax
The Identity and Identity-Info header fields that were previously The Identity and Identity-Info header fields that were previously
defined in RFC4474 are here deprecated. This revised specification defined in RFC4474 are here deprecated. This revised specification
collapses the grammar of Identity-Info into the Identity header field collapses the grammar of Identity-Info into the Identity header field
via the "info" parameter. Note that unlike the prior specification via the "info" parameter. Note that unlike the prior specification
in RFC4474, the Identity header field is now allowed to appear more in RFC4474, the Identity header field is now allowed to appear more
than one time in a SIP request. The revised grammar for the Identity than one time in a SIP request. The revised grammar for the Identity
header field builds on the ABNF [RFC5234] in RFC 3261 [RFC3261] header field builds on the ABNF [RFC5234] in RFC 3261 [RFC3261]
Section 25. It is as follows: Section 25. It is as follows:
Identity = "Identity" HCOLON signed-identity-digest SEMI \ Identity = "Identity" HCOLON signed-identity-digest SEMI
ident-info *( SEMI ident-info-params ) ident-info *( SEMI ident-info-params )
signed-identity-digest = LDQUOT *base64-char RDQUOT signed-identity-digest = *base64-char
ident-info = "info" EQUAL ident-info-uri ident-info = "info" EQUAL ident-info-uri
ident-info-uri = LAQUOT absoluteURI RAQUOT ident-info-uri = LAQUOT absoluteURI RAQUOT
ident-info-params = ident-info-alg / ident-type / \ ident-info-params = ident-info-alg / ident-type /
canonical-str / ident-info-extension ident-info-extension
ident-info-alg = "alg" EQUAL token ident-info-alg = "alg" EQUAL token
ident-type = "ppt" EQUAL token ident-type = "ppt" EQUAL token
canonical-str = "canon" EQUAL LDQUOT *base64-char RDQUOT
ident-info-extension = generic-param ident-info-extension = generic-param
base64-char = ALPHA / DIGIT / "/" / "+" base64-char = ALPHA / DIGIT / "/" / "+"
In addition to the "info" parameter, and the "alg" parameter In addition to the "info" parameter, and the "alg" parameter
previously defined in RFC4474, this specification defines the previously defined in RFC4474, this specification defines the
optional "canon" and "ppt" parameters. The 'absoluteURI' portion of optional "ppt" parameter. The 'absoluteURI' portion of ident-info-
ident-info-uri MUST contain a URI; see Section 7.3 for more on uri MUST contain a URI; see Section 7.3 for more on choosing how to
choosing how to advertise credentials through this parameter. advertise credentials through this parameter.
The signed-identity-digest is the PASSporT signature component of a The signed-identity-digest contains a base64 encoding of a PASSporT
PASSporT object [I-D.ietf-stir-passport], a signature which PASSporT [I-D.ietf-stir-passport], which secures the request with a signature
generates over the JSON header and payload objects; some header and that PASSporT generates over the JSON header and payload objects;
claim element values will mirror values of the SIP request. In order some of those header and claim element values will mirror values of
to generate that signature, an implementation must construct a the SIP request.
complete PASSporT object.
4.1. PASSporT Construction 4.1. PASSporT Construction
For SIP implementations to populate the PASSporT header JSON object For SIP implementations to populate the PASSporT header JSON object
with fields from a SIP request, the following elements message MUST with fields from a SIP request, the following elements MUST be placed
be placed as the values corresponding to the designated JSON keys: as the values corresponding to the designated JSON keys:
First, per baseline [I-D.ietf-stir-passport], the JSON key "typ" First, per baseline [I-D.ietf-stir-passport], the JSON "typ" key
key MUST have the value "passport". MUST have the value "passport".
Second, the JSON key "alg" MUST mirror the value of the optional Second, the JSON key "alg" MUST mirror the value of the optional
"alg" parameter in the SIP Identity header field. Note if the "alg" parameter in the SIP Identity header field. Note if the
"alg" parameter is absent from the Identity header, the default "alg" parameter is absent from the Identity header, the default
value is "ES256". value is "ES256".
Third, the JSON key "x5u" MUST have a value equivalent to the Third, the JSON key "x5u" MUST have a value equivalent to the
quoted URI in the "info" parameter. quoted URI in the "info" parameter, per the simple string
comparison rules of [RFC3986] section 6.2.1.
Fourth, if a PASSporT extension is in use, then the optional JSON Fourth, if a PASSporT extension is in use, then the optional JSON
key "ppt" MUST be present and have a value equivalent to the key "ppt" MUST be present and have a value equivalent to the
quoted value of the "ppt" parameter of the Identity header field. quoted value of the "ppt" parameter of the Identity header field.
An example of the PASSporT header JSON object without any extension An example of the PASSporT header JSON object without any extension
is: is:
{ "typ":"passport", { "typ":"passport",
"alg":"ES256", "alg":"ES256",
skipping to change at page 7, line 43 skipping to change at page 7, line 44
To populate the PASSporT payload JSON object from a SIP request, the To populate the PASSporT payload JSON object from a SIP request, the
following elements MUST be placed as values corresponding to the following elements MUST be placed as values corresponding to the
designated JSON keys: designated JSON keys:
First, the JSON "orig" array MUST be populated. If the First, the JSON "orig" array MUST be populated. If the
originating identity is a telephone number, then the array MUST be originating identity is a telephone number, then the array MUST be
populated with a "tn" claim with a value set to the value of the populated with a "tn" claim with a value set to the value of the
quoted originating identity, a canonicalized telephone number (see quoted originating identity, a canonicalized telephone number (see
Section 8.3). Otherwise, the array MUST be populated with a "uri" Section 8.3). Otherwise, the array MUST be populated with a "uri"
claim, set to the value of the AoR of the UA sending the message claim, set to the value of the AoR of the UA sending the message
as taken from addr-spec of the From header field, per the as taken from the addr-spec of the From header field, per the
procedures in Section 8.5. procedures in Section 8.5.
Second, the JSON "dest" array MUST be populated. If the Second, the JSON "dest" array MUST be populated. If the
destination identity is a telephone number, then the array MUST be destination identity is a telephone number, then the array MUST be
populated with a "tn" claim with a value set to the value of the populated with a "tn" claim with a value set to the value of the
quoted destination identity, a canonicalized telephone number (see quoted destination identity, a canonicalized telephone number (see
Section 8.3). Otherwise, the array MUST be populated with a "uri" Section 8.3). Otherwise, the array MUST be populated with a "uri"
claim, set to the value of the addr-spec component of the To claim, set to the value of the addr-spec component of the To
header field, which is the AoR to which the request is being sent, header field, which is the AoR to which the request is being sent,
per the procedures in Section 8.5. per the procedures in Section 8.5.
Third, the JSON key "iat" MUST appear, set to the value of a Third, the JSON key "iat" MUST appear. The authentication service
quoted encoding of the value of the SIP Date header field as a SHOULD set the value of "iat" to a quoted encoding of the value of
JSON NumericDate (as UNIX time, per [RFC7519] Section 2). the SIP Date header field as a JSON NumericDate (as UNIX time, per
[RFC7519] Section 2), though an authentication service MAY set the
value of "iat" to its own current clock time. The authentication
service MUST NOT generate a PASSporT for a SIP request if the Date
header is outside of its local policy for freshness (recommended
sixty seconds).
Fourth, if the request contains an SDP message body, and if that Fourth, if the request contains an SDP message body, and if that
SDP contains one or more "a=fingerprint" attributes, then the JSON SDP contains one or more "a=fingerprint" attributes, then the JSON
key "mky" MUST appear with the algorithm(s) and value(s) of the key "mky" MUST appear with the algorithm(s) and value(s) of the
fingerprint attributes (if they differ), following the format fingerprint attributes (if they differ), following the format
given in [I-D.ietf-stir-passport] Section 4.2.2. given in [I-D.ietf-stir-passport] Section 4.2.2.
For example: For example:
{ "orig":{"tn":"12155551212"}, { "orig":{"tn":"12155551212"},
"dest":{"tn":"12155551213"}, "dest":{"tn":"12155551213"},
"iat":"1443208345" } "iat":"1443208345" }
For information on the security properties of these SIP message For information on the security properties of these SIP message
elements, and why their inclusion mitigates replay attacks, see elements, and why their inclusion mitigates replay attacks, see
Section 12. Note that future extensions to the PASSporT object could Section 12. Note that future extensions to PASSporT could introduce
introduce new claims, and that further SIP procedures could be new claims, and that further SIP procedures could be required to
required to extract information from the SIP request to populate the extract information from the SIP request to populate the values of
values of those claims; see Section 9. those claims; see Section 9.
The "orig" and "dest" arrays may contain identifiers of heterogeneous The "orig" and "dest" arrays may contain identifiers of heterogeneous
type; for example, the "orig" array might contain a "tn" claim, while type; for example, the "orig" array might contain a "tn" claim, while
the "dest" contains a "uri" claim. Also note that in some cases, the the "dest" contains a "uri" claim. Also note that in some cases, the
"orig" and "dest" arrays might be populated with more than one value. "dest" array may be populated with more than one value. This could
This could for example occur when multiple "dest" identities are for example occur when multiple "dest" identities are specified in a
specified in a meshed conference. Defining how a SIP implementation meshed conference. Defining how a SIP implementation would align
would provision multiple originating or destination identities is multiple destination identities in PASSporT with such systems is left
left as a subject for future specification. as a subject for future specification.
After these two JSON objects, the header and the paylod, have been After these two JSON objects, the header and the payload, have been
constructed and base64-encoded, they must each be hashed per constructed and base64-encoded, they must each be hashed and signed
[I-D.ietf-stir-passport] Section 5. The signed value of those per [I-D.ietf-stir-passport] Section 5. The header, payload and
concatenated hashes then becomes the signed-identity-string of the signature components comprise a full PASSporT object. The resulting
Identity header field. The hashing and signing algorithm is PASSporT may be carried in SIP in either a full form, which includes
specified by the 'alg' parameter of the Identity header field and the the header and payload as well as the signature, or a compact form
mirrored "alg" parameter of PASSporT. This specification inherits which only carries the signature per [I-D.ietf-stir-passport]
from the PASSporT specification one value for the 'alg' parameter: Section 6. The hashing and signing algorithm is specified by the
'alg' parameter of the Identity header field and the mirrored "alg"
parameter of PASSporT. All implementations of this specification
MUST support the required signing algorithms of PASSporT. At present
there is one mandatory-to-support value for the 'alg' parameter:
'ES256', as defined in [RFC7519], which connotes an ECDSA P-256 'ES256', as defined in [RFC7519], which connotes an ECDSA P-256
digital signature. All implementations of this specification MUST digital signature.
support the required signing algorithms of PASSporT.
The PASSporT signature that serves as the signed-identity-digest for
the SIP Identity header field constitutes only the base64 encoded
signed hash, omitting the leading '.' of JWS.
The complete form of the Identity header field will therefore look
like the following example:
Identity: "sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/Hmty \
NS7Ltrg9dlxkWzoeU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21y \
NDo2ER/Ovgtw0Lu5csIppPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0 \
gfUs=";info=<https://biloxi.example.org/biloxi.cer>;alg=ES256
4.1.1. 'canon' and PASSporT 4.1.1. Example Full and Compact Forms of PASSporT in Identity
As Appendix F of the JWS specification [RFC7515] notes, there are As Appendix F of the JWS specification [RFC7515] notes, there are
cases where "it is useful to integrity-protect content that is not cases where "it is useful to integrity-protect content that is not
itself contained in a JWS." Since the fields that make up the itself contained in a JWS." Since the fields that make up the
majority of the PASSporT header and payload have values replicated in majority of the PASSporT header and payload have values replicated in
the SIP request, the SIP usage of PASSporT may exclude the base64 the SIP request, the SIP usage of PASSporT may exclude the base64
encoded version of the header and payload JSON objects from the encoded version of the header and payload JSON objects from the
Identity header field and instead present a detached signature. Only Identity header field and instead present a detached signature: what
the signature component of the PASSporT is REQUIRED in SIP, as it PASSporT calls its compact form, see [I-D.ietf-stir-passport]
forms the contents of the signed-identity-digest field. Optionally, Section 6.
as a debugging measure or optimization, the base64-encoded
concatenation of the JSON header and payload MAY be included as the
value of a "canon" parameter of the Identity header field. Note
however that the use of some future extensions could require "canon"
(see Section 9).
When the "canon" parameter is present, it MUST contain the base64 When an authentication service constructs an Identity header, the
encoded header and payload of the PASSporT token per contents of the signed-identity-digest field MUST contain either a
[I-D.ietf-stir-passport]; following JWS, the header and payload are full or compact PASSporT. Use of the compact form is RECOMMENDED in
separated by a single '.'. However, no trailing '.' is included in order to reduce message size, but note that extensions often require
the "canon": the string consists solely of the base64 encoded JSON the full form (see Section 9).
header object, followed by a '.', followed by the base64 encoded
payload JSON object, as follows:
Identity: "rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpj \ For example, a full form of PASSporT in an Identity header might look
lk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w"; \ as follows:
info=<https://biloxi.example.org/biloxi.c>;alg=ES256;canon= \
"eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cH \
M6Ly9jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJkZXN0Ijp7 \
InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdCI6IjE0NDM \
yMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0"
Note that the presence of the "canon" parameter adds considerably to Identity: eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1I \
the length of the Identity header field value. joiaHR0cHM6Ly9jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJ \
kZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdC \
I6IjE0NDMyMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0.r \
q3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYs \
ojNCpTzO3QfPOlckGaS6hEck7w;info=<https://biloxi.example.org \
/biloxi.cert>
The compact form of the same PASSporT object would appear in the
Identity header as:
Identity: ..rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qj \
pjlk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w; \
info=<https://biloxi.example.org/biloxi.cert>
5. Example of Operations 5. Example of Operations
This section provides an informative (non-normative) high-level This section provides an informative (non-normative) high-level
example of the operation of the mechanisms described in this example of the operation of the mechanisms described in this
document. document.
Imagine a case where Bob, who has the home proxy of example.com and Imagine a case where Bob, who has the home proxy of example.com and
the address-of-record sip:12155551212@example.com, wants to the address-of-record sip:12155551212@example.com, wants to
communicate with Alice at sip:alice@example.org. They have no prior communicate with Alice at sip:alice@example.org. They have no prior
skipping to change at page 10, line 47 skipping to change at page 10, line 41
. | | | |. . | | . . | | | |. . | | .
. | Bob | +-------+. . | Alice | . . | Bob | +-------+. . | Alice | .
. | UA | . . | UA | . . | UA | . . | UA | .
. | | . . | | . . | | . . | | .
. +-------+ . . +-------+ . . +-------+ . . +-------+ .
. Domain A . . Domain B . . Domain A . . Domain B .
............................ .............................. ............................ ..............................
The proxy authenticates Bob, and validates that he is authorized to The proxy authenticates Bob, and validates that he is authorized to
assert the identity that he populated in the From header field. The assert the identity that he populated in the From header field. The
proxy authentication service then constructs a PASSporT object which proxy authentication service then constructs a PASSporT which
contains a JSON representation of values which mirror certain parts contains a JSON representation of values which mirror certain parts
of the SIP request, including the identity in the From header field of the SIP request, including the identity in the From header field
value. As a part of generating the PASSporT object, the value. As a part of generating the PASSporT, the authentication
authentication service signs a hash of that JSON header and payload service signs a hash of that JSON header and payload with the private
with the private key associated with the appropriate credential for key associated with the appropriate credential for the identity (in
the identity (in this example, a certificate with authority to sign this example, a certificate with authority to sign for numbers in a
for numbers in a range from 12155551000 to 121555519999), and the range from 12155551000 to 121555519999), and the signature is
signature is inserted by the proxy server into the Identity header inserted by the proxy server into the Identity header field value of
field value of the request. Optionally, the JSON header and payload the request as a compact form of PASSporT. Alternatively, the JSON
themselves may also be included in the object, encoded in the "canon" header and payload themselves might also have been included in the
parameter of the Identity header field. object when using the full form of PASSporT.
The proxy authentication service, as the holder of a private key with The proxy authentication service, as the holder of a private key with
authority over Bob's telephone number, is asserting that the authority over Bob's telephone number, is asserting that the
originator of this request has been authenticated and that he is originator of this request has been authenticated and that he is
authorized to claim the identity that appears in the From header authorized to claim the identity that appears in the From header
field. The proxy inserts an "info" parameter into the Identity field. The proxy inserts an "info" parameter into the Identity
header field that tells Alice how to acquire keying material header field that tells Alice how to acquire keying material
necessary to validate its credentials (a public key), in case she necessary to validate its credentials (a public key), in case she
doesn't already have it. doesn't already have it.
skipping to change at page 12, line 45 skipping to change at page 12, line 23
{"dest":{"uri":["sip:alice@example.com"]},"iat":"1443208345", {"dest":{"uri":["sip:alice@example.com"]},"iat":"1443208345",
"orig":{"tn":"12155551212"}} "orig":{"tn":"12155551212"}}
The authentication service would then generate the signature over the The authentication service would then generate the signature over the
object following the procedures in [I-D.ietf-stir-passport] object following the procedures in [I-D.ietf-stir-passport]
Section 5. That signature would look as follows: Section 5. That signature would look as follows:
rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYs \ rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYs \
ojNCpTzO3QfPOlckGaS6hEck7w ojNCpTzO3QfPOlckGaS6hEck7w
An authentication service signing this request would thus generate An authentication service signing this request and using the compact
and add to the request an Identity header field of the following form of PASSporT would thus generate and add to the request an
form: Identity header field of the following form:
Identity: "rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpj \ Identity: ..rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpj \
lk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w"; \ lk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w; \
info=<https://biloxi.example.org/biloxi.c> info=<https://cert.example.org/passport.cer>
6. Signature Generation and Validation 6. Signature Generation and Validation
SIP entities that instantiate the authentication service and SIP entities that instantiate the authentication service and
verification service roles will, respectively, generate and validate verification service roles will, respectively, generate and validate
the Identity header and the signature it contains. the Identity header and the signature it contains.
6.1. Authentication Service Behavior 6.1. Authentication Service Behavior
Any entity that instantiates the authentication service role MUST Any entity that instantiates the authentication service role MUST
skipping to change at page 15, line 16 skipping to change at page 14, line 46
and the current time fall within the validity period of its and the current time fall within the validity period of its
credential. credential.
See Section 12.1 for information on how the Date header field assists See Section 12.1 for information on how the Date header field assists
verifiers. verifiers.
Step 4: Populate and Add the Identity Header Step 4: Populate and Add the Identity Header
Subsequently, the authentication service MUST form a PASSporT object Subsequently, the authentication service MUST form a PASSporT object
and add a corresponding Identity header field to the request and add a corresponding Identity header field to the request
containing this signature. For the baseline PASSporT header (headers containing either the full or compact form of PASSporT. For the
containing no "ppt" parameter), this follows the procedures in baseline PASSporT header (headers containing no "ppt" parameter),
Section 4; if the authentication service is using an alternative this follows the procedures in Section 4; if the authentication
"ppt" format, it MUST add an appropriate "ppt" parameter and follow service is using an alternative "ppt" format, it MUST add an
the procedures associated with that extension (see Section 9). After appropriate "ppt" parameter and follow the procedures associated with
the Identity header field has been added to the request, the that extension (see Section 9). After the Identity header field has
authentication service MUST also add a "info" parameter to the been added to the request, the authentication service MUST also add a
Identity header field. The "info" parameter contains a URI from "info" parameter to the Identity header field. The "info" parameter
which the authentication service's credential can be acquired; see contains a URI from which the authentication service's credential can
Section 7.3 for more on credential acquisition. be acquired; see Section 7.3 for more on credential acquisition.
Step 5: Add "canon", if Needed An authentication service MAY use the full form of the PASSporT in
the Identity header field. The presence of the full form is OPTIONAL
because the information carried in the baseline PASSporT object's
headers and claims is usually redundant with information already
carried elsewhere in the SIP request. Using the compact form can
significantly reduce SIP message size, especially when the PASSporT
object contains media keys. The syntax of the compact form is given
in [I-D.ietf-stir-passport] Section 6; essentially, it contains a
base64 encoding of the JSON header and payload in the PASSporT
object.
An authentication service MAY add a "canon" parameter to the Identity Note that per the behavior specified in [I-D.ietf-stir-passport], use
header field. The presence of "canon" is OPTIONAL because the of the full form is mandatory when optional extensions are included.
information carried in the baseline PASSporT object's headers and See Section 9.
claims is usually redundant with information already carried
elsewhere in the SIP request. Omitting "canon" can significantly
reduce SIP message size, especially when the PASSporT object contains
media keys. The syntax of "canon" is given in Section 4.1.1;
essentially, it contains a base64 encoding of the JSON header and
payload in the PASSporT object.
When however an authentication service creates a PASSporT object that 6.1.1. Handling Repairable Errors
uses extension claims beyond the baseline PASSporT object, including
"canon" is REQUIRED in order for the verification service to be
capable of validating the signature. See Section 9.
Also, in some cases, a request signed by an authentication service Also, in some cases, a request signed by an authentication service
will be rejected by the verification service on the receiving side, will be rejected by the verification service on the receiving side,
and the authentication service will receive a SIP 4xx status code in and the authentication service will receive a SIP 4xx status code in
the backwards direction, such as a 438 indicating a verification the backwards direction, such as a 438 indicating a verification
failure. If the authentication service did not originally send the failure. If the authentication service did not originally send the
Identity header field with the "canon" parameter, it SHOULD retry a full form of the PASSporT object in the Identity header field, it
request once after receiving a 438 response, this time including the SHOULD retry the request with the full form after receiving a 438
"canon". The information in "canon" is useful on the verification response; however implementations SHOULD NOT retry the request more
side for debugging errors, and there are some known causes of than once. The information in the full form is useful on the
verification failures (such as the Date header field value changing verification side for debugging errors, and there are some known
in transit, see Section 12.1 for more information) that can be causes of verification failures (such as the Date header field value
resolved by the inclusion of "canon". changing in transit, see Section 12.1 for more information) that can
be resolved by the inclusion of the full form of PASSporT.
Finally, the authentication service forwards the message normally. Finally, the authentication service forwards the message normally.
6.2. Verifier Behavior 6.2. Verifier Behavior
This document specifies a logical role for SIP entities called a This document specifies a logical role for SIP entities called a
verification service, or verifier. When a verifier receives a SIP verification service, or verifier. When a verifier receives a SIP
message containing one or more Identity header fields, it inspects message containing one or more Identity header fields, it inspects
the signature(s) to verify the identity of the originator of the the signature(s) to verify the identity of the originator of the
message. The results of a verification are provided as input to an message. The results of a verification are provided as input to an
skipping to change at page 16, line 33 skipping to change at page 16, line 15
support an Identity header field "ppt" parameter which is present, or support an Identity header field "ppt" parameter which is present, or
if no Identity header field is present at all, and the presence of an if no Identity header field is present at all, and the presence of an
Identity header field is required by local policy (for example, based Identity header field is required by local policy (for example, based
on a per-sending-domain policy, or a per-sending-user policy), then a on a per-sending-domain policy, or a per-sending-user policy), then a
428 'Use Identity Header' response MUST be sent in the backwards 428 'Use Identity Header' response MUST be sent in the backwards
direction. For more on this and other verifier responses, see direction. For more on this and other verifier responses, see
Section 6.2.2. Section 6.2.2.
In order to verify an Identity header field in a message, an entity In order to verify an Identity header field in a message, an entity
acting as a verifier MUST perform the following steps, in the order acting as a verifier MUST perform the following steps, in the order
here specified. Note that when an Identity header field contains the here specified. Note that when an Identity header field contains a
optional "canon" parameter, the verifier MUST follow the additional full form PASSporT object, the verifier MUST follow the additional
procedures in Section 6.2.3. procedures in Section 6.2.3.
Step 1: Check for an Unsupported "ppt" Step 1: Check for an Unsupported "ppt"
The verifier MUST inspect any optional "ppt" parameter appearing in The verifier MUST inspect any optional "ppt" parameter appearing in
the Identity request. If no "ppt" parameter is present, then the the Identity request. If no "ppt" parameter is present, then the
verifier proceeds normally below. If a "ppt" parameter value is verifier proceeds normally below. If a "ppt" parameter value is
present, and the verifier does not support it, it MUST ignore the present, and the verifier does not support it, it MUST ignore the
Identity header field. If a supported "ppt" parameter value is Identity header field. If a supported "ppt" parameter value is
present, the verifier proceeds with Step 2, and will ultimately present, the verifier proceeds with Step 2, and will ultimately
skipping to change at page 17, line 20 skipping to change at page 17, line 4
The verifier must ensure that it possesses the proper keying material The verifier must ensure that it possesses the proper keying material
to validate the signature in the Identity header field, which usually to validate the signature in the Identity header field, which usually
involves dereferencing a URI in the "info" parameter of the Identity involves dereferencing a URI in the "info" parameter of the Identity
header field. See Section 7.2 for more information on these header field. See Section 7.2 for more information on these
procedures. If the verifier does not support the credential procedures. If the verifier does not support the credential
described in the "info" parameter, then it treats the credential for described in the "info" parameter, then it treats the credential for
this header field as unsupported. this header field as unsupported.
Step 4: Check the Freshness of Date Step 4: Check the Freshness of Date
The verifier furthermore ensures that the value of the Date header The verifier furthermore ensures that the value of the Date header
field of the request meets local policy for freshness (sixty seconds field of the request meets local policy for freshness (sixty seconds
is RECOMMENDED) and that it falls within the validity period of the is RECOMMENDED) and that it falls within the validity period of the
credential used to sign the Identity header field. For more on the credential used to sign the Identity header field. For more on the
attacks this prevents, see Section 12.1. If the "canon" parameter is attacks this prevents, see Section 12.1. If the full form of the
present, the verifier SHOULD compare the "iat" value in the "canon" PASSporT is present, the verifier SHOULD compare the "iat" value in
to the Date header field value in the request. If the two are the PASSporT to the Date header field value in the request. If the
different, and the "iat" value is later but within verification two are different, and the "iat" value is later but within
service policy for freshness, the verification service SHOULD perform verification service policy for freshness, the verification service
the computation required by Step 5 using the "iat" value instead of SHOULD perform the computation required by Step 5 using the "iat"
the Date header field value. value instead of the Date header field value.
Step 5: Validate the Signature Step 5: Validate the Signature
The verifier MUST validate the signature in the Identity header field The verifier MUST validate the signature in the Identity header field
over the PASSporT object. For baseline PASSporT objects (with no over the PASSporT object. For baseline PASSporT objects (with no
Identity header field "ppt" parameter) the verifier MUST follow the Identity header field "ppt" parameter) the verifier MUST follow the
procedures for generating the signature over a PASSporT object procedures for generating the signature over a PASSporT object
described in Section 4. If a "ppt" parameter is present (and per described in Section 4. If a "ppt" parameter is present (and per
Step 1, is supported), the verifier follows the procedures for that Step 1, is supported), the verifier follows the procedures for that
"ppt" (see Section 9). If a verifier determines that the that the "ppt" (see Section 9). If a verifier determines that the that the
skipping to change at page 18, line 19 skipping to change at page 17, line 50
forwarding decisions in intermediary implementations, or changing how forwarding decisions in intermediary implementations, or changing how
the user is alerted, or how identity is rendered, in user agent the user is alerted, or how identity is rendered, in user agent
implementations. implementations.
The presence of multiple Identity header fields within a message The presence of multiple Identity header fields within a message
raises the prospect that a verification services could receive a raises the prospect that a verification services could receive a
message containing some valid and some invalid Identity header message containing some valid and some invalid Identity header
fields. As a guideline, this specification recommends that only if a fields. As a guideline, this specification recommends that only if a
verifier determines all Identity header fields within a message are verifier determines all Identity header fields within a message are
invalid should the request be considered to have an invalid identity. invalid should the request be considered to have an invalid identity.
If at least one Identity header field value is valid and from a
trusted source, then relying parties can use that header for
authorization decisions regardless of whether other untrusted or
invalid Identity headers appear in a request.
6.2.2. Response Codes Sent by a Verification Service 6.2.2. Failure Response Codes Sent by a Verification Service
RFC4474 originally defined four response codes for failure conditions RFC4474 originally defined four response codes for failure conditions
specific to the Identity header field and its original mechanism. specific to the Identity header field and its original mechanism.
These status codes are retained in this specification, with some These status codes are retained in this specification, with some
slight modifications. Also, this specification details responding slight modifications. Also, this specification details responding
with 403 when a stale Date header field value is received. with 403 when a stale Date header field value is received.
A 428 response will be sent (per Section 6.2) when an Identity header A 428 response will be sent (per Section 6.2) when an Identity header
field is required, but no Identity header field without a "ppt" field is required, but no Identity header field without a "ppt"
parameter, or with a supported "ppt" value, has been received. In parameter, or with a supported "ppt" value, has been received. In
skipping to change at page 19, line 17 skipping to change at page 19, line 4
with which the credential was signed. with which the credential was signed.
The 438 'Invalid Identity Header' response indicates that of the set The 438 'Invalid Identity Header' response indicates that of the set
of Identity header fields in a request, no header field with a valid of Identity header fields in a request, no header field with a valid
and supported PASSporT object has been received. Like the 428 and supported PASSporT object has been received. Like the 428
response, this is sent by a verification service when its local response, this is sent by a verification service when its local
policy dictates that a broken signature in an Identity header field policy dictates that a broken signature in an Identity header field
is grounds for rejecting a request. Note that in some cases, an is grounds for rejecting a request. Note that in some cases, an
Identity header field may be broken for other reasons than that an Identity header field may be broken for other reasons than that an
originator is attempting to spoof an identity: for example, when a originator is attempting to spoof an identity: for example, when a
transit network alters the Date header field of the request. Relying transit network alters the Date header field of the request. Sending
on the full PASSporT object presented through the "canon" parameter a full form PASSporT can repair some of these conditions (see
can repair some of these conditions (see Section 6.2.3), so the Section 6.2.3), so the recommended way to attempt to repair this
recommended way to attempt to repair this failure is to retry the failure is to retry the request with the full form of PASSporT if it
request with "canon". had originally been sent with the compact form. The alternative
reason phrase 'Invalid PASSporT' SHOULD be used when an extended full
form PASSporT lacks required headers or claims, or when an extended
full form PASSporT signaled with the "ppt" parameter lacks required
claims for that extension.
Finally, a 403 response with the special reason phase 'Stale Date" Finally, a 403 response with the special reason phrase 'Stale Date"
may be sent when the verification service receives a request with a may be sent when the verification service receives a request with a
Date header field value that is older than the local policy for Date header field value that is older than the local policy for
freshness permits. The same response may be used when the "iat" in freshness permits. The same response may be used when the "iat" in
the "canon" parameter of a request has a value older than the local the full form of a PASSporT has a value older than the local policy
policy for freshness permits. for freshness permits.
6.2.3. Handling 'canon' parameters 6.2.3. Handling the full form of PASSporT
If the optional "canon" parameter of the Identity header field is If the full form of PASSporT is present in an Identity header, this
present, it contains a base64 encoding of the header and claim permits the use of optional extensions as described in
component of the PASSporT object constructed by the authentication [I-D.ietf-stir-passport] Section 7.3. The verification service can
service (as detailed in Section 4.1.1). The verification service can extract from the "orig" element" a canonical telephone number created
thus extract from it the canonical telephone number created by the by the authentication service, as well as an "iat" claim
authentication service, as well as an "iat" claim corresponding to corresponding to the Date header field that the authentication
the Date header field that the authentication service used. These service used. These may be used to debug canonicalization problems,
may be used to debug canonicalization problems, or to avoid or to avoid unnecessary signature breakage caused by intermediaries
unnecessary signature breakage caused by intermediaries that alter that alter the Date header field value in transit.
the Date header field value in transit.
As an optimization, when "canon" is present, the verification service As an optimization, when the full form is present, the verification
MAY compute its own canonicalization of an originating telephone service MAY compute its own canonicalization of an originating
number and compare it to the values in the "canon" parameter before telephone number and compare it to the values in the "orig" element
performing any cryptographic functions in order to ascertain whether of PASSporT before performing any cryptographic functions in order to
or not the two ends agree on the canonical number form. ascertain whether or not the two ends agree on the canonical number
form.
7. Credentials 7. Credentials
This section gives general guidance on the use of credential systems This section gives general guidance on the use of credential systems
by authentication and verification services, as well as requirements by authentication and verification services, as well as requirements
that must be met by credential systems that conform with this that must be met by credential systems that conform with this
architecture. It does not mandate any specific credential system. architecture. It does not mandate any specific credential system.
Furthermore, this specification allows either a user agent or a proxy Furthermore, this specification allows either a user agent or a proxy
server to provide the authentication service function and/or the server to provide the authentication service function and/or the
skipping to change at page 24, line 29 skipping to change at page 24, line 14
header field value instead of the From header field value. In some header field value instead of the From header field value. In some
trusted environments, the P-Asserted-Identity header field is used in trusted environments, the P-Asserted-Identity header field is used in
lieu of the From header field to convey the address-of-record or lieu of the From header field to convey the address-of-record or
telephone number of the originator of a request; where it does, local telephone number of the originator of a request; where it does, local
policy might therefore dictate that the canonical identity derives policy might therefore dictate that the canonical identity derives
from the P-Asserted-Identity header field rather than the From header from the P-Asserted-Identity header field rather than the From header
field. field.
Ultimately, in any case where local policy canonicalizes the identity Ultimately, in any case where local policy canonicalizes the identity
into a form different from how it appears in the From header field, into a form different from how it appears in the From header field,
the use of the "canon" parameter by authentication services is the use of the full form of PASSporT by authentication services is
RECOMMENDED, but because "canon" itself could then divulge RECOMMENDED, but because the "orig" claim of PASSporT could itself
information about users or networks, implementers should be mindful could then divulge information about users or networks, implementers
of the guidelines in Section 11. should be mindful of the guidelines in Section 11.
8.1. Differentiating Telephone Numbers from URIs 8.1. Differentiating Telephone Numbers from URIs
It may not be trivial to tell if a given URI contains a telephone It may not be trivial to tell if a given URI contains a telephone
number. In order to determine whether or not the user portion of a number. In order to determine whether or not the user portion of a
SIP URI is a telephone number, authentication services and SIP URI is a telephone number, authentication services and
verification services MUST perform the following procedure on any SIP verification services MUST perform the following procedure on any SIP
URI they inspect which contains a numeric user part. Note that the URI they inspect which contains a numeric user part. Note that the
same procedures are followed for creating the canonical form of URIs same procedures are followed for creating the canonical form of URIs
found in the From header field as they are in the To header field or found in the From header field as they are in the To header field or
skipping to change at page 25, line 23 skipping to change at page 25, line 11
number, or even a private branch exchange number. Once a telephone number, or even a private branch exchange number. Once a telephone
number has been detected, implementations should follow the number has been detected, implementations should follow the
procedures in Section 8.3. procedures in Section 8.3.
If the URI field does not contain a telephone number, or if the If the URI field does not contain a telephone number, or if the
result of the canonicalization of the From header field value does result of the canonicalization of the From header field value does
not form a valid E.164 telephone number, the authentication service not form a valid E.164 telephone number, the authentication service
and/or verification service SHOULD treat the entire URI as a SIP URI, and/or verification service SHOULD treat the entire URI as a SIP URI,
and apply the procedures in Section 8.5. These URI normalization and apply the procedures in Section 8.5. These URI normalization
procedures are invoked to canonicalize the URI before it is included procedures are invoked to canonicalize the URI before it is included
in a PASSporT object in, for example, an "uri" claim. See in a PASSporT object in, for example, a "uri" claim. See Section 8.5
Section 8.5 for that behavior. for that behavior.
8.2. Authority for Telephone Numbers 8.2. Authority for Telephone Numbers
In order for telephone numbers to be used with the mechanism In order for telephone numbers to be used with the mechanism
described in this document, authentication services must receive described in this document, authentication services must receive
credentials from an authority for telephone numbers or telephone credentials from an authority for telephone numbers or telephone
number ranges, and verification services must trust the authority number ranges, and verification services must trust the authority
employed by the authentication service that signs a request. Per employed by the authentication service that signs a request. Per
Section 7.4, enrollment procedures and credential management are Section 7.4, enrollment procedures and credential management are
outside the scope of this document; approaches to credential outside the scope of this document; approaches to credential
skipping to change at page 26, line 15 skipping to change at page 25, line 49
Next, an implementation must assess if the number string is a Next, an implementation must assess if the number string is a
valid, globally-routable number with a leading country code. If valid, globally-routable number with a leading country code. If
not, implementations SHOULD convert the number into E.164 format, not, implementations SHOULD convert the number into E.164 format,
adding a country code if necessary; this may involve transforming adding a country code if necessary; this may involve transforming
the number from a dial string (see [RFC3966]), removing any the number from a dial string (see [RFC3966]), removing any
national or international dialing prefixes or performing similar national or international dialing prefixes or performing similar
procedures. It is only in the case that an implementation cannot procedures. It is only in the case that an implementation cannot
determine how to convert the number to a globally-routable format determine how to convert the number to a globally-routable format
that this step may be skipped. This will be the case, for that this step may be skipped. This will be the case, for
example, for nationally-specific service numbers (e.g. 911, 112); example, for nationally-specific service numbers (e.g. 911, 112);
however, the routing procedures associated with those numbers will however, calls to those numbers are routed in a very strict
likely make sure that the verification service understands the fashion which ordinarily prevents them from reaching entities that
context of their use. don't understand the numbers.
Other transformations during canonicalization MAY be made in Some domains may need to take unique steps to convert their
accordance with specific policies used within a local domain. For numbers into a global format, and such transformations during
example, one domain may only use local number formatting and need canonicalization can also be made in accordance with specific
to convert all To/From header field user portions to E.164 by policies used within a local domain. For example, one domain may
prepending country-code and region code digits; another domain only use local number formatting and need to convert all To/From
might have prefixed usernames with trunk-routing codes, in which header field user portions to E.164 by prepending country-code and
case the canonicalization will need to remove the prefix. This region code digits; another domain might have prefixed usernames
specification cannot anticipate all of the potential with trunk-routing codes, in which case the canonicalization will
transformations that might be useful. need to remove the prefix. This specification cannot anticipate
all of the potential transformations that might be useful.
The resulting canonical number string will be used as input to the The resulting canonical number string will be used as input to the
hash calculation during signing and verifying processes. hash calculation during signing and verifying processes.
The ABNF of this number string is: The ABNF of this number string is:
tn-spec = [ "#" / "*" ] 1*DIGIT tn-spec = [ "#" / "*" ] 1*DIGIT
The resulting number string is used in the construction of the The resulting number string is used in the construction of the
telephone number field(s) in a PASSporT object. telephone number field(s) in a PASSporT object.
skipping to change at page 28, line 42 skipping to change at page 28, line 31
component. A more exact definition is left to future specifications. component. A more exact definition is left to future specifications.
9. Extensibility 9. Extensibility
As future requirements may warrant increasing the scope of the As future requirements may warrant increasing the scope of the
Identity mechanism, this specification specifies an optional "ppt" Identity mechanism, this specification specifies an optional "ppt"
parameter of the Identity header field, which mirrors the "ppt" parameter of the Identity header field, which mirrors the "ppt"
header in PASSporT. The "ppt" parameter value MUST consist of a header in PASSporT. The "ppt" parameter value MUST consist of a
token containing an extension specification, which denotes an token containing an extension specification, which denotes an
extended set of one or more signed claims per the type extensibility extended set of one or more signed claims per the type extensibility
mechanism specified in [I-D.ietf-stir-passport] Section 6. mechanism specified in [I-D.ietf-stir-passport] Section 7. Note that
per the guidance in that section, "ppt" is used only to enforce a
mandatory extension: optional claims may be added to any PASSporT
object without requiring the use of "ppt", but the compact form of
PASSporT MUST NOT be used when optional claims are present in the
PASSporT payload.
The potential for extensions is one the primary motivations for The potential for extensions is one the primary motivations for
allowing the presence of multiple Identity header fields in the same allowing the presence of multiple Identity header fields in the same
SIP request. It is envisioned that future extensions might allow for SIP request. It is envisioned that future extensions might allow for
alternate information to be signed, or to explicitly allow different alternate information to be signed, or to explicitly allow different
parties to provide the signatures than the authorities envisioned by parties to provide the signatures than the authorities envisioned by
baseline STIR. A request might, for example, have one Identity added baseline STIR. A request might, for example, have one Identity added
by an authentication service at the originating administrative by an authentication service at the originating administrative
domain, and then another Identity header field added by some further domain, and then another Identity header field added by some further
intermediary using a PASSporT extension. While this specification intermediary using a PASSporT extension. While this specification
skipping to change at page 29, line 16 skipping to change at page 29, line 9
header fields, implementations MUST support receiving multiple header header fields, implementations MUST support receiving multiple header
fields for future compatibility reasons. fields for future compatibility reasons.
An authentication service cannot assume that verifiers will An authentication service cannot assume that verifiers will
understand any given extension. Verifiers that do support an understand any given extension. Verifiers that do support an
extension may then trigger appropriate application-level behavior in extension may then trigger appropriate application-level behavior in
the presence of an extension; authors of extensions should provide the presence of an extension; authors of extensions should provide
appropriate extension-specific guidance to application developers on appropriate extension-specific guidance to application developers on
this point. this point.
If any claim in an extension contains a JSON value that does not 10. Backwards Compatibility with RFC4474
correspond to a field of the SIP request, and the extension does not
otherwise explain how a verification service could derive or acquire
that value, then the optional "canon" parameter MUST be used for the
Identity header field containing that extension.
10. Backwards Compatibililty with RFC4474
This specification introduces several significant changes from the This specification introduces several significant changes from the
RFC4474 version of the Identity header field. However, due to the RFC4474 version of the Identity header field. However, due to the
problems enumerated in [I-D.rosenberg-sip-rfc4474-concerns], it is problems enumerated in [I-D.rosenberg-sip-rfc4474-concerns], it is
not believed that the original Identity header field has seen any not believed that the original Identity header field has seen any
deployment, or even implementation in deployed products. deployment, or even implementation in deployed products.
As such, this mechanism contains no provisions for signatures As such, this mechanism contains no provisions for signatures
generated with this specification to work with RFC4474-compliant generated with this specification to work with RFC4474-compliant
implementations, nor any related backwards-compatibility provisions. implementations, nor any related backwards-compatibility provisions.
Hypothetically, were an RFC4474-compliant implementation to receive Hypothetically, were an RFC4474-compliant implementation to receive
messages containing this revised version of the Identity header messages containing this revised version of the Identity header
field, it would likely fail the request due to the absence of an field, it would likely fail the request with a 436 response code due
Identity-Info header field with a 436 response code. Implementations to the absence of an Identity-Info header field. Implementations of
of this specification, for debugging purposes, might interpret a 436 this specification, for debugging purposes, might interpret a 436
with a reason phrase of "Bad Identity-Info" as an indication that the with a reason phrase of "Bad Identity-Info" as an indication that the
request has failed because it reached a (hypothetical) request has failed because it reached a (hypothetical)
RFC4474-compliant verification service. RFC4474-compliant verification service.
11. Privacy Considerations 11. Privacy Considerations
The purpose of this mechanism is to provide a reliable identification The purpose of this mechanism is to provide a reliable identification
of the originator of a SIP request, specifically a cryptographic of the originator of a SIP request, specifically a cryptographic
assurance that an authority asserts the originator can claim the URI assurance that an authority asserts the originator can claim the URI
the identity stipulated in the request. This URI may contain or the identity stipulated in the request. This URI may contain or
skipping to change at page 31, line 12 skipping to change at page 30, line 47
beyond what appears in the From header field; P-Asserted-Identity beyond what appears in the From header field; P-Asserted-Identity
holds a definitive identity for the originator that is somehow known holds a definitive identity for the originator that is somehow known
to a closed network of intermediaries. Presumably, that network will to a closed network of intermediaries. Presumably, that network will
use this identity for billing or security purposes. The danger of use this identity for billing or security purposes. The danger of
this network-specific information leaking outside of the closed this network-specific information leaking outside of the closed
network motivated the "id" priv-value token. The "id" priv-value network motivated the "id" priv-value token. The "id" priv-value
token has no implications for the Identity header field, and privacy token has no implications for the Identity header field, and privacy
services MUST NOT remove the Identity header field when a priv-value services MUST NOT remove the Identity header field when a priv-value
of "id" appears in a Privacy header field. of "id" appears in a Privacy header field.
The optional "canon" parameter of the Identity header field specified The full form of the PASSporT object provides the complete JSON
in this document provides the complete JSON objects used to generate objects used to generate the signed-identity-digest of the Identity
the signed-identity-digest of the Identity header field value, header field value, including the canonicalized form of the telephone
including the canonicalized form of the telephone number of the number of the originator of a call, if the signature is over a
originator of a call, if the signature is over a telephone number. telephone number. In some contexts, local policy may require a
In some contexts, local policy may require a canonicalization which canonicalization which differs substantially from the original From
differs substantially from the original From header field. Depending header field. Depending on those policies, potentially the full form
on those policies, potentially the "canon" parameter might divulge of PASSporT might divulge information about the originating network
information about the originating network or user that might not or user that might not appear elsewhere in the SIP request. Were it
appear elsewhere in the SIP request. Were it to be used to reflect to be used to reflect the contents of the P-Asserted-Identity header
the contents of the P-Asserted-Identity header field, for example, field, for example, then the object would need to be converted to the
then "canon" would need to be removed when the P-Asserted-Identity compact form when the P-Asserted-Identity header is removed to avoid
header is removed to avoid any such leakage outside of a trust any such leakage outside of a trust domain. Since, in those
domain. Since, in those contexts, the canonical form of the contexts, the canonical form of the originator's identity could not
originator's identity could not be reassembled by a verifier, and be reassembled by a verifier, and thus the Identity signature
thus the Identity signature validation process would fail, using P- validation process would fail, using P-Asserted-Identity with the
Asserted-Identity with the Identity "canon" parameter in this fashion full form of PASSporT in this fashion is NOT RECOMMENDED outside of
is NOT RECOMMENDED outside of environments where SIP requests will environments where SIP requests will never leave the trust domain.
never leave the trust domain. As a side note, history shows that As a side note, history shows that closed networks never stay closed
closed networks never stay closed and one should design their and one should design their implementation assuming connectivity to
implementation assuming connectivity to the broader Internet. the broader Internet.
Finally, note that unlike [RFC3325], the mechanism described in this Finally, note that unlike [RFC3325], the mechanism described in this
specification adds no information to SIP requests that has privacy specification adds no information to SIP requests that has privacy
implications - apart from disclosing that an authentication service implications - apart from disclosing that an authentication service
is willing to sign for an originator. is willing to sign for an originator.
12. Security Considerations 12. Security Considerations
This document describes a mechanism that provides a signature over This document describes a mechanism that provides a signature over
the Date header field of SIP requests, parts of the To and From the Date header field of SIP requests, parts of the To and From
skipping to change at page 32, line 38 skipping to change at page 32, line 24
received requests, and thus if an Identity header field is replayed received requests, and thus if an Identity header field is replayed
by an attacker within the Date interval, verifiers can detect that it by an attacker within the Date interval, verifiers can detect that it
is spoofed because a message with an identical Date from the same is spoofed because a message with an identical Date from the same
source had recently been received. source had recently been received.
It has been observed in the wild that some networks change the Date It has been observed in the wild that some networks change the Date
header field value of SIP requests in transit, and that alternative header field value of SIP requests in transit, and that alternative
behavior might be necessary to accommodate that use case. behavior might be necessary to accommodate that use case.
Verification services that observe a signature validation failure MAY Verification services that observe a signature validation failure MAY
therefore reconstruct the Date header field component of the therefore reconstruct the Date header field component of the
signature from the "iat" carried in PASSporT via the "canon" signature from the "iat" carried in the full form of PASSporT:
parameter: provided that time recorded by "iat" falls within the provided that time recorded by "iat" falls within the local policy
local policy for freshness that would ordinarily apply to the Date for freshness that would ordinarily apply to the Date header, the
header, the verification service MAY treat the signature as valid, verification service MAY treat the signature as valid, provided it
provided it keeps adequate state to detect recent replays. Note that keeps adequate state to detect recent replays. Note that this will
this will require the inclusion of the "canon" parameter by require the inclusion of the full form of the PASSporT object by
authentication services in networks where such failures are observed. authentication services in networks where such failures are observed.
The To header field value provides the identity of the SIP user that The To header field value provides the identity of the SIP user that
this request originally targeted. Covering the identity in the To this request originally targeted. Covering the identity in the To
header field with the Identity signature serves two purposes. First, header field with the Identity signature serves two purposes. First,
it prevents cut-and-paste attacks in which an Identity header field it prevents cut-and-paste attacks in which an Identity header field
from a legitimate request for one user is cut-and-pasted into a from a legitimate request for one user is cut-and-pasted into a
request for a different user. Second, it preserves the starting URI request for a different user. Second, it preserves the starting URI
scheme of the request, which helps prevent downgrade attacks against scheme of the request, which helps prevent downgrade attacks against
the use of SIPS. The To identity offers additional protection the use of SIPS. The To identity offers additional protection
skipping to change at page 36, line 5 skipping to change at page 35, line 38
Without TLS, the various header field values and the body of the Without TLS, the various header field values and the body of the
request will not have integrity protection when the request request will not have integrity protection when the request
arrives at an authentication service. Accordingly, a prior arrives at an authentication service. Accordingly, a prior
legitimate or illegitimate intermediary could modify the message legitimate or illegitimate intermediary could modify the message
arbitrarily. arbitrarily.
Of these two concerns, the first is most material to the intended Of these two concerns, the first is most material to the intended
scope of this mechanism. This mechanism is intended to prevent scope of this mechanism. This mechanism is intended to prevent
impersonation attacks, not man-in-the-middle attacks; integrity over impersonation attacks, not man-in-the-middle attacks; integrity over
parts of the the header and body is provided by this mechanism only parts of the header and body is provided by this mechanism only to
to prevent replay attacks. However, it is possible that applications prevent replay attacks. However, it is possible that applications
relying on the presence of the Identity header field could leverage relying on the presence of the Identity header field could leverage
this integrity protection for services other than replay protection. this integrity protection for services other than replay protection.
Accordingly, direct TLS connections SHOULD be used between the UAC Accordingly, direct TLS connections SHOULD be used between the UAC
and the authentication service whenever possible. The opportunistic and the authentication service whenever possible. The opportunistic
nature of this mechanism, however, makes it very difficult to nature of this mechanism, however, makes it very difficult to
constrain UAC behavior, and moreover there will be some deployment constrain UAC behavior, and moreover there will be some deployment
architectures where a direct connection is simply infeasible and the architectures where a direct connection is simply infeasible and the
UAC cannot act as an authentication service itself. Accordingly, UAC cannot act as an authentication service itself. Accordingly,
when a direct connection and TLS are not possible, a UAC should use when a direct connection and TLS are not possible, a UAC should use
skipping to change at page 38, line 25 skipping to change at page 38, line 11
The 437 "Unsupported Certificate" default reason phrase should be The 437 "Unsupported Certificate" default reason phrase should be
changed to "Unsupported Credential". changed to "Unsupported Credential".
13.3. Identity-Info Parameters 13.3. Identity-Info Parameters
The IANA manages a registry for Identity-Info parameters. The The IANA manages a registry for Identity-Info parameters. The
specification asks the IANA to change the name of this registry to specification asks the IANA to change the name of this registry to
"Identity Parameters". "Identity Parameters".
This specification defines two new values for the registry: "canon" The "alg" parameter entry in the registry should be updated to
as defined in this specification in Section 4.1.1; and "info" as reference [RFCThis] as its specification.
This specification defines one new value for the registry: "info" as
defined in this specification in Section 7.3. defined in this specification in Section 7.3.
13.4. Identity-Info Algorithm Parameter Values 13.4. Identity-Info Algorithm Parameter Values
This IANA manages an Identity-Info Algorithm Parameter Values This IANA manages an Identity-Info Algorithm Parameter Values
registry which this specification deprecates. Since the algorithms registry which this specification deprecates. We request that the
for signing PASSporT objects are defined in PASSporT rather than in IANA delete this registry. Since the algorithms for signing
this specification, there is no longer a need for an algorithm PASSporTs are defined in [I-D.ietf-stir-passport] rather than in this
parameter registry for the Identity header field. specification, there is no longer a need for an algorithm parameter
registry for the Identity header field.
14. Acknowledgments 14. Acknowledgments
The authors would like to thank Olle Jacobson, Dave Frankel, Robert The authors would like to thank Syed Ali, Olle Jacobson, Dave
Sparks, Dave Crocker, Stephen Kent, Brian Rosen, Alex Bobotek, Paul Frankel, Robert Sparks, Dave Crocker, Stephen Kent, Brian Rosen, Alex
Kyzviat, Jonathan Lennox, Richard Shockey, Martin Dolly, Andrew Bobotek, Paul Kyzviat, Jonathan Lennox, Richard Shockey, Martin
Allen, Hadriel Kaplan, Sanjay Mishra, Anton Baskov, Pierce Gorman, Dolly, Andrew Allen, Hadriel Kaplan, Sanjay Mishra, Anton Baskov,
David Schwartz, Eric Burger, Alan Ford, Christer Holmberg, Philippe Pierce Gorman, David Schwartz, Eric Burger, Alan Ford, Christer
Fouquart, Michael Hamer, Henning Schulzrinne, and Richard Barnes for Holmberg, Philippe Fouquart, Michael Hamer, Henning Schulzrinne, and
their comments. Richard Barnes for their comments.
15. Changes from RFC4474 15. Changes from RFC4474
The following are salient changes from the original RFC 4474: The following are salient changes from the original RFC 4474:
Generalized the credential mechanism; credential enrollment, Generalized the credential mechanism; credential enrollment,
acquisition and trust is now outside the scope of this document acquisition and trust is now outside the scope of this document
Reduced the scope of the Identity signature to remove CSeq, Call- Reduced the scope of the Identity signature to remove CSeq, Call-
ID, Contact, and the message body; signing of key fingerprints in ID, Contact, and the message body; signing of key fingerprints in
SDP is now included SDP is now included
Deprecated the Identity-Info header field and relocated its Deprecated the Identity-Info header field and relocated its
components into parameters of the Identity header field (which components into parameters of the Identity header field (which
obsoletes the previous version of the header field) obsoletes the previous version of the header field)
The Identity header field can now appear multiple times in one The Identity header field can now appear multiple times in one
request request
skipping to change at page 40, line 32 skipping to change at page 40, line 21
[I-D.ietf-iri-comparison] [I-D.ietf-iri-comparison]
Masinter, L. and M. D&#258;&#378;rst, "Comparison, Masinter, L. and M. D&#258;&#378;rst, "Comparison,
Equivalence and Canonicalization of Internationalized Equivalence and Canonicalization of Internationalized
Resource Identifiers", draft-ietf-iri-comparison-02 (work Resource Identifiers", draft-ietf-iri-comparison-02 (work
in progress), October 2012. in progress), October 2012.
[I-D.ietf-stir-certificates] [I-D.ietf-stir-certificates]
Peterson, J. and S. Turner, "Secure Telephone Identity Peterson, J. and S. Turner, "Secure Telephone Identity
Credentials: Certificates", draft-ietf-stir- Credentials: Certificates", draft-ietf-stir-
certificates-07 (work in progress), July 2016. certificates-08 (work in progress), September 2016.
[I-D.kaplan-stir-cider] [I-D.kaplan-stir-cider]
Kaplan, H., "A proposal for Caller Identity in a DNS-based Kaplan, H., "A proposal for Caller Identity in a DNS-based
Entrusted Registry (CIDER)", draft-kaplan-stir-cider-00 Entrusted Registry (CIDER)", draft-kaplan-stir-cider-00
(work in progress), July 2013. (work in progress), July 2013.
[I-D.peterson-sipping-retarget] [I-D.peterson-sipping-retarget]
Peterson, J., "Retargeting and Security in SIP: A Peterson, J., "Retargeting and Security in SIP: A
Framework and Requirements", draft-peterson-sipping- Framework and Requirements", draft-peterson-sipping-
retarget-00 (work in progress), February 2005. retarget-00 (work in progress), February 2005.
skipping to change at page 43, line 4 skipping to change at page 42, line 31
Authors' Addresses Authors' Addresses
Jon Peterson Jon Peterson
Neustar, Inc. Neustar, Inc.
1800 Sutter St Suite 570 1800 Sutter St Suite 570
Concord, CA 94520 Concord, CA 94520
US US
Email: jon.peterson@neustar.biz Email: jon.peterson@neustar.biz
Cullen Jennings Cullen Jennings
Cisco Cisco
400 3rd Avenue SW, Suite 350 400 3rd Avenue SW, Suite 350
Calgary, AB T2P 4H2 Calgary, AB T2P 4H2
Canada Canada
Email: fluffy@iii.ca Email: fluffy@cisco.com
Eric Rescorla Eric Rescorla
RTFM, Inc. RTFM, Inc.
2064 Edgewood Drive 2064 Edgewood Drive
Palo Alto, CA 94303 Palo Alto, CA 94303
USA USA
Email: ekr@rtfm.com Email: ekr@rtfm.com
Chris Wendt Chris Wendt
Comcast Comcast
One Comcast Center One Comcast Center
Philadelphia, PA 19103 Philadelphia, PA 19103
USA USA
Email: chris-ietf@chriswendt.net Email: chris-ietf@chriswendt.net
 End of changes. 75 change blocks. 
264 lines changed or deleted 273 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/