draft-ietf-stir-rfc4474bis-13.txt   draft-ietf-stir-rfc4474bis-14.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 2, 2017 E. Rescorla Expires: April 21, 2017 E. Rescorla
RTFM, Inc. RTFM, Inc.
C. Wendt C. Wendt
Comcast Comcast
September 29, 2016 October 18, 2016
Authenticated Identity Management in the Session Initiation Protocol Authenticated Identity Management in the Session Initiation Protocol
(SIP) (SIP)
draft-ietf-stir-rfc4474bis-13.txt draft-ietf-stir-rfc4474bis-14.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 2, 2017. This Internet-Draft will expire on April 21, 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 7, line 32 skipping to change at page 7, line 32
Fourth, if a PASSporT extension is in use, then the optional JSON Fourth, if a PASSporT extension is in use, then the optional JSON
key "ppt" MUST be present and have a value equivalent to the key "ppt" MUST be present and have a value equivalent to the
quoted value of the "ppt" parameter of the Identity header field. quoted value of the "ppt" parameter of the Identity header field.
An example of the PASSporT header JSON object without any extension An example of the PASSporT header JSON object without any extension
is: is:
{ "typ":"passport", { "typ":"passport",
"alg":"ES256", "alg":"ES256",
"x5u":"https://www.example.com/cert.pkx" } "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" 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"
skipping to change at page 8, line 20 skipping to change at page 8, line 20
[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. The authentication
service MUST NOT generate a PASSporT for a SIP request if the Date service MUST NOT generate a PASSporT for a SIP request if the Date
header is outside of its local policy for freshness (recommended header is outside of its local policy for freshness (recommended
sixty seconds). sixty seconds).
Fourth, if the request contains an SDP message body, and if that Fourth, if the request contains an SDP message body, and if that
SDP contains one or more "a=fingerprint" attributes, then the JSON SDP contains one or more "a=fingerprint" attributes, then the JSON
key "mky" MUST appear with the algorithm(s) and value(s) of the key "mky" MUST appear with the algorithm(s) and value(s) of the
fingerprint attributes (if they differ), following the format fingerprint attributes (if they differ), following the format
given in [I-D.ietf-stir-passport] Section 4.2.2. given in [I-D.ietf-stir-passport] Section 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
skipping to change at page 8, line 46 skipping to change at page 8, line 46
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
"dest" array may be populated with more than one value. This could "dest" array may be populated with more than one value. This could
for example occur when multiple "dest" identities are specified in a for example occur when multiple "dest" identities are specified in a
meshed conference. Defining how a SIP implementation would align meshed conference. Defining how a SIP implementation would align
multiple destination identities in PASSporT with such systems is left multiple destination identities in PASSporT with such systems is left
as a subject for future specification. as a subject for future specification.
After these two JSON objects, the header and the payload, have been After these two JSON objects, the header and the payload, have been
constructed and base64-encoded, they must each be hashed and signed constructed and base64-encoded, they must each be hashed and signed
per [I-D.ietf-stir-passport] Section 5. The header, payload and per [I-D.ietf-stir-passport] Section 6. The header, payload and
signature components comprise a full PASSporT object. The resulting signature components comprise a full PASSporT object. The resulting
PASSporT may be carried in SIP in either a full form, which includes PASSporT may be carried in SIP in either a full form, which includes
the header and payload as well as the signature, or a compact form the header and payload as well as the signature, or a compact form
which only carries the signature per [I-D.ietf-stir-passport] which only carries the signature per [I-D.ietf-stir-passport]
Section 6. The hashing and signing algorithm is specified by the Section 7. The hashing and signing algorithm is specified by the
'alg' parameter of the Identity header field and the mirrored "alg" 'alg' parameter of the Identity header field and the mirrored "alg"
parameter of PASSporT. All implementations of this specification parameter of PASSporT. All implementations of this specification
MUST support the required signing algorithms of PASSporT. At present MUST support the required signing algorithms of PASSporT. At present
there is one mandatory-to-support value for the 'alg' parameter: there is one mandatory-to-support value for the 'alg' parameter:
'ES256', as defined in [RFC7519], which connotes an ECDSA P-256 'ES256', as defined in [RFC7519], which connotes an ECDSA P-256
digital signature. digital signature.
4.1.1. Example Full and Compact Forms of PASSporT in Identity 4.1.1. Example Full and Compact Forms of PASSporT in Identity
As Appendix F of the JWS specification [RFC7515] notes, there are As Appendix F of the JWS specification [RFC7515] notes, there are
cases where "it is useful to integrity-protect content that is not cases where "it is useful to integrity-protect content that is not
itself contained in a JWS." Since the fields that make up the itself contained in a JWS." Since the fields that make up the
majority of the PASSporT header and payload have values replicated in majority of the PASSporT header and payload have values replicated in
the SIP request, the SIP usage of PASSporT may exclude the base64 the SIP request, the SIP usage of PASSporT may exclude the base64
encoded version of the header and payload JSON objects from the encoded version of the header and payload JSON objects from the
Identity header field and instead present a detached signature: what Identity header field and instead present a detached signature: what
PASSporT calls its compact form, see [I-D.ietf-stir-passport] PASSporT calls its compact form, see [I-D.ietf-stir-passport]
Section 6. Section 7.
When an authentication service constructs an Identity header, the When an authentication service constructs an Identity header, the
contents of the signed-identity-digest field MUST contain either a contents of the signed-identity-digest field MUST contain either a
full or compact PASSporT. Use of the compact form is RECOMMENDED in full or compact PASSporT. Use of the compact form is RECOMMENDED in
order to reduce message size, but note that extensions often require order to reduce message size, but note that extensions often require
the full form (see Section 9). the full form (see Section 9).
For example, a full form of PASSporT in an Identity header might look For example, a full form of PASSporT in an Identity header might look
as follows: as follows:
skipping to change at page 12, line 18 skipping to change at page 12, line 18
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 5. 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
form of PASSporT would thus generate and add to the request an form of PASSporT would thus generate and add to the request an
Identity header field of the following form: Identity header field of the following form:
Identity: ..rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpj \ Identity: ..rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpj \
lk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w; \ lk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w; \
skipping to change at page 15, line 10 skipping to change at page 15, line 10
service is using an alternative "ppt" format, it MUST add an service is using an alternative "ppt" format, it MUST add an
appropriate "ppt" parameter and follow the procedures associated with appropriate "ppt" parameter and follow the procedures associated with
that extension (see Section 9). After the Identity header field has that extension (see Section 9). After the Identity header field has
been added to the request, the authentication service MUST also add a been added to the request, the authentication service MUST also add a
"info" parameter to the Identity header field. The "info" parameter "info" parameter to the Identity header field. The "info" parameter
contains a URI from which the authentication service's credential can contains a URI from which the authentication service's credential can
be acquired; see Section 7.3 for more on credential acquisition. be acquired; see Section 7.3 for more on credential acquisition.
An authentication service MAY use the full form of the PASSporT in An authentication service MAY use the full form of the PASSporT in
the Identity header field. The presence of the full form is OPTIONAL the Identity header field. The presence of the full form is OPTIONAL
because the information carried in the baseline PASSporT object's because the information carried in the baseline PASSporT headers and
headers and claims is usually redundant with information already claims is usually redundant with information already carried
carried elsewhere in the SIP request. Using the compact form can elsewhere in the SIP request. Using the compact form can
significantly reduce SIP message size, especially when the PASSporT significantly reduce SIP message size, especially when the PASSporT
object contains media keys. The syntax of the compact form is given payload contains media keys. The syntax of the compact form is given
in [I-D.ietf-stir-passport] Section 6; essentially, it contains a in [I-D.ietf-stir-passport] Section 7; essentially, it contains only
base64 encoding of the JSON header and payload in the PASSporT the signature component of the PASSporT.
object.
Note that per the behavior specified in [I-D.ietf-stir-passport], use Note that per the behavior specified in [I-D.ietf-stir-passport], use
of the full form is mandatory when optional extensions are included. of the full form is mandatory when optional extensions are included.
See Section 9. See Section 9.
6.1.1. Handling Repairable Errors 6.1.1. Handling Repairable Errors
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
skipping to change at page 16, line 4 skipping to change at page 15, line 51
This document specifies a logical role for SIP entities called a This document specifies a logical role for SIP entities called a
verification service, or verifier. When a verifier receives a SIP verification service, or verifier. When a verifier receives a SIP
message containing one or more Identity header fields, it inspects message containing one or more Identity header fields, it inspects
the signature(s) to verify the identity of the originator of the the signature(s) to verify the identity of the originator of the
message. The results of a verification are provided as input to an message. The results of a verification are provided as input to an
authorization process that is outside the scope of this document. authorization process that is outside the scope of this document.
A SIP request may contain zero, one, or more Identity header fields. A SIP request may contain zero, one, or more Identity header fields.
A verification service performs the steps below on each Identity A verification service performs the steps below on each Identity
header field that appears in a request. If the verifier does not header field that appears in a request. If a verification service
support an Identity header field "ppt" parameter which is present, or cannot use any Identity header in a request, due to the absence of
if no Identity header field is present at all, and the presence of an Identity headers or unsupported "ppt" parameters, and the presence of
Identity header field is required by local policy (for example, based an Identity header field is required by local policy (for example,
on a per-sending-domain policy, or a per-sending-user policy), then a based on a per-sending-domain policy, or a per-sending-user policy),
428 'Use Identity Header' response MUST be sent in the backwards then a 428 'Use Identity Header' response MUST be sent in the
direction. For more on this and other verifier responses, see backwards direction. For more on this and other verifier responses,
Section 6.2.2. see Section 6.2.2.
In order to verify an Identity header field in a message, an entity In order to verify an Identity header field in a message, an entity
acting as a verifier MUST perform the following steps, in the order acting as a verifier MUST perform the following steps, in the order
here specified. Note that when an Identity header field contains a here specified. Note that when an Identity header field contains a
full form PASSporT object, the verifier MUST follow the additional full form PASSporT object, the verifier MUST follow the additional
procedures in Section 6.2.3. procedures in Section 6.2.3.
Step 1: Check for an Unsupported "ppt" Step 1: Check for an Unsupported "ppt"
The verifier MUST inspect any optional "ppt" parameter appearing in The verifier MUST inspect any optional "ppt" parameter appearing in
the Identity request. If no "ppt" parameter is present, then the the Identity header. If no "ppt" parameter is present, then the
verifier proceeds normally below. If a "ppt" parameter value is verifier proceeds normally below. If a "ppt" parameter value is
present, and the verifier does not support it, it MUST ignore the present, and the verifier does not support it, it MUST ignore the
Identity header field. If a supported "ppt" parameter value is Identity header field. If a supported "ppt" parameter value is
present, the verifier proceeds with Step 2, and will ultimately present, the verifier proceeds with Step 2, and will ultimately
follow the "ppt" variations described in Step 5. follow the "ppt" variations described in Step 5.
Step 2: Determine the Originator's Identity Step 2: Determine the Originator's Identity
In order to determine whether the signature for the identity field In order to determine whether the signature for the identity field
should be over the entire identity field URI or just a telephone should be over the entire identity field URI or just a telephone
skipping to change at page 17, line 4 skipping to change at page 16, line 49
The verifier must ensure that it possesses the proper keying material The verifier must ensure that it possesses the proper keying material
to validate the signature in the Identity header field, which usually to validate the signature in the Identity header field, which usually
involves dereferencing a URI in the "info" parameter of the Identity involves dereferencing a URI in the "info" parameter of the Identity
header field. See Section 7.2 for more information on these header field. See Section 7.2 for more information on these
procedures. If the verifier does not support the credential procedures. If the verifier does not support the credential
described in the "info" parameter, then it treats the credential for described in the "info" parameter, then it treats the credential for
this header field as unsupported. this header field as unsupported.
Step 4: Check the Freshness of Date Step 4: Check the Freshness of Date
The verifier furthermore ensures that the value of the Date header The verifier furthermore ensures that the value of the Date header
field of the request meets local policy for freshness (sixty seconds field of the request meets local policy for freshness (sixty seconds
is RECOMMENDED) and that it falls within the validity period of the is RECOMMENDED) and that it falls within the validity period of the
credential used to sign the Identity header field. For more on the credential used to sign the Identity header field. For more on the
attacks this prevents, see Section 12.1. If the full form of the attacks this prevents, see Section 12.1. If the full form of the
PASSporT is present, the verifier SHOULD compare the "iat" value in PASSporT is present, the verifier SHOULD compare the "iat" value in
the PASSporT to the Date header field value in the request. If the the PASSporT to the Date header field value in the request. If the
two are different, and the "iat" value is later but within two are different, and the "iat" value differs from the Date header
verification service policy for freshness, the verification service field value but remains within verification service policy for
SHOULD perform the computation required by Step 5 using the "iat" freshness, the verification service SHOULD perform the computation
value instead of the Date header field value. required by Step 5 using the "iat" value instead of the Date header
field value.
Step 5: Validate the Signature Step 5: Validate the Signature
The verifier MUST validate the signature in the Identity header field The verifier MUST validate the signature in the Identity header field
over the PASSporT object. For baseline PASSporT objects (with no over the PASSporT object. For baseline PASSporT objects (with no
Identity header field "ppt" parameter) the verifier MUST follow the Identity header field "ppt" parameter) the verifier MUST follow the
procedures for generating the signature over a PASSporT object procedures for generating the signature over a PASSporT object
described in Section 4. If a "ppt" parameter is present (and per described in Section 4. If a "ppt" parameter is present (and per
Step 1, is supported), the verifier follows the procedures for that Step 1, is supported), the verifier follows the procedures for that
"ppt" (see Section 9). If a verifier determines that the that the "ppt" (see Section 9). If a verifier determines that the signature
signature in the Identity does not correspond to the reconstructed in the Identity does not correspond to the reconstructed signed-
signed-identity-digest, then the Identity header field should be identity-digest, then the Identity header field should be considered
considered invalid. invalid.
6.2.1. Authorization of Requests 6.2.1. Authorization of Requests
The verification of an Identity header field does not entail any The verification of an Identity header field does not entail any
particular treatment of the request. The handling of the message particular treatment of the request. The handling of the message
after the verification process depends on how the verification after the verification process depends on how the verification
service is implemented and on local policy. This specification does service is implemented and on local policy. This specification does
not propose any authorization policy for user agents or proxy servers not propose any authorization policy for user agents or proxy servers
to follow based on the presence of a valid Identity header field, the to follow based on the presence of a valid Identity header field, the
presence of an invalid Identity header field, or the absence of an presence of an invalid Identity header field, or the absence of an
skipping to change at page 19, line 25 skipping to change at page 19, line 25
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 full form of a PASSporT has a value older than the local policy the full form of a PASSporT has a value older than the local policy
for freshness permits. for freshness permits.
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 7.3. The verification service can [I-D.ietf-stir-passport] Section 8.3. Furthermore, the verification
extract from the "orig" element" a canonical telephone number created service can extract from the "orig" and "dest" elements of the
by the authentication service, as well as an "iat" claim PASSporT full form the canonical telephone numbers created by the
corresponding to the Date header field that the authentication authentication service, as well as an "iat" claim corresponding to
service used. These may be used to debug canonicalization problems, the Date header field that the authentication service used. These
or to avoid unnecessary signature breakage caused by intermediaries may be used to debug canonicalization problems, or to avoid
that alter the Date header field value in transit. unnecessary signature breakage caused by intermediaries that alter
the SIP header field values in transit.
As an optimization, when the full form is present, the verification As an optimization, when the full form is present, the verification
service MAY compute its own canonicalization of an originating service MAY compute its own canonicalization of an originating
telephone number and compare it to the values in the "orig" element telephone number and compare it to the values in the "orig" element
of PASSporT before performing any cryptographic functions in order to of PASSporT before performing any cryptographic functions in order to
ascertain whether or not the two ends agree on the canonical number ascertain whether or not the two ends agree on the canonical number
form. form.
7. Credentials 7. Credentials
skipping to change at page 24, line 15 skipping to change at page 24, line 15
trusted environments, the P-Asserted-Identity header field is used in trusted environments, the P-Asserted-Identity header field is used in
lieu of the From header field to convey the address-of-record or lieu of the From header field to convey the address-of-record or
telephone number of the originator of a request; where it does, local telephone number of the originator of a request; where it does, local
policy might therefore dictate that the canonical identity derives policy might therefore dictate that the canonical identity derives
from the P-Asserted-Identity header field rather than the From header from the P-Asserted-Identity header field rather than the From header
field. field.
Ultimately, in any case where local policy canonicalizes the identity Ultimately, in any case where local policy canonicalizes the identity
into a form different from how it appears in the From header field, into a form different from how it appears in the From header field,
the use of the 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 could itself RECOMMENDED, but because the "orig" claim of PASSporT itself could
could then divulge information about users or networks, implementers then divulge information about users or networks, implementers should
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 It may not be trivial to tell if a given URI contains a telephone
number. In order to determine whether or not the user portion of a number. In order to determine whether or not the user portion of a
SIP URI is a telephone number, authentication services and SIP URI is a telephone number, authentication services and
verification services MUST perform the following procedure on any SIP verification services MUST perform the following procedure on any SIP
URI they inspect which contains a numeric user part. Note that the URI they inspect which contains a numeric user part. Note that the
same procedures are followed for creating the canonical form of URIs same procedures are followed for creating the canonical form of URIs
found in the From header field as they are in the To header field or found in the From header field as they are in the To header field or
the P-Asserted-Identity header field. the P-Asserted-Identity header field.
First, implementations must look for obvious indications that the First, implementations must look for obvious indications that the
user-portion of the URI constitutes a telephone number. Telephone user-portion of the URI constitutes a telephone number. Telephone
numbers most commonly appear in SIP header field values in the numbers most commonly appear in SIP header field values in the
username portion of a SIP URI (e.g., username portion of a SIP URI (e.g.,
'sip:+17005551008@chicago.example.com;user=phone'). The user part of 'sip:+17005551008@chicago.example.com;user=phone'). The user part of
that URI conforms to the syntax of the TEL URI scheme (RFC 3966 that URI conforms to the syntax of the TEL URI scheme (RFC 3966
[RFC3966]). It is also possible for a TEL URI to appear in the SIP [RFC3966]). It is also possible for a TEL URI to appear in the SIP
To or From header field outside the context of a SIP or SIPS URI To or From header field outside the context of a SIP or SIPS URI
(e.g., 'tel:+17005551008'). Thus, in some environments, numbers will (e.g., 'tel:+17005551008'). Thus, in standards-compliant
be explicitly labeled by the use of TEL URIs or the 'user=phone' environments, numbers will be explicitly labeled by the use of TEL
parameter, or implicitly by the presence of the '+' indicator at the URIs or the 'user=phone' parameter. Outside of those environments,
start of the user-portion. Absent these indications, if there are implementations may infer that the user part is a telephone number
numbers present in the user-portion, implementations may also detect 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 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. Whatever the
number has been detected, implementations should follow the process, once a telephone number has been detected, implementations
procedures in Section 8.3. SHOULD follow the procedures in Section 8.3.
If the URI field does not contain a telephone number, or if the If the URI field does not contain a telephone number, or if the
result of the canonicalization of the From header field value does result of the canonicalization of the From header field value does
not form a valid E.164 telephone number, the authentication service not form a valid E.164 telephone number, the authentication service
and/or verification service SHOULD treat the entire URI as a SIP URI, and/or verification service SHOULD treat the entire URI as a SIP URI,
and apply the procedures in Section 8.5. These URI normalization and apply the procedures in Section 8.5. These URI normalization
procedures are invoked to canonicalize the URI before it is included procedures are invoked to canonicalize the URI before it is included
in a PASSporT object in, for example, a "uri" claim. See Section 8.5 in a PASSporT object in, for example, a "uri" claim. See Section 8.5
for that behavior. for that behavior.
skipping to change at page 25, line 34 skipping to change at page 25, line 34
[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, it must Once an implementation has identified a telephone number, it must
construct a number string. That requires performing the following construct a number string. That requires performing the 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 "#" or "*" keys used in some special service numbers (typically,
(typically, these will appear only in the To header field value). these will appear only in the To header field value). This MUST
This MUST result in an ASCII string limited to "#", "*" and digits result in an ASCII string limited to "#", "*" and digits without
without whitespace or visual separators. 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
not, implementations SHOULD convert the number into E.164 format, not, implementations SHOULD convert the number into E.164 format,
adding a country code if necessary; this may involve transforming adding a country code if necessary; this may involve transforming
the number from a dial string (see [RFC3966]), removing any the number from a dial string (see [RFC3966]), removing any
national or international dialing prefixes or performing similar national or international dialing prefixes or performing similar
procedures. It is only in the case that an implementation cannot procedures. It is only in the case that an implementation cannot
determine how to convert the number to a globally-routable format determine how to convert the number to a globally-routable format
that this step may be skipped. This will be the case, for that this step may be skipped. This will be the case, for
skipping to change at page 26, line 21 skipping to change at page 26, line 21
region code digits; another domain might have prefixed usernames region code digits; another domain might have prefixed usernames
with trunk-routing codes, in which case the canonicalization will with trunk-routing codes, in which case the canonicalization will
need to remove the prefix. This specification cannot anticipate need to remove the prefix. This specification cannot anticipate
all of the potential transformations that might be useful. all of the potential transformations that might be useful.
The resulting canonical number string will be used as input to the The resulting canonical number string will be used as input to the
hash calculation during signing and verifying processes. hash calculation during signing and verifying processes.
The ABNF of this number string is: The ABNF of this number string is:
tn-spec = [ "#" / "*" ] 1*DIGIT tn-spec = 1*tn-char
tn-char = "#" / "*" / DIGIT
The resulting number string is used in the construction of the The resulting number string is used in the construction of the
telephone number field(s) in a PASSporT object. telephone number field(s) in a PASSporT object.
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.
skipping to change at page 28, line 31 skipping to change at page 28, line 31
component. A more exact definition is left to future specifications. component. A more exact definition is left to future specifications.
9. Extensibility 9. Extensibility
As future requirements may warrant increasing the scope of the As future requirements may warrant increasing the scope of the
Identity mechanism, this specification specifies an optional "ppt" Identity mechanism, this specification specifies an optional "ppt"
parameter of the Identity header field, which mirrors the "ppt" parameter of the Identity header field, which mirrors the "ppt"
header in PASSporT. The "ppt" parameter value MUST consist of a header in PASSporT. The "ppt" parameter value MUST consist of a
token containing an extension specification, which denotes an token containing an extension specification, which denotes an
extended set of one or more signed claims per the type extensibility extended set of one or more signed claims per the type extensibility
mechanism specified in [I-D.ietf-stir-passport] Section 7. Note that mechanism specified in [I-D.ietf-stir-passport] Section 8. Note that
per the guidance in that section, "ppt" is used only to enforce a per the guidance in that section, "ppt" is used only to enforce a
mandatory extension: optional claims may be added to any PASSporT mandatory extension: optional claims may be added to any PASSporT
object without requiring the use of "ppt", but the compact form of object without requiring the use of "ppt", but the compact form of
PASSporT MUST NOT be used when optional claims are present in the PASSporT MUST NOT be used when optional claims are present in the
PASSporT payload. PASSporT payload.
The potential for extensions is one the primary motivations for The potential for extensions is one the primary motivations for
allowing the presence of multiple Identity header fields in the same allowing the presence of multiple Identity header fields in the same
SIP request. It is envisioned that future extensions might allow for SIP request. It is envisioned that future extensions might allow for
alternate information to be signed, or to explicitly allow different alternate information to be signed, or to explicitly allow different
skipping to change at page 39, line 18 skipping to change at page 39, line 18
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, "Personal Assertion Token
draft-ietf-stir-passport-07 (work in progress), September (PASSporT)", draft-ietf-stir-passport-08 (work in
2016. progress), September 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 40, line 21
[I-D.ietf-iri-comparison] [I-D.ietf-iri-comparison]
Masinter, L. and M. D&#258;&#378;rst, "Comparison, Masinter, L. and M. D&#258;&#378;rst, "Comparison,
Equivalence and Canonicalization of Internationalized Equivalence and Canonicalization of Internationalized
Resource Identifiers", draft-ietf-iri-comparison-02 (work Resource Identifiers", draft-ietf-iri-comparison-02 (work
in progress), October 2012. in progress), October 2012.
[I-D.ietf-stir-certificates] [I-D.ietf-stir-certificates]
Peterson, J. and S. Turner, "Secure Telephone Identity Peterson, J. and S. Turner, "Secure Telephone Identity
Credentials: Certificates", draft-ietf-stir- Credentials: Certificates", draft-ietf-stir-
certificates-08 (work in progress), September 2016. certificates-09 (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. 26 change blocks. 
62 lines changed or deleted 67 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/