draft-ietf-stir-rfc4474bis-11.txt   draft-ietf-stir-rfc4474bis-12.txt 
Network Working Group J. Peterson Network Working Group J. Peterson
Internet-Draft NeuStar Internet-Draft NeuStar
Intended status: Standards Track C. Jennings Intended status: Standards Track C. Jennings
Expires: February 25, 2017 Cisco Expires: March 13, 2017 Cisco
E. Rescorla E. Rescorla
RTFM, Inc. RTFM, Inc.
C. Wendt C. Wendt
Comcast Comcast
August 24, 2016 September 9, 2016
Authenticated Identity Management in the Session Initiation Protocol Authenticated Identity Management in the Session Initiation Protocol
(SIP) (SIP)
draft-ietf-stir-rfc4474bis-11.txt draft-ietf-stir-rfc4474bis-12.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 February 25, 2017. This Internet-Draft will expire on March 13, 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 44 skipping to change at page 2, line 44
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 . . . . . . . . . . . . . . . . . . . . . . . 24
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 Compatibililty with RFC4474 . . . . . . . . . . . . 29
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 30 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 29
12. Security Considerations . . . . . . . . . . . . . . . . . . . 32 12. Security Considerations . . . . . . . . . . . . . . . . . . . 31
12.1. Protected Request Fields . . . . . . . . . . . . . . . . 32 12.1. Protected Request Fields . . . . . . . . . . . . . . . . 32
12.1.1. Protection of the To Header and Retargeting . . . . 34 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 . . . . . . . . . 35
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 . . . . . . . . . . . . . . . . . . . . . 38 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
13.1. SIP Header Fields . . . . . . . . . . . . . . . . . . . 38 13.1. SIP Header Fields . . . . . . . . . . . . . . . . . . . 38
13.2. SIP Response Codes . . . . . . . . . . . . . . . . . . . 38 13.2. SIP Response Codes . . . . . . . . . . . . . . . . . . . 38
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 . . . . . . . . . . . . . . . . . . . . . . . 39 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38
15. Changes from RFC4474 . . . . . . . . . . . . . . . . . . . . 39 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 . . . . . . . . . . . . . . . . . 41 16.2. Informative References . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
This document provides enhancements to the existing mechanisms for This document provides enhancements to the existing mechanisms for
authenticated identity management in the Session Initiation Protocol authenticated identity management in the Session Initiation Protocol
(SIP, [RFC3261]). An identity, for the purposes of this document, is (SIP, [RFC3261]). An identity, for the purposes of this document, is
defined as either a canonical address-of-record (AoR) SIP URI defined as either a canonical address-of-record (AoR) SIP URI
employed to reach a user (such as 'sip:alice@atlanta.example.com'), employed to reach a user (such as 'sip:alice@atlanta.example.com'),
or a telephone number, which commonly appears in either a TEL URI or a telephone number, which commonly appears in either a TEL URI
[RFC3966] or as the user portion of a SIP URI. [RFC3966] or as the user portion of a SIP URI.
skipping to change at page 4, line 29 skipping to change at page 4, line 29
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 extracted from an "identity field" a SIP request Identities are derived from an "identity field" a SIP request such
such as the From header field. 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 47 skipping to change at page 5, line 47
prove a user is authorized to use a particular From header field must prove a user is authorized to use a particular From header field must
ultimately derive from the domain owner: either a user agent gives ultimately derive from the domain owner: either a user agent gives
requests to the domain name owner in order for them to be signed by requests to the domain name owner in order for them to be signed by
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 copied from certain format, a JSON [RFC7159] object comprising values derived from
header field values in the SIP request. The authentication service certain header field values in the SIP request. The authentication
computes a signature over those JSON elements as PASSporT specifies. service computes a signature over those JSON elements as PASSporT
That signature is then placed in the SIP Identity header field. In specifies. That signature is then placed in the SIP Identity header
order to assist in the validation of the Identity header field, this field. In order to assist in the validation of the Identity header
specification also describes a parameter of the Identity header field field, this specification also describes a parameter of the Identity
that can be used by the recipient of a request to recover the header field that can be used by the recipient of a request to
credentials of the signer. 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. PASSporT objects 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 [RFC4234] 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 ident-info \ Identity = "Identity" HCOLON signed-identity-digest SEMI \
*( SEMI ident-info-params ) ident-info *( SEMI ident-info-params )
signed-identity-digest = LDQUOT *base64-char RDQUOT signed-identity-digest = LDQUOT *base64-char RDQUOT
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 / canonical-str / \ ident-info-params = ident-info-alg / ident-type / \
ident-info-extension canonical-str / 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 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 "canon" and "ppt" parameters. The 'absoluteURI' portion of
ident-info-uri MUST contain a URI; see Section 7.3 for more on ident-info-uri MUST contain a URI; see Section 7.3 for more on
choosing how to advertise credentials through this parameter. choosing how to advertise credentials through this parameter.
The signed-identity-digest is the PASSporT signature component of a The signed-identity-digest is the PASSporT signature component of a
PASSporT object [I-D.ietf-stir-passport], a signature which PASSporT PASSporT object [I-D.ietf-stir-passport], a signature which PASSporT
generates over the JSON objects contain headers and claims; some generates over the JSON header and payload objects; some header and
header and claim values will mirror elements of the SIP request. In claim element values will mirror values of the SIP request. In order
order to generate that signature, an implementation must construct a to generate that signature, an implementation must construct a
complete PASSporT object. 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 message MUST
be placed as the values corresponding to the designated JSON keys: be placed 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 key "typ"
key MUST have the value "passport". key 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.
Fourth, the optional JSON key "ppt", if present, MUST have a value Fourth, if a PASSporT extension is in use, then the optional JSON
equivalent to the quoted value of the "ppt" parameter of the key "ppt" MUST be present and have a value equivalent to the
Identity header field. If the "ppt" parameter is absent from the quoted value of the "ppt" parameter of the Identity header field.
header field, the "ppt" key MUST NOT not appear in the JSON header
object.
For example: An example of the PASSporT header JSON object without any extension
is:
{ "typ":"passport", { "typ":"passport",
"alg":"ES256", "alg":"ES256",
"x5u":"https://www.example.com/cert.pkx" } "x5u":"https://www.example.com/cert.pkx" }
To populate the PASSporT claims 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 addr-spec of the From header field, per the
skipping to change at page 8, line 15 skipping to change at page 8, line 15
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, set to the value of a
quoted encoding of the value of the SIP Date header field as a quoted encoding of the value of the SIP Date header field as a
JSON NumericDate (as UNIX time, per [RFC7519] Section 2). JSON NumericDate (as UNIX time, per [RFC7519] Section 2).
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 3.2.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 the PASSporT object could
skipping to change at page 8, line 39 skipping to change at page 8, line 39
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. "orig" and "dest" arrays might be populated with more than one value.
This could for example occur when multiple "dest" identities are This could for example occur when multiple "dest" identities are
specified in a meshed conference. Defining how a SIP implementation specified in a meshed conference. Defining how a SIP implementation
would provision multiple originating or destination identities is would provision multiple originating or destination identities is
left as a subject for future specification. left as a subject for future specification.
After these two JSON objects, the header and the claims, have been After these two JSON objects, the header and the paylod, have been
constructed and base64-encoded, they must each be hashed per constructed and base64-encoded, they must each be hashed per
[I-D.ietf-stir-passport] Section 3.3. The signed value of those [I-D.ietf-stir-passport] Section 5. The signed value of those
concatenated hashes then becomes the signed-identity-string of the concatenated hashes then becomes the signed-identity-string of the
Identity header field. The hashing and signing algorithm is Identity header field. The hashing and signing algorithm is
specified by the 'alg' parameter of the Identity header field and the specified by the 'alg' parameter of the Identity header field and the
mirrored "alg" parameter of PASSporT. This specification inherits mirrored "alg" parameter of PASSporT. This specification inherits
from the PASSporT specification one value for the 'alg' parameter: from the PASSporT specification one 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. All implementations of this specification MUST
support the required signing algorithms of PASSporT. support the required signing algorithms of PASSporT.
The PASSporT signature that serves as the signed-identity-digest for The PASSporT signature that serves as the signed-identity-digest for
skipping to change at page 9, line 22 skipping to change at page 9, line 22
Identity: "sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/Hmty \ Identity: "sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/Hmty \
NS7Ltrg9dlxkWzoeU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21y \ NS7Ltrg9dlxkWzoeU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21y \
NDo2ER/Ovgtw0Lu5csIppPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0 \ NDo2ER/Ovgtw0Lu5csIppPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0 \
gfUs=";info=<https://biloxi.example.org/biloxi.cer>;alg=ES256 gfUs=";info=<https://biloxi.example.org/biloxi.cer>;alg=ES256
4.1.1. 'canon' and PASSporT 4.1.1. 'canon' and PASSporT
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 claims 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 claims 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. Only
the signature component of the PASSporT is REQUIRED in SIP, as it the signature component of the PASSporT is REQUIRED in SIP, as it
forms the contents of the signed-identity-digest field. Optionally, forms the contents of the signed-identity-digest field. Optionally,
as a debugging measure or optimization, the base64-encoded as a debugging measure or optimization, the base64-encoded
concatenation of the JSON header and claims MAY be included as the concatenation of the JSON header and payload MAY be included as the
value of a "canon" parameter of the Identity header field. Note value of a "canon" parameter of the Identity header field. Note
however that the use of some future extensions could require "canon" however that the use of some future extensions could require "canon"
(see Section 9). (see Section 9).
When the "canon" parameter is present, it is populated per the When the "canon" parameter is present, it MUST contain the base64
[I-D.ietf-stir-passport] Section 3.2 payload of PASSporT. However, encoded header and payload of the PASSporT token per
no trailing '.' is included: the string consists solely of the base64 [I-D.ietf-stir-passport]; following JWS, the header and payload are
encoded JSON header object, followed by a '.', followed by the base64 separated by a single '.'. However, no trailing '.' is included in
encoded claims JSON object, as follows: the "canon": the string consists solely of the base64 encoded JSON
header object, followed by a '.', followed by the base64 encoded
payload JSON object, as follows:
Identity: "rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpj \ Identity: "rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpj \
lk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w"; \ lk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w"; \
info=<https://biloxi.example.org/biloxi.c>;alg=ES256;canon= \ info=<https://biloxi.example.org/biloxi.c>;alg=ES256;canon= \
"eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cH \ "eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cH \
M6Ly9jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJkZXN0Ijp7 \ M6Ly9jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJkZXN0Ijp7 \
InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdCI6IjE0NDM \ InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdCI6IjE0NDM \
yMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0" yMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0"
Note that the presence of the "canon" parameter adds considerably to Note that the presence of the "canon" parameter adds considerably to
skipping to change at page 10, line 48 skipping to change at page 10, line 48
. | 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 object which
contains a JSON representation of headers and claims which mirror contains a JSON representation of values which mirror certain parts
certain parts of the SIP request, including the identity in the From of the SIP request, including the identity in the From header field
header field value. As a part of generating the PASSporT object, the value. As a part of generating the PASSporT object, the
authentication service signs a hash of those JSON headers and claims authentication service signs a hash of that JSON header and payload
with the private key associated with the appropriate credential for with the private key associated with the appropriate credential for
the identity (in this example, a certificate with authority to sign the identity (in this example, a certificate with authority to sign
for numbers in a range from 12155551000 to 121555519999), and the for numbers in a range from 12155551000 to 121555519999), and the
signature is inserted by the proxy server into the Identity header signature is inserted by the proxy server into the Identity header
field value of the request. Optionally, the JSON headers and claims field value of the request. Optionally, the JSON header and payload
themselves may also be included in the object, encoded in the "canon" themselves may also be included in the object, encoded in the "canon"
parameter of the Identity header field. parameter of the Identity header field.
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
skipping to change at page 12, line 25 skipping to change at page 12, line 25
Content-Length: 147 Content-Length: 147
v=0 v=0
o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com
s=Session SDP s=Session SDP
c=IN IP4 pc33.atlanta.example.com c=IN IP4 pc33.atlanta.example.com
t=0 0 t=0 0
m=audio 49172 RTP/AVP 0 m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
An authentication service will create a corresponding PASSporT An authentication service will create a corresponding PASSporT
object. The properly-serialized PASSporT header and claims JSON object. The properly-serialized PASSporT header and payload JSON
objects would look as follows. For the header, the values chosen by objects would look as follows. For the header, the values chosen by
the authentication service at "example.org" might read: the authentication service at "example.org" might read:
{"alg":"ES256","typ":"passport","x5u":"https://cert.example.org/ {"alg":"ES256","typ":"passport","x5u":"https://cert.example.org/
passport.cer"} passport.cer"}
The serialized claims will derive from the SIP request (the From, To, The serialized payload will derive values from the SIP request (the
and Date header field values) as follows: From, To, and Date header field values) as follows:
{"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 3.3. 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 would thus generate
and add to the request an Identity header field of the following and add to the request an Identity header field of the following
form: form:
Identity: "rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpj \ Identity: "rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpj \
lk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w"; \ lk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w"; \
skipping to change at page 15, line 37 skipping to change at page 15, line 37
Step 5: Add "canon", if Needed Step 5: Add "canon", if Needed
An authentication service MAY add a "canon" parameter to the Identity An authentication service MAY add a "canon" parameter to the Identity
header field. The presence of "canon" is OPTIONAL because the header field. The presence of "canon" is OPTIONAL because the
information carried in the baseline PASSporT object's headers and information carried in the baseline PASSporT object's headers and
claims is usually redundant with information already carried claims is usually redundant with information already carried
elsewhere in the SIP request. Omitting "canon" can significantly elsewhere in the SIP request. Omitting "canon" can significantly
reduce SIP message size, especially when the PASSporT object contains reduce SIP message size, especially when the PASSporT object contains
media keys. The syntax of "canon" is given in Section 4.1.1; media keys. The syntax of "canon" is given in Section 4.1.1;
essentially, it contains a base64 encoding of the JSON header and essentially, it contains a base64 encoding of the JSON header and
claims in the PASSporT object. payload in the PASSporT object.
When however an authentication service creates a PASSporT object that When however an authentication service creates a PASSporT object that
uses extension claims beyond the baseline PASSporT object, including uses extension claims beyond the baseline PASSporT object, including
"canon" is REQUIRED in order for the verification service to be "canon" is REQUIRED in order for the verification service to be
capable of validating the signature. See Section 9. 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
skipping to change at page 19, line 23 skipping to change at page 19, line 23
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. Relying
on the full PASSporT object presented through the "canon" parameter on the full PASSporT object presented through the "canon" parameter
can repair some of these conditions (see Section 6.2.3), so the can repair some of these conditions (see Section 6.2.3), so the
recommended way to attempt to repair this failure is to retry the recommended way to attempt to repair this failure is to retry the
request with "canon". request with "canon".
Finally, a 403 with the special reason phase 'Stale Date" response Finally, a 403 response with the special reason phase '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 "canon" parameter of a request has a value older than the local
policy for freshness permits. policy for freshness permits.
6.2.3. Handling 'canon' parameters 6.2.3. Handling 'canon' parameters
If the optional "canon" parameter of the Identity header field is If the optional "canon" parameter of the Identity header field is
present, it contains a base64 encoding of the header and claim present, it contains a base64 encoding of the header and claim
component of the PASSporT object constructed by the authentication component of the PASSporT object constructed by the authentication
service (see Section 4.1.1). The verification service can thus service (as detailed in Section 4.1.1). The verification service can
extract from it the canonical telephone number created by the thus extract from it the canonical telephone number created by the
authentication service, as well as an "iat" claim corresponding to authentication service, as well as an "iat" claim corresponding to
the Date header field that the authentication service used. These the Date header field that the authentication service used. These
may be used to debug canonicalization problems, or to avoid may be used to debug canonicalization problems, or to avoid
unnecessary signature breakage caused by intermediaries that alter unnecessary signature breakage caused by intermediaries 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 "canon" is present, the verification service
MAY compute its own canonicalization of an originating telephone MAY compute its own canonicalization of an originating telephone
number and compare it to the values in the "canon" parameter before number and compare it to the values in the "canon" parameter before
performing any cryptographic functions in order to ascertain whether performing any cryptographic functions in order to ascertain whether
skipping to change at page 24, line 20 skipping to change at page 24, line 20
dominant use case in the deployment of SIP. However, the Identity dominant use case in the deployment of SIP. However, the Identity
header mechanism also works with SIP URIs without telephone numbers header mechanism also works with SIP URIs without telephone numbers
(of the form "sip:user@host"), and potentially other identifiers when (of the form "sip:user@host"), and potentially other identifiers when
SIP interworks with other protocols. SIP interworks with other protocols.
Authentication services vet the identity of the originator of a call, Authentication services vet the identity of the originator of a call,
which is typically found in the From header field value. The which is typically found in the From header field value. The
guidance in this specification also applies to extracting the URI guidance in this specification also applies to extracting the URI
containing the originator's identity from the P-Asserted-Identity containing the originator's identity from the P-Asserted-Identity
header field value instead of the From header field value. In some header field value instead of the From header field value. In some
environments, the P-Asserted-Identity header field is used in lieu of trusted environments, the P-Asserted-Identity header field is used in
the From header field to convey the address-of-record or telephone lieu of the From header field to convey the address-of-record or
number of the originator of a request; where it does, local policy telephone number of the originator of a request; where it does, local
might therefore dictate that the canonical identity derive from the policy might therefore dictate that the canonical identity derives
P-Asserted-Identity header field rather than the From header field. from the P-Asserted-Identity header field rather than the From header
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 "canon" parameter by authentication services is
RECOMMENDED, but because "canon" itself could then divulge RECOMMENDED, but because "canon" itself could then divulge
information about users or networks, implementers should be mindful information about users or networks, implementers should be mindful
of the guidelines in Section 11. of the guidelines in Section 11.
8.1. Differentiating Telephone Numbers from URIs 8.1. Differentiating Telephone Numbers from URIs
skipping to change at page 25, line 16 skipping to change at page 25, line 17
start of the user-portion. Absent these indications, if there are start of the user-portion. Absent these indications, if there are
numbers present in the user-portion, implementations may also detect numbers present in the user-portion, implementations may also detect
that the user-portion of the URI contains a telephone number by that the user-portion of the URI contains a telephone number by
determining whether or not those numbers would be dialable or determining whether or not those numbers would be dialable or
routable in the local environment -- bearing in mind that the routable in the local environment -- bearing in mind that the
telephone number may be a valid [E.164] number, a nationally-specific telephone number may be a valid [E.164] number, a nationally-specific
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, URI If the URI field does not contain a telephone number, or if the
normalization procedures are invoked to canonicalize the URI before result of the canonicalization of the From header field value does
it is included in a PASSporT object in, for example, an "uri" claim. not form a valid E.164 telephone number, the authentication service
See Section 8.5 for that behavior. and/or verification service SHOULD treat the entire URI as a SIP URI,
and apply the procedures in Section 8.5. These URI normalization
procedures are invoked to canonicalize the URI before it is included
in a PASSporT object in, for example, an "uri" claim. See
Section 8.5 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
management for telephone numbers are discussed in management for telephone numbers are discussed in
[I-D.ietf-stir-certificates]. [I-D.ietf-stir-certificates].
8.3. Telephone Number Canonicalization Procedures 8.3. Telephone Number Canonicalization Procedures
Once an implementation has identified a telephone number in the URI, Once an implementation has identified a telephone number, it must
it must construct a number string. That requires performing the construct a number string. That requires performing the following
following steps: steps:
Implementations MUST drop any "+"s, any internal dashes, Implementations MUST drop any "+"s, any internal dashes,
parentheses or other non-numeric characters, excepting only the parentheses or other non-numeric characters, excepting only the
leading "#" or "*" keys used in some special service numbers leading "#" or "*" keys used in some special service numbers
(typically, these will appear only in the To header field value). (typically, these will appear only in the To header field value).
This MUST result in an ASCII string limited to "#", "*" and digits This MUST result in an ASCII string limited to "#", "*" and digits
without whitespace or visual separators. without whitespace or visual separators.
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
skipping to change at page 26, line 17 skipping to change at page 26, line 24
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, the routing procedures associated with those numbers will
likely make sure that the verification service understands the likely make sure that the verification service understands the
context of their use. context of their use.
Other transformations during canonicalization MAY be made in Other transformations during canonicalization MAY be made in
accordance with specific policies used within a local domain. For accordance with specific policies used within a local domain. For
example, one domain may only use local number formatting and need example, one domain may only use local number formatting and need
to convert all To/From header field user portions to E.164 by to convert all To/From header field user portions to E.164 by
prepending country-code and region code digits; another domain prepending country-code and region code digits; another domain
might haved prefixed usernames with trunk-routing codes, in which might have prefixed usernames with trunk-routing codes, in which
case the canonicalization will need to remove the prefix. This case the canonicalization will need to remove the prefix. This
specification cannot anticipate all of the potential specification cannot anticipate all of the potential
transformations that might be useful. 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
If the result of this procedure forms a full E.164 telephone number, The resulting number string is used in the construction of the
that number is used for the purpose of creating the signed-identity- telephone number field(s) in a PASSporT object.
string by both the authentication service and verification service.
Practically, entities that perform the authentication service role
will sometimes alter the telephone numbers that appear in the To and
From header field values, converting them to this format (though note
this is not a function that [RFC3261] permits proxy servers to
perform). The result of the canonicalization process of the From
header field value may also be recorded through the use of the
"canon" parameter of the Identity (see Section 4).
If the result of the canonicalization of the From header field value
does 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 apply the procedures in Section 8.5.
8.4. Authority for Domain Names 8.4. Authority for Domain Names
To use a SIP URI as an identity in this mechanism requires To use a SIP URI as an identity in this mechanism requires
authentication and verification systems to support standard authentication and verification systems to support standard
mechanisms for proving authority over a domain name: that is, the mechanisms for proving authority over a domain name: that is, the
domain name in the host portion of the SIP URI. domain name in the host portion of the SIP URI.
A verifier MUST evaluate the correspondence between the user's A verifier MUST evaluate the correspondence between the user's
identity and the signing credential by following the procedures identity and the signing credential by following the procedures
skipping to change at page 28, line 27 skipping to change at page 28, line 19
The hostport portion of the SIP or SIPS URI MUST similarly be The hostport portion of the SIP or SIPS URI MUST similarly be
stripped of any trailing port along with the ":" that proceeds the stripped of any trailing port along with the ":" that proceeds the
port, leaving only the host. port, leaving only the host.
The ABNF of this canonical URI form (following the syntax defined in The ABNF of this canonical URI form (following the syntax defined in
RFC3261) is: RFC3261) is:
canon-uri = ( "sip" / "sips" ) ":" user "@" host canon-uri = ( "sip" / "sips" ) ":" user "@" host
Finally, the URI will be subject to syntax-based URI normalization Finally, the URI will be subject to syntax-based URI normalization
procedures of [RFC3986] Section 6.2.2, especially to perform case procedures of [RFC3986] Section 6.2.2. Implementations MUST perform
normalization and percent-encoding normalization. However, note that case normalization (rendering the scheme, user, and host all
normalization procedures face known challenges in some lowercase) and percent-encoding normalization (decoding any percent-
internationalized environments (see [I-D.ietf-iri-comparison]) and encoded octet that corresponds to an unreserved character, per
that perfect normalization of URIs may not be possible in those [RFC3986] Section 2.3). However, note that normalization procedures
environments. face known challenges in some internationalized environments (see
[I-D.ietf-iri-comparison]) and that perfect normalization of URIs may
not be possible in those environments.
For future PASSporT applications, it may be desirable to provide an For future PASSporT applications, it may be desirable to provide an
identifier without an attached protocol scheme. Future identifier without an attached protocol scheme. Future
specifications that define PASSporT claims for SIP as a using specifications that define PASSporT claims for SIP as a using
protocol could use these basic procedures, but eliminate the scheme protocol could use these basic procedures, but eliminate the scheme
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 4. mechanism specified in [I-D.ietf-stir-passport] Section 6.
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 39, line 21 skipping to change at page 39, line 4
David Schwartz, Eric Burger, Alan Ford, Christer Holmberg, Philippe David Schwartz, Eric Burger, Alan Ford, Christer Holmberg, Philippe
Fouquart, Michael Hamer, Henning Schulzrinne, and Richard Barnes for Fouquart, Michael Hamer, Henning Schulzrinne, and Richard Barnes for
their comments. 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 ID, Contact, and the message body; signing of key fingerprints in
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
Replaced previous signed-identity-digest format with PASSporT Replaced previous signed-identity-digest format with PASSporT
(signing algorithms now defined there) (signing algorithms now defined in a separate specification)
Revised status code descriptions Revised status code descriptions
16. References 16. References
16.1. Normative References 16.1. Normative References
[E.164] ITU-T, "The international public telecommunication [E.164] ITU-T, "The international public telecommunication
numbering plan", E 164, February 2005, numbering plan", E 164, February 2005,
<https://www.itu.int/rec/T-REC-E.164/en>. <https://www.itu.int/rec/T-REC-E.164/en>.
[I-D.ietf-stir-passport] [I-D.ietf-stir-passport]
Wendt, C. and J. Peterson, "Persona Assertion Token", Wendt, C. and J. Peterson, "Persona Assertion Token",
draft-ietf-stir-passport-06 (work in progress), August draft-ietf-stir-passport-07 (work in progress), September
2016. 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>. <http://www.rfc-editor.org/info/rfc3261>.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263, Protocol (SIP): Locating SIP Servers", RFC 3263,
DOI 10.17487/RFC3263, June 2002, DOI 10.17487/RFC3263, June 2002,
<http://www.rfc-editor.org/info/rfc3263>. <http://www.rfc-editor.org/info/rfc3263>.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
DOI 10.17487/RFC3280, April 2002,
<http://www.rfc-editor.org/info/rfc3280>.
[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002,
<http://www.rfc-editor.org/info/rfc3370>.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, DOI 10.17487/RFC3966, December 2004, RFC 3966, DOI 10.17487/RFC3966, December 2004,
<http://www.rfc-editor.org/info/rfc3966>. <http://www.rfc-editor.org/info/rfc3966>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>. <http://www.rfc-editor.org/info/rfc3986>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>. <http://www.rfc-editor.org/info/rfc5280>.
[RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain [RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain
Certificates in the Session Initiation Protocol (SIP)", Certificates in the Session Initiation Protocol (SIP)",
RFC 5922, DOI 10.17487/RFC5922, June 2010, RFC 5922, DOI 10.17487/RFC5922, June 2010,
<http://www.rfc-editor.org/info/rfc5922>. <http://www.rfc-editor.org/info/rfc5922>.
[RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words
for Use in RFCs to Indicate Requirement Levels", RFC 6919,
DOI 10.17487/RFC6919, April 2013,
<http://www.rfc-editor.org/info/rfc6919>.
16.2. Informative References 16.2. Informative References
[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
skipping to change at page 42, line 11 skipping to change at page 41, line 16
Initiation Protocol (SIP)", RFC 3323, Initiation Protocol (SIP)", RFC 3323,
DOI 10.17487/RFC3323, November 2002, DOI 10.17487/RFC3323, November 2002,
<http://www.rfc-editor.org/info/rfc3323>. <http://www.rfc-editor.org/info/rfc3323>.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325, Asserted Identity within Trusted Networks", RFC 3325,
DOI 10.17487/RFC3325, November 2002, DOI 10.17487/RFC3325, November 2002,
<http://www.rfc-editor.org/info/rfc3325>. <http://www.rfc-editor.org/info/rfc3325>.
[RFC3548] Josefsson, S., Ed., "The Base16, Base32, and Base64 Data
Encodings", RFC 3548, DOI 10.17487/RFC3548, July 2003,
<http://www.rfc-editor.org/info/rfc3548>.
[RFC3893] Peterson, J., "Session Initiation Protocol (SIP) [RFC3893] Peterson, J., "Session Initiation Protocol (SIP)
Authenticated Identity Body (AIB) Format", RFC 3893, Authenticated Identity Body (AIB) Format", RFC 3893,
DOI 10.17487/RFC3893, September 2004, DOI 10.17487/RFC3893, September 2004,
<http://www.rfc-editor.org/info/rfc3893>. <http://www.rfc-editor.org/info/rfc3893>.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, DOI 10.17487/RFC4234,
October 2005, <http://www.rfc-editor.org/info/rfc4234>.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, Initiation Protocol (SIP)", RFC 4474,
DOI 10.17487/RFC4474, August 2006, DOI 10.17487/RFC4474, August 2006,
<http://www.rfc-editor.org/info/rfc4474>. <http://www.rfc-editor.org/info/rfc4474>.
[RFC4501] Josefsson, S., "Domain Name System Uniform Resource [RFC4501] Josefsson, S., "Domain Name System Uniform Resource
Identifiers", RFC 4501, DOI 10.17487/RFC4501, May 2006, Identifiers", RFC 4501, DOI 10.17487/RFC4501, May 2006,
<http://www.rfc-editor.org/info/rfc4501>. <http://www.rfc-editor.org/info/rfc4501>.
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation [RFC4916] Elwell, J., "Connected Identity in the Session Initiation
Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June
2007, <http://www.rfc-editor.org/info/rfc4916>. 2007, <http://www.rfc-editor.org/info/rfc4916>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing a Secure Real-time Transport Protocol for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer (SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May
2010, <http://www.rfc-editor.org/info/rfc5763>. 2010, <http://www.rfc-editor.org/info/rfc5763>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS) of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <http://www.rfc-editor.org/info/rfc6698>. 2012, <http://www.rfc-editor.org/info/rfc6698>.
 End of changes. 50 change blocks. 
135 lines changed or deleted 108 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/