draft-ietf-stir-rfc4474bis-14.txt   draft-ietf-stir-rfc4474bis-15.txt 
Network Working Group J. Peterson Network Working Group J. Peterson
Internet-Draft NeuStar Internet-Draft NeuStar
Obsoletes: 4474 (if approved) C. Jennings Obsoletes: 4474 (if approved) C. Jennings
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: April 21, 2017 E. Rescorla Expires: May 4, 2017 E. Rescorla
RTFM, Inc. RTFM, Inc.
C. Wendt C. Wendt
Comcast Comcast
October 18, 2016 October 31, 2016
Authenticated Identity Management in the Session Initiation Protocol Authenticated Identity Management in the Session Initiation Protocol
(SIP) (SIP)
draft-ietf-stir-rfc4474bis-14.txt draft-ietf-stir-rfc4474bis-15.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 April 21, 2017. This Internet-Draft will expire on May 4, 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 24 skipping to change at page 2, line 24
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. Example Full and Compact Forms of PASSporT in 4.1.1. Example Full and Compact Forms of PASSporT in
Identity . . . . . . . . . . . . . . . . . . . . . . 9 Identity . . . . . . . . . . . . . . . . . . . . . . 9
5. Example of Operations . . . . . . . . . . . . . . . . . . . . 9 5. Example of Operations . . . . . . . . . . . . . . . . . . . . 10
5.1. Example Identity Header Construction . . . . . . . . . . 11 5.1. Example Identity Header Construction . . . . . . . . . . 11
6. Signature Generation and Validation . . . . . . . . . . . . . 12 6. Signature Generation and Validation . . . . . . . . . . . . . 13
6.1. Authentication Service Behavior . . . . . . . . . . . . . 12 6.1. Authentication Service Behavior . . . . . . . . . . . . . 13
6.1.1. Handling Repairable Errors . . . . . . . . . . . . . 15 6.1.1. Handling Repairable Errors . . . . . . . . . . . . . 15
6.2. Verifier Behavior . . . . . . . . . . . . . . . . . . . . 15 6.2. Verifier Behavior . . . . . . . . . . . . . . . . . . . . 16
6.2.1. Authorization of Requests . . . . . . . . . . . . . . 17 6.2.1. Authorization of Requests . . . . . . . . . . . . . . 17
6.2.2. Failure Response Codes Sent by a Verification Service 18 6.2.2. Failure Response Codes Sent by a Verification Service 18
6.2.3. Handling the full form of PASSporT . . . . . . . . . 19 6.2.3. Handling the full form of PASSporT . . . . . . . . . 19
7. Credentials . . . . . . . . . . . . . . . . . . . . . . . . . 19 7. Credentials . . . . . . . . . . . . . . . . . . . . . . . . . 20
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 . . . . . . . 22
7.3. 'info' parameter URIs . . . . . . . . . . . . . . . . . . 22 7.3. 'info' parameter URIs . . . . . . . . . . . . . . . . . . 22
7.4. Credential System Requirements . . . . . . . . . . . . . 22 7.4. Credential System Requirements . . . . . . . . . . . . . 23
8. Identity Types . . . . . . . . . . . . . . . . . . . . . . . 23 8. Identity Types . . . . . . . . . . . . . . . . . . . . . . . 24
8.1. Differentiating Telephone Numbers from URIs . . . . . . . 24 8.1. Differentiating Telephone Numbers from URIs . . . . . . . 25
8.2. Authority for Telephone Numbers . . . . . . . . . . . . . 25 8.2. Authority for Telephone Numbers . . . . . . . . . . . . . 26
8.3. Telephone Number Canonicalization Procedures . . . . . . 25 8.3. Telephone Number Canonicalization Procedures . . . . . . 26
8.4. Authority for Domain Names . . . . . . . . . . . . . . . 26 8.4. Authority for Domain Names . . . . . . . . . . . . . . . 27
8.5. URI Normalization . . . . . . . . . . . . . . . . . . . . 27 8.5. URI Normalization . . . . . . . . . . . . . . . . . . . . 28
9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 28 9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 29
10. Backwards Compatibility with RFC4474 . . . . . . . . . . . . 29 10. Backwards Compatibility with RFC4474 . . . . . . . . . . . . 30
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 29 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 30
12. Security Considerations . . . . . . . . . . . . . . . . . . . 31 12. Security Considerations . . . . . . . . . . . . . . . . . . . 32
12.1. Protected Request Fields . . . . . . . . . . . . . . . . 31 12.1. Protected Request Fields . . . . . . . . . . . . . . . . 32
12.1.1. Protection of the To Header and Retargeting . . . . 33 12.1.1. Protection of the To Header and Retargeting . . . . 34
12.2. Unprotected Request Fields . . . . . . . . . . . . . . . 34 12.2. Unprotected Request Fields . . . . . . . . . . . . . . . 35
12.3. Malicious Removal of Identity Headers . . . . . . . . . 34 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 . 36
12.5. Authorization and Transitional Strategies . . . . . . . 36 12.5. Authorization and Transitional Strategies . . . . . . . 37
12.6. Display-Names and Identity . . . . . . . . . . . . . . . 37 12.6. Display-Names and Identity . . . . . . . . . . . . . . . 38
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
13.1. SIP Header Fields . . . . . . . . . . . . . . . . . . . 37 13.1. SIP Header Fields . . . . . . . . . . . . . . . . . . . 38
13.2. SIP Response Codes . . . . . . . . . . . . . . . . . . . 37 13.2. SIP Response Codes . . . . . . . . . . . . . . . . . . . 38
13.3. Identity-Info Parameters . . . . . . . . . . . . . . . . 38 13.3. Identity-Info Parameters . . . . . . . . . . . . . . . . 39
13.4. Identity-Info Algorithm Parameter Values . . . . . . . . 38 13.4. Identity-Info Algorithm Parameter Values . . . . . . . . 39
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39
15. Changes from RFC4474 . . . . . . . . . . . . . . . . . . . . 38 15. Changes from RFC4474 . . . . . . . . . . . . . . . . . . . . 39
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
16.1. Normative References . . . . . . . . . . . . . . . . . . 39 16.1. Normative References . . . . . . . . . . . . . . . . . . 40
16.2. Informative References . . . . . . . . . . . . . . . . . 40 16.2. Informative References . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
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 5, line 48 skipping to change at page 5, line 48
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 derived from format, which is special encoding of a JSON [RFC7159] object
certain header field values in the SIP request. The authentication comprising values derived from certain header field values in the SIP
service computes a signature over those JSON elements as PASSporT request. The authentication service computes a signature over those
specifies. An encoding of the resulting PASSporT is then placed in JSON elements as PASSporT specifies. An encoding of the resulting
the SIP Identity header field. In order to assist in the validation PASSporT is then placed in the SIP Identity header field. In order
of the Identity header field, this specification also describes a to assist in the validation of the Identity header field, this
parameter of the Identity header field that can be used by the specification also describes a parameter of the Identity header field
recipient of a request to recover the credentials of the signer. that can be used by the 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
PASSporTs 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 = *base64-char 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 /
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
ident-info-extension = generic-param ident-info-extension = generic-param
base64-char = ALPHA / DIGIT / "/" / "+" base64-char = ALPHA / DIGIT / "/" / "+"
skipping to change at page 7, line 38 skipping to change at page 7, line 38
is: is:
{ "typ":"passport", { "typ":"passport",
"alg":"ES256", "alg":"ES256",
"x5u":"https://www.example.com/cert.cer" } "x5u":"https://www.example.com/cert.cer" }
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" object 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 JSON object containing a "tn" element with a
quoted originating identity, a canonicalized telephone number (see value set to the value of the quoted originating identity, a
Section 8.3). Otherwise, the array MUST be populated with a "uri" canonicalized telephone number (see Section 8.3). Otherwise, the
claim, set to the value of the AoR of the UA sending the message object MUST be populated with a JSON object containing "uri"
element, set to the value of the AoR of the UA sending the message
as taken from the 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 JSON object containing a "tn" element with a
quoted destination identity, a canonicalized telephone number (see value set to the value of the quoted destination identity, a
Section 8.3). Otherwise, the array MUST be populated with a "uri" canonicalized telephone number (see Section 8.3). Otherwise, the
claim, set to the value of the addr-spec component of the To array MUST be populated with a JSON object containing a "uri"
element, 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. Multiple JSON objects are
permitted in "dest" for future compatibility reasons.
Third, the JSON key "iat" MUST appear. The authentication service Third, the JSON key "iat" MUST appear. The authentication service
SHOULD set the value of "iat" to a quoted encoding of the value of SHOULD set the value of "iat" to an encoding of the value of the
the SIP Date header field as a JSON NumericDate (as UNIX time, per SIP Date header field as a JSON NumericDate (as UNIX time, per
[RFC7519] Section 2), though an authentication service MAY set the [RFC7519] Section 2), though an authentication service MAY set the
value of "iat" to its own current clock time. The authentication value of "iat" to its own current clock time. If the
service MUST NOT generate a PASSporT for a SIP request if the Date authentication service uses its own clock time then the use of the
header is outside of its local policy for freshness (recommended full form of PASSporT is REQUIRED. In either case, the
sixty seconds). 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 5.2.2. given in [I-D.ietf-stir-passport] Section 5.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 PASSporT could introduce Section 12. Note that future extensions to PASSporT could introduce
new claims, and that further SIP procedures could be required to new claims, and that further SIP procedures could be required to
extract information from the SIP request to populate the values of extract information from the SIP request to populate the 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
skipping to change at page 12, line 13 skipping to change at page 12, line 35
object. The properly-serialized PASSporT header and payload 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 payload will derive values from the SIP request (the The serialized payload will derive values from the SIP request (the
From, To, 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 6. That signature would look as follows: Section 6. That signature would look as follows:
rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYs \ rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYs \
ojNCpTzO3QfPOlckGaS6hEck7w ojNCpTzO3QfPOlckGaS6hEck7w
An authentication service signing this request and using the compact An authentication service signing this request and using the compact
skipping to change at page 19, line 30 skipping to change at page 19, line 48
6.2.3. Handling the full form of PASSporT 6.2.3. Handling the full form of PASSporT
If the full form of PASSporT is present in an Identity header, this If the full form of PASSporT is present in an Identity header, this
permits the use of optional extensions as described in permits the use of optional extensions as described in
[I-D.ietf-stir-passport] Section 8.3. Furthermore, the verification [I-D.ietf-stir-passport] Section 8.3. Furthermore, the verification
service can extract from the "orig" and "dest" elements of the service can extract from the "orig" and "dest" elements of the
PASSporT full form the canonical telephone numbers created by the PASSporT full form the canonical telephone numbers 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 values 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 SIP header field values in transit. certain SIP header field values in transit.
As an optimization, when the full form is present, the verification However, the verification service MUST NOT treat the value in the
service MAY compute its own canonicalization of an originating "orig" of a full form PASSporT as the originating identity of the
telephone number and compare it to the values in the "orig" element call: the originating identity of the call is always derived from the
of PASSporT before performing any cryptographic functions in order to SIP signaling, and it is that value, per the procedures above in
ascertain whether or not the two ends agree on the canonical number Section 6.2 Step 2, which is used to recompute the signature at the
form. verification service. That value, rather than the value inside the
PASSporT object, is rendered to an end user in ordinary SIP
operations, and if a verification service were to simply trust that
the value in the "orig" corresponded to the call that it received
without comparing it to the call signaling, this would enable various
cut-and-paste attacks. As an optimization, when the full form is
present, the verification service MAY delay performing that
cryptographic operation and first compute its own canonicalization of
an originating telephone number to compare it to the values in the
"orig" element of PASSporT. This would allow the verification
service to ascertain whether or not the two ends agree on the
canonical number form; if they do not, then surely the signature
validation would fail.
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 21 skipping to change at page 25, line 7
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 full form of PASSporT by authentication services is the use of the full form of PASSporT by authentication services is
RECOMMENDED, but because the "orig" claim of PASSporT itself could RECOMMENDED, but because the "orig" claim of PASSporT itself could
then divulge information about users or networks, implementers should then divulge information about users or networks, implementers should
be mindful of the guidelines in Section 11. 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 In order to determine whether or not the user portion of a SIP URI is
number. In order to determine whether or not the user portion of a a telephone number, authentication services and verification services
SIP URI is a telephone number, authentication services and MUST perform the following procedure on any SIP URI they inspect
verification services MUST perform the following procedure on any SIP which contains a numeric user part. Note that the same procedures
URI they inspect which contains a numeric user part. Note that the are followed for creating the canonical form of a URI found in the
same procedures are followed for creating the canonical form of URIs From header field as they are for one found in the To header field or
found in the From header field as they are in the To header field or
the P-Asserted-Identity header field. the P-Asserted-Identity header field.
First, implementations must look for obvious indications that the First, implementations will ascertain if the user-portion of the URI
user-portion of the URI constitutes a telephone number. Telephone constitutes a telephone number. Telephone numbers most commonly
numbers most commonly appear in SIP header field values in the appear in SIP header field values in the username portion of a SIP
username portion of a SIP URI (e.g., URI (e.g., 'sip:+17005551008@chicago.example.com;user=phone'). The
'sip:+17005551008@chicago.example.com;user=phone'). The user part of user part of SIP URIs with the "user=phone" parameter conforms to the
that URI conforms to the syntax of the TEL URI scheme (RFC 3966 syntax of the TEL URI scheme (RFC 3966 [RFC3966]). It is also
[RFC3966]). It is also possible for a TEL URI to appear in the SIP possible for a TEL URI to appear in SIP header fields outside the
To or From header field outside the context of a SIP or SIPS URI context of a SIP or SIPS URI (e.g., 'tel:+17005551008'). Thus, in
(e.g., 'tel:+17005551008'). Thus, in standards-compliant standards-compliant environments, numbers will be explicitly labeled
environments, numbers will be explicitly labeled by the use of TEL by the use of TEL URIs or the 'user=phone' parameter.
URIs or the 'user=phone' parameter. Outside of those environments,
implementations may infer that the user part is a telephone number
due to the presence of the '+' indicator at the start of the user-
portion. Absent even that indication, if there are numbers present
in the user-portion, implementations might conceivably also detect
that the user-portion of the URI contains a telephone number by
determining whether or not those numbers would be dialable or
routable in the local environment -- bearing in mind that the
telephone number may be a valid [E.164] number, a nationally-specific
number, or even a private branch exchange number. Whatever the
process, once a telephone number has been detected, implementations
SHOULD follow the procedures in Section 8.3.
If the URI field does not contain a telephone number, or if the Alternatively, implementations in environments that do not conform to
result of the canonicalization of the From header field value does those standards MAY follow local policies for identifying telephone
not form a valid E.164 telephone number, the authentication service numbers. For exampple, implementations could infer that the user
and/or verification service SHOULD treat the entire URI as a SIP URI, part is a telephone number due to the presence of the '+' indicator
and apply the procedures in Section 8.5. These URI normalization at the start of the user-portion. Absent even that indication, if
procedures are invoked to canonicalize the URI before it is included there are numbers present in the user-portion, implementations might
in a PASSporT object in, for example, a "uri" claim. See Section 8.5 conceivably also detect that the user-portion of the URI contains a
for that behavior. telephone number by determining whether or not those numbers would be
dialable or routable in the local environment -- bearing in mind that
the telephone number may be a valid [E.164] number, a nationally-
specific number, or even a private branch exchange number.
Implementations could also rely on external hints: for example, a
verification service implementation could infer from the type of
credential that signed a request that the signature must be over a
telephone number.
Regardless of how the implementation detects telephone numbers, once
a telephone number has been detected, implementations SHOULD follow
the procedures in Section 8.3. If the URI field does not contain a
telephone number, or 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.
These URI normalization procedures are invoked to canonicalize the
URI before it is included in a PASSporT object in, for example, a
"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
skipping to change at page 27, line 6 skipping to change at page 27, line 46
'virtual hosting' cases where multiple domains are managed by a 'virtual hosting' cases where multiple domains are managed by a
single application (see [RFC5922] Section 7.8). Secondly, some SIP single application (see [RFC5922] Section 7.8). Secondly, some SIP
services may delegate SIP functions to a subordinate domain and services may delegate SIP functions to a subordinate domain and
utilize the procedures in [RFC3263] that allow requests for, say, utilize the procedures in [RFC3263] that allow requests for, say,
'example.com' to be routed to 'sip.example.com'. As a result, a user 'example.com' to be routed to 'sip.example.com'. As a result, a user
with the AoR 'sip:alice@example.com' may process requests through a with the AoR 'sip:alice@example.com' may process requests through a
host like 'sip.example.com', and it may be that latter host that acts host like 'sip.example.com', and it may be that latter host that acts
as an authentication service. as an authentication service.
To address the second of these problems, a domain that deploys an To address the second of these problems, a domain that deploys an
authentication service on a subordinate host MUST be willing to authentication service on a subordinate host might supply that host
supply that host with the private keying material associated with a with the private keying material associated with a credential whose
credential whose subject is a domain name that corresponds to the subject is a domain name that corresponds to the domain portion of
domain portion of the AoRs that the domain distributes to users. the AoRs that the domain distributes to users. Note that this
Note that this corresponds to the comparable case of routing inbound corresponds to the comparable case of routing inbound SIP requests to
SIP requests to a domain. When the NAPTR and SRV procedures of RFC a domain. When the NAPTR and SRV procedures of RFC 3263 are used to
3263 are used to direct requests to a domain name other than the direct requests to a domain name other than the domain in the
domain in the original Request-URI (e.g., for original Request-URI (e.g., for 'sip:alice@example.com', the
'sip:alice@example.com', the corresponding SRV records point to the corresponding SRV records point to the service 'sip1.example.org'),
service 'sip1.example.org'), the client expects that the certificate the client expects that the certificate passed back in any TLS
passed back in any TLS exchange with that host will correspond exchange with that host will correspond exactly with the domain of
exactly with the domain of the original Request-URI, not the domain the original Request-URI, not the domain name of the host.
name of the host. Consequently, in order to make inbound routing to Consequently, in order to make inbound routing to such SIP services
such SIP services work, a domain administrator must similarly be work, a domain administrator must similarly be willing to share the
willing to share the domain's private key with the service. This domain's private key with the service. This design decision was made
design decision was made to compensate for the insecurity of the DNS, to compensate for the insecurity of the DNS, and it makes certain
and it makes certain potential approaches to DNS-based 'virtual potential approaches to DNS-based 'virtual hosting' unsecurable for
hosting' unsecurable for SIP in environments where domain SIP in environments where domain administrators are unwilling to
administrators are unwilling to share keys with hosting services. share keys with hosting services.
8.5. URI Normalization 8.5. URI Normalization
Just as telephone numbers may undergo a number of syntactic Just as telephone numbers may undergo a number of syntactic
transformations during transit, the same can happen to SIP and SIPS transformations during transit, the same can happen to SIP and SIPS
URIs without telephone numbers as they traverse certain URIs without telephone numbers as they traverse certain
intermediaries. Therefore, when generating a PASSporT object based intermediaries. Therefore, when generating a PASSporT object based
on a SIP request, any SIP and SIPS URIs must be transformed into a on a SIP request, any SIP and SIPS URIs must be transformed into a
canonical form which captures the address-of-record represented by canonical form which captures the address-of-record represented by
the URI before they are provisioned in PASSporT claims such as "uri". the URI before they are provisioned in PASSporT claims such as "uri".
skipping to change at page 33, line 18 skipping to change at page 34, line 15
corresponding to the fingerprint. For example, there are some corresponding to the fingerprint. For example, there are some
baiting attacks, launched with the REFER method or through social baiting attacks, launched with the REFER method or through social
engineering, where the attacker receives a request from the target engineering, where the attacker receives a request from the target
and reoriginates it to a third party. These might not be prevented and reoriginates it to a third party. These might not be prevented
by only a signature over the From, To and Date, but could be by only a signature over the From, To and Date, but could be
prevented by securing a fingerprint for DTLS-SRTP. While this is a prevented by securing a fingerprint for DTLS-SRTP. While this is a
different form of impersonation than is commonly used for different form of impersonation than is commonly used for
robocalling, ultimately there is little purpose in establishing the robocalling, ultimately there is little purpose in establishing the
identity of the user that originated a SIP request if this assurance identity of the user that originated a SIP request if this assurance
is not coupled with a comparable assurance over the contents of the is not coupled with a comparable assurance over the contents of the
subsequent media communication. This signature also, per [RFC7258], subsequent media communication. This signature also reduces the
reduces the potential for passive monitoring attacks against the SIP potential for active eavesdropping attacks against the SIP media. In
media. In environments where DTLS-SRTP is unsupported, however, no environments where DTLS-SRTP is unsupported, however, no field is
field is signed and no protections are provided. signed and no protections are provided.
12.1.1. Protection of the To Header and Retargeting 12.1.1. Protection of the To Header and Retargeting
Armed with the original value of the To header field, the recipient Armed with the original value of the To header field, the recipient
of a request may be tempted compare it to their own identity in order of a request may be tempted compare it to their own identity in order
to determine whether or not the identity information in this call to determine whether or not the identity information in this call
might have been replayed. However, any request may be legitimately might have been replayed. However, any request may be legitimately
retargeted as well, and as a result legitimate requests may reach a retargeted as well, and as a result legitimate requests may reach a
SIP endpoint whose user is not identified by the URI designated in SIP endpoint whose user is not identified by the URI designated in
the To header field value. It is therefore difficult for any the To header field value. It is therefore difficult for any
skipping to change at page 37, line 41 skipping to change at page 38, line 37
13. IANA Considerations 13. IANA Considerations
This document contains a number of actions for IANA. This document contains a number of actions for IANA.
13.1. SIP Header Fields 13.1. SIP Header Fields
The Identity-Info header in the SIP Header Fields registry should be The Identity-Info header in the SIP Header Fields registry should be
marked as deprecated by [RFCThis]. marked as deprecated by [RFCThis].
Also, the Identity-Info header reserved the compact form "n" at its
time of registration. Please remove that compact form from the
registry. The Identity header however retains the compact form "y"
reserved by RFC4474.
13.2. SIP Response Codes 13.2. SIP Response Codes
The Reason phrase for the 436 response default reason phrase should The Reason phrase for the 436 response default reason phrase should
be changed from "Bad Identity-Info" to "Bad Identity Info" in the SIP be changed from "Bad Identity-Info" to "Bad Identity Info" in the SIP
Response Code registry. Response Code registry.
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
skipping to change at page 38, line 28 skipping to change at page 39, line 28
This IANA manages an Identity-Info Algorithm Parameter Values This IANA manages an Identity-Info Algorithm Parameter Values
registry which this specification deprecates. We request that the registry which this specification deprecates. We request that the
IANA delete this registry. Since the algorithms for signing IANA delete this registry. Since the algorithms for signing
PASSporTs are defined in [I-D.ietf-stir-passport] rather than in this PASSporTs are defined in [I-D.ietf-stir-passport] rather than in this
specification, there is no longer a need for an algorithm parameter specification, there is no longer a need for an algorithm parameter
registry for the Identity header field. registry for the Identity header field.
14. Acknowledgments 14. Acknowledgments
The authors would like to thank Syed Ali, Olle Jacobson, Dave The authors would like to thank Jim Schaad, Ning Zhang, Syed Ali,
Frankel, Robert Sparks, Dave Crocker, Stephen Kent, Brian Rosen, Alex Olle Jacobson, Dave Frankel, Robert Sparks, Dave Crocker, Stephen
Bobotek, Paul Kyzviat, Jonathan Lennox, Richard Shockey, Martin Kent, Brian Rosen, Alex Bobotek, Paul Kyzviat, Jonathan Lennox,
Dolly, Andrew Allen, Hadriel Kaplan, Sanjay Mishra, Anton Baskov, Richard Shockey, Martin Dolly, Andrew Allen, Hadriel Kaplan, Sanjay
Pierce Gorman, David Schwartz, Eric Burger, Alan Ford, Christer Mishra, Anton Baskov, Pierce Gorman, David Schwartz, Eric Burger,
Holmberg, Philippe Fouquart, Michael Hamer, Henning Schulzrinne, and Alan Ford, Christer Holmberg, Philippe Fouquart, Michael Hamer,
Richard Barnes for their comments. Henning Schulzrinne, and 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
skipping to change at page 39, line 19 skipping to change at page 40, line 19
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, "Personal Assertion Token Wendt, C. and J. Peterson, "Personal Assertion Token
(PASSporT)", draft-ietf-stir-passport-08 (work in (PASSporT)", draft-ietf-stir-passport-09 (work in
progress), September 2016. progress), October 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>.
[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,
skipping to change at page 40, line 21 skipping to change at page 41, 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-09 (work in progress), October 2016. certificates-10 (work in progress), October 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.
 End of changes. 32 change blocks. 
144 lines changed or deleted 172 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/