draft-ietf-stir-rfc4474bis-15.txt   draft-ietf-stir-rfc4474bis-16.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: May 4, 2017 E. Rescorla Expires: August 13, 2017 E. Rescorla
RTFM, Inc. RTFM, Inc.
C. Wendt C. Wendt
Comcast Comcast
October 31, 2016 February 9, 2017
Authenticated Identity Management in the Session Initiation Protocol Authenticated Identity Management in the Session Initiation Protocol
(SIP) (SIP)
draft-ietf-stir-rfc4474bis-15.txt draft-ietf-stir-rfc4474bis-16.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 May 4, 2017. This Internet-Draft will expire on August 13, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 30 skipping to change at page 2, line 30
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 . . . . . . . . . . . . . . . . . . . . 10 5. Example of Operations . . . . . . . . . . . . . . . . . . . . 10
5.1. Example Identity Header Construction . . . . . . . . . . 11 5.1. Example Identity Header Construction . . . . . . . . . . 11
6. Signature Generation and Validation . . . . . . . . . . . . . 13 6. Signature Generation and Validation . . . . . . . . . . . . . 13
6.1. Authentication Service Behavior . . . . . . . . . . . . . 13 6.1. Authentication Service Behavior . . . . . . . . . . . . . 13
6.1.1. Handling Repairable Errors . . . . . . . . . . . . . 15 6.1.1. Handling Repairable Errors . . . . . . . . . . . . . 15
6.2. Verifier Behavior . . . . . . . . . . . . . . . . . . . . 16 6.2. Verifier Behavior . . . . . . . . . . . . . . . . . . . . 16
6.2.1. Authorization of Requests . . . . . . . . . . . . . . 17 6.2.1. Authorization of Requests . . . . . . . . . . . . . . 18
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 Retried Requests . . . . . . . . . . . . . . 20
7. Credentials . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.2.4. Handling the full form of PASSporT . . . . . . . . . 20
7.1. Credential Use by the Authentication Service . . . . . . 20 7. Credentials . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Credential Use by the Authentication Service . . . . . . 21
7.2. Credential Use by the Verification Service . . . . . . . 22 7.2. Credential Use by the Verification Service . . . . . . . 22
7.3. 'info' parameter URIs . . . . . . . . . . . . . . . . . . 22 7.3. 'info' parameter URIs . . . . . . . . . . . . . . . . . . 23
7.4. Credential System Requirements . . . . . . . . . . . . . 23 7.4. Credential System Requirements . . . . . . . . . . . . . 23
8. Identity Types . . . . . . . . . . . . . . . . . . . . . . . 24 8. Identity Types . . . . . . . . . . . . . . . . . . . . . . . 25
8.1. Differentiating Telephone Numbers from URIs . . . . . . . 25 8.1. Differentiating Telephone Numbers from URIs . . . . . . . 25
8.2. Authority for Telephone Numbers . . . . . . . . . . . . . 26 8.2. Authority for Telephone Numbers . . . . . . . . . . . . . 26
8.3. Telephone Number Canonicalization Procedures . . . . . . 26 8.3. Telephone Number Canonicalization Procedures . . . . . . 26
8.4. Authority for Domain Names . . . . . . . . . . . . . . . 27 8.4. Authority for Domain Names . . . . . . . . . . . . . . . 27
8.5. URI Normalization . . . . . . . . . . . . . . . . . . . . 28 8.5. URI Normalization . . . . . . . . . . . . . . . . . . . . 29
9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 29 9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 30
10. Backwards Compatibility with RFC4474 . . . . . . . . . . . . 30 10. Backwards Compatibility with RFC4474 . . . . . . . . . . . . 30
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 30 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 31
12. Security Considerations . . . . . . . . . . . . . . . . . . . 32 12. Security Considerations . . . . . . . . . . . . . . . . . . . 33
12.1. Protected Request Fields . . . . . . . . . . . . . . . . 32 12.1. Protected Request Fields . . . . . . . . . . . . . . . . 33
12.1.1. Protection of the To Header and Retargeting . . . . 34 12.1.1. Protection of the To Header and Retargeting . . . . 35
12.2. Unprotected Request Fields . . . . . . . . . . . . . . . 35 12.2. Unprotected Request Fields . . . . . . . . . . . . . . . 35
12.3. Malicious Removal of Identity Headers . . . . . . . . . 35 12.3. Malicious Removal of Identity Headers . . . . . . . . . 36
12.4. Securing the Connection to the Authentication Service . 36 12.4. Securing the Connection to the Authentication Service . 36
12.5. Authorization and Transitional Strategies . . . . . . . 37 12.5. Authorization and Transitional Strategies . . . . . . . 37
12.6. Display-Names and Identity . . . . . . . . . . . . . . . 38 12.6. Display-Names and Identity . . . . . . . . . . . . . . . 38
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
13.1. SIP Header Fields . . . . . . . . . . . . . . . . . . . 38 13.1. SIP Header Fields . . . . . . . . . . . . . . . . . . . 39
13.2. SIP Response Codes . . . . . . . . . . . . . . . . . . . 38 13.2. SIP Response Codes . . . . . . . . . . . . . . . . . . . 39
13.3. Identity-Info Parameters . . . . . . . . . . . . . . . . 39 13.3. Identity-Info Parameters . . . . . . . . . . . . . . . . 39
13.4. Identity-Info Algorithm Parameter Values . . . . . . . . 39 13.4. Identity-Info Algorithm Parameter Values . . . . . . . . 40
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40
15. Changes from RFC4474 . . . . . . . . . . . . . . . . . . . . 39 15. Changes from RFC4474 . . . . . . . . . . . . . . . . . . . . 40
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
16.1. Normative References . . . . . . . . . . . . . . . . . . 40 16.1. Normative References . . . . . . . . . . . . . . . . . . 41
16.2. Informative References . . . . . . . . . . . . . . . . . 41 16.2. Informative References . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
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.
[RFC3261] specifies several places within a SIP request where users [RFC3261] specifies several places within a SIP request where users
can express an identity for themselves, most prominently the user- can express an identity for themselves, most prominently the user-
populated From header field. However, the recipient of a SIP request populated From header field. However, in the absence of some sort of
has no way to verify that the From header field has been populated cryptographic authentication mechanism, the recipient of a SIP
appropriately, in the absence of some sort of cryptographic request has no way to verify that the From header field has been
authentication mechanism. This leaves SIP vulnerable to a category populated appropriately. This leaves SIP vulnerable to a category of
of abuses, including impersonation attacks that facilitate or enable abuses, including impersonation attacks that facilitate or enable
robocalling, voicemail hacking, swatting, and related problems as robocalling, voicemail hacking, swatting, and related problems as
described in [RFC7340]. Ideally, a cryptographic approach to described in [RFC7340]. Ideally, a cryptographic approach to
identity can provide a much stronger and less spoofable assurance of identity can provide a much stronger and assurance of identity than
identity than the Caller ID services that the telephone network the Caller ID services that the telephone network provides today, and
provides today. one less vulnerable to spoofing.
[RFC3261] encourages user agents (UAs) to implement a number of [RFC3261] encourages user agents (UAs) to implement a number of
potential authentication mechanisms, including Digest authentication, potential authentication mechanisms, including Digest authentication,
Transport Layer Security (TLS), and S/MIME (implementations may Transport Layer Security (TLS), and S/MIME (implementations may
support other security schemes as well). However, few SIP user support other security schemes as well). However, few SIP user
agents today support the end-user certificates necessary to agents today support the end-user certificates necessary to
authenticate themselves (via S/MIME, for example), and for its part authenticate themselves (via S/MIME, for example), and for its part
Digest authentication is limited by the fact that the originator and Digest authentication is limited by the fact that the originator and
destination must share a prearranged secret. Practically speaking, destination must share a prearranged secret. Practically speaking,
originating user agents need to be able to securely communicate their originating user agents need to be able to securely communicate their
skipping to change at page 4, line 47 skipping to change at page 4, line 49
SIP entity that validates Identity headers in a SIP request. SIP entity that validates Identity headers in a SIP request.
3. Architectural Overview 3. Architectural Overview
The identity architecture for SIP defined in this specification The identity architecture for SIP defined in this specification
depends on a logical "authentication service" which validates depends on a logical "authentication service" which validates
outgoing requests. An authentication service may be implemented outgoing requests. An authentication service may be implemented
either as part of a user agent or as a proxy server; typically, it is either as part of a user agent or as a proxy server; typically, it is
a component of a network intermediary like a proxy to which a component of a network intermediary like a proxy to which
originating user agents send unsigned requests. Once the originator originating user agents send unsigned requests. Once the originator
of the message has been authenticated, through means entirely up to of the message has been authenticated, through pre-arranged means
the authentication service, the authentication service then creates with the authentication service, the authentication service then
and adds an Identity header field to the request. This requires creates and adds an Identity header field to the request. This
computing cryptographic information, including a digital signature requires computing cryptographic information, including a digital
over some components of messages, that lets other SIP entities verify signature over some components of messages, that lets other SIP
that the sending user has been authenticated and its claim of a entities verify that the sending user has been authenticated and its
particular identity has been authorized. These "verification claim of a particular identity has been authorized. These
services" validate the signature and enable policy decisions to be "verification services" validate the signature and enable policy
made based on the results of the validation. decisions to be made based on the results of the validation.
Policy decisions made after validation depend heavily on the Policy decisions made after validation depend heavily on the
verification service's trust for the credentials that the verification service's trust for the credentials that the
authentication service uses to sign requests. As robocalling, authentication service uses to sign requests. As robocalling,
voicemail hacking, and swatting usually involve impersonation of voicemail hacking, and swatting usually involve impersonation of
telephone numbers, credentials that will be trusted by relying telephone numbers, credentials that will be trusted by relying
parties to sign for telephone numbers are a key component of the parties to sign for telephone numbers are a key component of the
architecture. Authority over telephone numbers is however, not so architecture. Authority over telephone numbers is, however, not as
easy to establish on the Internet as authority over traditional easy to establish on the Internet as authority over traditional
domain names. This document assumes the existence of credentials for domain names. This document assumes the existence of credentials for
establishing authority over telephone numbers, for cases where the establishing authority over telephone numbers, for cases where the
telephone number is the identity of the user, but this document does telephone number is the identity of the user, but this document does
not mandate or specify a credential system. not mandate or specify a credential system;
[I-D.ietf-stir-certificates] describes a credential system compatible [I-D.ietf-stir-certificates] describes a credential system compatible
with this architecture. with this architecture.
Although addressing the vulnerabilities in the STIR problem statement Although addressing the vulnerabilities in the STIR problem statement
and threat model mostly requires dealing with telephone number as and threat model mostly requires dealing with telephone number as
identities, SIP must also handle signing for SIP URIs as identities. identities, SIP must also handle signing for SIP URIs as identities.
This is typically easier to deal with, as these identities are issued This is typically easier to deal with, as these identities are issued
to users by authorities over Internet domains. When a new user by organizations that have authority over Internet domains. When a
becomes associated with example.com, for example, the administrator new user becomes associated with example.com, for example, the
of the SIP service for that domain can issue them an identity in that administrator of the SIP service for that domain can issue them an
namespace, such as sip:alice@example.com. Alice may then send identity in that namespace, such as sip:alice@example.com. Alice may
REGISTER requests to example.com that make her user agents eligible then send REGISTER requests to example.com that make her user agents
to receive requests for sip:alice@example.com. In other cases, Alice eligible to receive requests for sip:alice@example.com. In other
may herself be the owner of her own domain, and may issue herself cases, Alice may herself be the owner of her own domain, and may
identities as she chooses. But ultimately, it is the controller of issue herself identities as she chooses. But ultimately, it is the
the SIP service at example.com that must be responsible for controller of the SIP service at example.com that must be responsible
authorizing the use of names in the example.com domain. Therefore, for authorizing the use of names in the example.com domain.
for the purposes of baseline SIP, the necessary credentials needed to Therefore, for the purposes of SIP as defined in [RFC3261], the
prove a user is authorized to use a particular From header field must necessary credentials needed to prove a user is authorized to use a
ultimately derive from the domain owner: either a user agent gives particular From header field must ultimately derive from the domain
requests to the domain name owner in order for them to be signed by owner: either a user agent gives requests to the domain name owner in
the domain owner's credentials, or the user agent must possess order for them to be signed by the domain owner's credentials, or the
credentials that prove in some fashion that the domain owner has user agent must possess credentials that prove that the domain owner
given the user agent the right to a name. has 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, which is special encoding of a JSON [RFC7159] object format, which is special encoding of a JSON [RFC7159] object
comprising values derived from certain header field values in the SIP comprising values derived from certain header field values in the SIP
request. The authentication service computes a signature over those request. The authentication service computes a signature over those
JSON elements as PASSporT specifies. An encoding of the resulting JSON elements as PASSporT specifies. An encoding of the resulting
PASSporT is then placed in the SIP Identity header field. In order PASSporT is then placed in the SIP Identity header field. In order
to assist in the validation of the Identity header field, this to assist in the validation of the Identity header field, this
skipping to change at page 6, line 29 skipping to change at page 6, line 32
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 = 1*(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 / "/" / "+"
In addition to the "info" parameter, and the "alg" parameter In addition to the "info" parameter, and the "alg" parameter
previously defined in RFC4474, this specification defines the previously defined in RFC4474, this specification defines the
optional "ppt" parameter. The 'absoluteURI' portion of ident-info- optional "ppt" parameter (PASSporT Type). The 'absoluteURI' portion
uri MUST contain a URI; see Section 7.3 for more on choosing how to of ident-info-uri MUST contain a URI; see Section 7.3 for more on
advertise credentials through this parameter. choosing how to advertise credentials through this parameter.
The signed-identity-digest contains a base64 encoding of a PASSporT The signed-identity-digest contains a base64 encoding of a PASSporT
[I-D.ietf-stir-passport], which secures the request with a signature [I-D.ietf-stir-passport], which secures the request with a signature
that PASSporT generates over the JSON header and payload objects; that PASSporT generates over the JSON header and payload objects;
some of those header and claim element values will mirror values of some of those header and claim element values will mirror values of
the SIP request. the SIP request.
4.1. PASSporT Construction 4.1. PASSporT Construction
For SIP implementations to populate the PASSporT header JSON object For SIP implementations to populate the PASSporT header JSON object
skipping to change at page 8, line 38 skipping to change at page 8, line 44
{ "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 of this document.
The "orig" and "dest" arrays may contain identifiers of heterogeneous The "orig" and "dest" arrays may contain identifiers of heterogeneous
type; for example, the "orig" array might contain a "tn" claim, while type; for example, the "orig" array might contain a "tn" claim, while
the "dest" contains a "uri" claim. Also note that in some cases, the the "dest" contains a "uri" claim. Also note that in some cases, the
"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.
skipping to change at page 9, line 35 skipping to change at page 9, line 41
PASSporT calls its compact form, see [I-D.ietf-stir-passport] PASSporT calls its compact form, see [I-D.ietf-stir-passport]
Section 7. 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 (backslashes shown for line folding only):
Identity: eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1I \ Identity: eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1I \
joiaHR0cHM6Ly9jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJ \ joiaHR0cHM6Ly9jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJ \
kZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdC \ kZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdC \
I6IjE0NDMyMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0.r \ I6IjE0NDMyMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0.r \
q3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYs \ q3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYs \
ojNCpTzO3QfPOlckGaS6hEck7w;info=<https://biloxi.example.org \ ojNCpTzO3QfPOlckGaS6hEck7w;info=<https://biloxi.example.org \
/biloxi.cert> /biloxi.cert>
The compact form of the same PASSporT object would appear in the The compact form of the same PASSporT object would appear in the
Identity header as: Identity header as:
Identity: ..rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qj \ Identity: ..rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qj \
pjlk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w; \ pjlk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w; \
info=<https://biloxi.example.org/biloxi.cert> info=<https://biloxi.example.org/biloxi.cert>
5. Example of Operations 5. Example of Operations
This section provides an informative (non-normative) high-level This section provides an informative (non-normative) high-level
skipping to change at page 10, line 12 skipping to change at page 10, line 18
pjlk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w; \ pjlk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w; \
info=<https://biloxi.example.org/biloxi.cert> info=<https://biloxi.example.org/biloxi.cert>
5. Example of Operations 5. Example of Operations
This section provides an informative (non-normative) high-level This section provides an informative (non-normative) high-level
example of the operation of the mechanisms described in this example of the operation of the mechanisms described in this
document. document.
Imagine a case where Bob, who has the home proxy of example.com and Imagine a case where Bob, who has the home proxy of example.com and
the address-of-record sip:12155551212@example.com, wants to the address-of-record sip:12155551212@example.com;user=phone, wants
communicate with Alice at sip:alice@example.org. They have no prior to communicate with Alice at sip:alice@example.org. They have no
relationship, and Alice implements best practices to prevent prior relationship, and Alice implements best practices to prevent
impersonation attacks. impersonation attacks.
Bob's user agent generates an INVITE and places his address-of-record Bob's user agent generates an INVITE and places his address-of-record
in the From header field of the request. He then sends an INVITE to in the From header field of the request. He then sends an INVITE to
an authentication service proxy for his domain. an authentication service proxy for his domain.
............................ .............................. ............................ ..............................
. . . . . . . .
. +-------+ . . +-------+ . . +-------+ . . +-------+ .
. Signs for | | . Signed . | | . . Signs for | | . Signed . | | .
skipping to change at page 12, line 8 skipping to change at page 12, line 8
unsuccessful, some other treatment could be applied by the receiving unsuccessful, some other treatment could be applied by the receiving
domain or Alice's user agent. domain or Alice's user agent.
5.1. Example Identity Header Construction 5.1. Example Identity Header Construction
For the following SIP request: For the following SIP request:
INVITE sip:bob@biloxi.example.org SIP/2.0 INVITE sip:bob@biloxi.example.org SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
To: Alice <sip:alice@example.com> To: Alice <sip:alice@example.com>
From: Bob <sip:12155551212@example.com>;tag=1928301774> From: Bob <sip:12155551212@example.com;user=phone>;tag=1928301774>
Call-ID: a84b4c76e66710 Call-ID: a84b4c76e66710
CSeq: 314159 INVITE CSeq: 314159 INVITE
Max-Forwards: 70 Max-Forwards: 70
Date: Fri, 25 Sep 2015 19:12:25 GMT Date: Fri, 25 Sep 2015 19:12:25 GMT
Contact: <sip:12155551212gateway.example.com> Contact: <sip:12155551212gateway.example.com>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 147 Content-Length: 147
v=0 v=0
o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com
s=Session SDP s=Session SDP
c=IN IP4 pc33.atlanta.example.com c=IN IP4 pc33.atlanta.example.com
t=0 0 t=0 0
m=audio 49172 RTP/AVP 0 m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
An authentication service will create a corresponding PASSporT An authentication service will create a corresponding PASSporT
object. The properly-serialized PASSporT header and payload JSON object. The properly-serialized PASSporT header and payload JSON
skipping to change at page 15, line 51 skipping to change at page 15, line 51
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
the backwards direction, such as a 438 indicating a verification the backwards direction, such as a 438 indicating a verification
failure. If the authentication service did not originally send the failure. If the authentication service did not originally send the
full form of the PASSporT object in the Identity header field, it full form of the PASSporT object in the Identity header field, it
SHOULD retry the request with the full form after receiving a 438 SHOULD retry the request with the full form after receiving a 438
response; however implementations SHOULD NOT retry the request more response; however implementations SHOULD NOT retry the request more
than once. The information in the full form is useful on the than once. Authentication services implemented at proxy servers
verification side for debugging errors, and there are some known would retry such a request as a ssequential for, by re-processing the
causes of verification failures (such as the Date header field value destination as a new target and handling it serially as described in
changing in transit, see Section 12.1 for more information) that can Section 16.6 of [RFC3261].
be resolved by the inclusion of the full form of PASSporT.
The information in the full form is useful on the verification side
for debugging errors, and there are some known causes of verification
failures (such as the Date header field value changing in transit,
see Section 12.1 for more information) that can be resolved by the
inclusion of the full form of PASSporT.
Finally, the authentication service forwards the message normally. Finally, the authentication service forwards the message normally.
6.2. Verifier Behavior 6.2. Verifier Behavior
This document specifies a logical role for SIP entities called a This document specifies a logical role for SIP entities called a
verification service, or verifier. When a verifier receives a SIP verification service, or verifier. When a verifier receives a SIP
message containing one or more Identity header fields, it inspects message containing one or more Identity header fields, it inspects
the signature(s) to verify the identity of the originator of the the signature(s) to verify the identity of the originator of the
message. The results of a verification are provided as input to an message. The results of a verification are provided as input to an
skipping to change at page 16, line 35 skipping to change at page 16, line 40
an Identity header field is required by local policy (for example, an Identity header field is required by local policy (for example,
based on a per-sending-domain policy, or a per-sending-user policy), based on a per-sending-domain policy, or a per-sending-user policy),
then a 428 'Use Identity Header' response MUST be sent in the then a 428 'Use Identity Header' response MUST be sent in the
backwards direction. For more on this and other verifier responses, backwards direction. For more on this and other verifier responses,
see 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.4.
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 header. 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.
skipping to change at page 17, line 11 skipping to change at page 17, line 17
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
number, the verification service MUST follow the process described in number, the verification service MUST follow the process described in
Section 8.1. That section will either lead to the telephone number Section 8.1. That section will either lead to the telephone number
canonicalization procedures in Section 8.3 for telephone numbers, or canonicalization procedures in Section 8.3 for telephone numbers, or
to the URI normalization procedures described in Section 8.5 for to the URI normalization procedures described in Section 8.5 for
domain names. domain names.
Step 3: Identify Credential for Validation Step 3: Identify Credential for Validation
The verifier must ensure that it possesses the proper keying material The verifier must ensure that it has access to the proper keying
to validate the signature in the Identity header field, which usually material to validate the signature in the Identity header field,
involves dereferencing a URI in the "info" parameter of the Identity which usually involves dereferencing a URI in the "info" parameter of
header field. See Section 7.2 for more information on these the Identity header field. See Section 7.2 for more information on
procedures. If the verifier does not support the credential these 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
skipping to change at page 18, line 38 skipping to change at page 18, line 44
specific to the Identity header field and its original mechanism. specific to the Identity header field and its original mechanism.
These status codes are retained in this specification, with some These status codes are retained in this specification, with some
slight modifications. Also, this specification details responding slight modifications. Also, this specification details responding
with 403 when a stale Date header field value is received. with 403 when a stale Date header field value is received.
A 428 response will be sent (per Section 6.2) when an Identity header A 428 response will be sent (per Section 6.2) when an Identity header
field is required, but no Identity header field without a "ppt" field is required, but no Identity header field without a "ppt"
parameter, or with a supported "ppt" value, has been received. In parameter, or with a supported "ppt" value, has been received. In
the case where one or more Identity header fields with unsupported the case where one or more Identity header fields with unsupported
"ppt" values have been received, then a verification service may send "ppt" values have been received, then a verification service may send
a 428 with the special reason phrase "Use Supported PASSporT Format". a 428 with a human-readable reason phrase like "Use Supported
Note however that this specification gives no guidance on how a PASSporT Format". Note however that this specification gives no
verification service might decide to require an Identity header field guidance on how a verification service might decide to require an
for a particular SIP request. Such authorization policies are Identity header field for a particular SIP request. Such
outside the scope of this specification. authorization policies are outside the scope of this specification.
The 436 'Bad Identity Info' response code indicates an inability to The 436 'Bad Identity Info' response code indicates an inability to
acquire the credentials needed by the verification service for acquire the credentials needed by the verification service for
validating the signature in an Identity header field. Again, given validating the signature in an Identity header field. Again, given
the potential presence of multiple Identity header fields, this the potential presence of multiple Identity header fields, this
response code should only be sent when the verification service is response code should only be sent when the verification service is
unable to deference the URIs and/or acquire the credentials unable to deference the URIs and/or acquire the credentials
associated with all Identity header fields in the request. This associated with all Identity header fields in the request. This
failure code could be repairable if the authentication service failure code could be repairable if the authentication service
resends the request with an 'info' parameter pointing to a credential resends the request with an 'info' parameter pointing to a credential
skipping to change at page 19, line 24 skipping to change at page 19, line 29
The 438 'Invalid Identity Header' response indicates that of the set The 438 'Invalid Identity Header' response indicates that of the set
of Identity header fields in a request, no header field with a valid of Identity header fields in a request, no header field with a valid
and supported PASSporT object has been received. Like the 428 and supported PASSporT object has been received. Like the 428
response, this is sent by a verification service when its local response, this is sent by a verification service when its local
policy dictates that a broken signature in an Identity header field policy dictates that a broken signature in an Identity header field
is grounds for rejecting a request. Note that in some cases, an is grounds for rejecting a request. Note that in some cases, an
Identity header field may be broken for other reasons than that an Identity header field may be broken for other reasons than that an
originator is attempting to spoof an identity: for example, when a originator is attempting to spoof an identity: for example, when a
transit network alters the Date header field of the request. Sending transit network alters the Date header field of the request. Sending
a full form PASSporT can repair some of these conditions (see a full form PASSporT can repair some of these conditions (see
Section 6.2.3), so the recommended way to attempt to repair this Section 6.2.4), so the recommended way to attempt to repair this
failure is to retry the request with the full form of PASSporT if it failure is to retry the request with the full form of PASSporT if it
had originally been sent with the compact form. The alternative had originally been sent with the compact form. The alternative
reason phrase 'Invalid PASSporT' SHOULD be used when an extended full reason phrase 'Invalid PASSporT' can be used when an extended full
form PASSporT lacks required headers or claims, or when an extended form PASSporT lacks required headers or claims, or when an extended
full form PASSporT signaled with the "ppt" parameter lacks required full form PASSporT signaled with the "ppt" parameter lacks required
claims for that extension. claims for that extension. Sending a string along these lines will
help humans debugging the sending system.
Finally, a 403 response with the special reason phrase 'Stale Date" Finally, a 403 response may be sent when the verification service
may be sent when the verification service receives a request with a receives a request with a Date header field value that is older than
Date header field value that is older than the local policy for the local policy for freshness permits. The same response may be
freshness permits. The same response may be used when the "iat" in used when the "iat" in the full form of a PASSporT has a value older
the full form of a PASSporT has a value older than the local policy than the local policy for freshness permits. The reason phrase
for freshness permits. "Stale Date" can be sent to help humans debug the failure.
6.2.3. Handling the full form of PASSporT Future specifications may explore ways, including Reason codes or
Warning headers, to communicate further information that could be
used to disambiguate the source of errors in cases with multiple
Identity headers in a single request, or provide similar detailed
feedback for debugging purposes.
6.2.3. Handling Retried Requests
If a verification service sends a failure response in the backwards
direction, the authentication service may retry the request as
described in Section 6.1.1. If the authentication service is
instantiated at a proxy server, then it will retry the request as a
sequential fork. Verification services implemented at a proxy server
will recognize this request as a spiral rather than a loop due to the
proxy behavior fix documented in [RFC5393] Section 4.2. However, if
the verification service is implemented in an endpoint, the endpoint
will need to override the default UAS behavior (in particular, the
SHOULD in [RFC3261] Section 8.2.2.2) to accept this request as a
spiral rather than a loop.
6.2.4. 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
values 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
skipping to change at page 20, line 50 skipping to change at page 21, line 31
across multiple devices may be prohibitively complex and require across multiple devices may be prohibitively complex and require
quite a good deal of additional endpoint behavior. Managing several quite a good deal of additional endpoint behavior. Managing several
credentials for the various devices could also be burdensome. Thus, credentials for the various devices could also be burdensome. Thus,
for reasons of credential management alone, implementing the for reasons of credential management alone, implementing the
authentication service at an intermediary may be more practical. authentication service at an intermediary may be more practical.
This trade-off needs to be understood by implementers of this This trade-off needs to be understood by implementers of this
specification. specification.
7.1. Credential Use by the Authentication Service 7.1. Credential Use by the Authentication Service
In order to act as an authentication service, a SIP entity must have In order to act as an authentication service, a SIP entity must
access to the private keying material of one or more credentials that possess the private keying material of one or more credentials that
cover domain names or telephone numbers. These credentials may cover domain names or telephone numbers. These credentials may
represent authority over one domain (such as example.com) or a set of represent authority over one domain (such as example.com) or a set of
domains enumerated by the credential. Similarly, a credential may domains enumerated by the credential. Similarly, a credential may
represent authority over a single telephone number or a range of represent authority over a single telephone number or a range of
telephone numbers. The way that the scope of a credential's telephone numbers. The way that the scope of a credential's
authority is expressed is specific to the credential mechanism. authority is expressed is specific to the credential mechanism.
Authorization of the use of a particular username or telephone number Authorization of the use of a particular username or telephone number
in the From header field value is a matter of local policy for the in the From header field value is a matter of local policy for the
authentication service, one that depends greatly on the manner in authentication service, one that depends greatly on the manner in
which authentication is performed. For non-telephone number user which authentication is performed. For non-telephone number user
parts, one policy might be as follows: the username given in the parts, one policy might be as follows: the username given in the
'username' parameter of the Proxy-Authorization header field MUST 'username' parameter of the Proxy-Authorization header field must
correspond exactly to the username in the From header field of the correspond exactly to the username in the From header field of the
SIP message. However, there are many cases in which this is too SIP message. However, there are many cases in which this is too
limiting or inappropriate; a realm might use 'username' parameters in limiting or inappropriate; a realm might use 'username' parameters in
Proxy-Authorization header field that do not correspond to the user- Proxy-Authorization header field that do not correspond to the user-
portion of From header fields, or a user might manage multiple portion of From header fields, or a user might manage multiple
accounts in the same administrative domain. In this latter case, a accounts in the same administrative domain. In this latter case, a
domain might maintain a mapping between the values in the 'username' domain might maintain a mapping between the values in the 'username'
parameter of the Proxy-Authorization header field and a set of one or parameter of the Proxy-Authorization header field and a set of one or
more SIP URIs that might legitimately be asserted for that more SIP URIs that might legitimately be asserted for that
'username'. For example, the username can correspond to the 'private 'username'. For example, the username can correspond to the 'private
identity' as defined in Third Generation Partnership Project (3GPP), identity' as defined in Third Generation Partnership Project (3GPP),
in which case the From header field can contain any one of the public in which case the From header field can contain any one of the public
identities associated with this private identity. In this instance, identities associated with this private identity. In this instance,
another policy might be as follows: the URI in the From header field another policy might be as follows: the URI in the From header field
MUST correspond exactly to one of the mapped URIs associated with the must correspond exactly to one of the mapped URIs associated with the
'username' given in the Proxy-Authorization header field. This is a 'username' given in the Proxy-Authorization header field. This is a
suitable approach for telephone numbers in particular. suitable approach for telephone numbers in particular.
This specification could also be used with credentials that cover a This specification could also be used with credentials that cover a
single name or URI, such as alice@example.com or single name or URI, such as alice@example.com or
sip:alice@example.com. This would require a modification to sip:alice@example.com. This would require a modification to
authentication service behavior to operate on a whole URI rather than authentication service behavior to operate on a whole URI rather than
a domain name. Because this is not believed to be a pressing use a domain name. Because this is not believed to be a pressing use
case, this is deferred to future work, but implementers should note case, this is deferred to future work, but implementers should note
this as a possible future direction. this as a possible future direction.
skipping to change at page 22, line 8 skipping to change at page 22, line 33
Exceptions to such authentication service policies arise for cases Exceptions to such authentication service policies arise for cases
like anonymity; if the AoR asserted in the From header field uses a like anonymity; if the AoR asserted in the From header field uses a
form like 'sip:anonymous@example.com' (see [RFC3323]), then the form like 'sip:anonymous@example.com' (see [RFC3323]), then the
'example.com' proxy might authenticate only that the user is a valid 'example.com' proxy might authenticate only that the user is a valid
user in the domain and insert the signature over the From header user in the domain and insert the signature over the From header
field as usual. field as usual.
7.2. Credential Use by the Verification Service 7.2. Credential Use by the Verification Service
In order to act as a verification service, a SIP entity must have a In order to act as a verification service, a SIP entity must have a
way to acquire and retain credentials for authorities over particular way to acquire credentials for authorities over particular domain
domain names, telephone numbers and/or number ranges. Dereferencing names, telephone numbers and/or number ranges. Dereferencing the URI
the URI found in the "info" parameter of the Identity header field found in the "info" parameter of the Identity header field (as
(as described Section 7.3) MUST be supported by all verification described Section 7.3) MUST be supported by all verification service
service implementations to create a baseline means of credential implementations to create a baseline means of credential acquisition.
acquisition. Provided that the credential used to sign a message is Provided that the credential used to sign a message is not previously
not previously known to the verifier, SIP entities SHOULD discover known to the verifier, SIP entities SHOULD discover this credential
this credential by dereferencing the "info" parameter, unless they by dereferencing the "info" parameter, unless they have some
have some implementation-specific way of acquiring the needed keying implementation-specific way of acquiring the needed keying material,
material, such as an offline store of periodically-updated such as an offline store of periodically-updated credentials. The
credentials. The 436 'Bad Identity Info' response exists for cases 436 'Bad Identity Info' response exists for cases where the
where the verification service cannot deference the URI in the "info" verification service cannot deference the URI in the "info"
parameter. parameter.
This specification does not propose any particular policy for a This specification does not propose any particular policy for a
verification service to determine whether or not the holder of a verification service to determine whether or not the holder of a
credential is the appropriate party to sign for a given SIP identity. credential is the appropriate party to sign for a given SIP identity.
Guidance on this is deferred to credential mechanism specifications. Guidance on this is deferred to credential mechanism specifications.
Verification service implementations supporting this specification Verification service implementations supporting this specification
may wish to have some means of retaining credentials (in accordance may wish to have some means of retaining credentials (in accordance
with normal practices for credential lifetimes and revocation) in with normal practices for credential lifetimes and revocation) in
skipping to change at page 24, line 33 skipping to change at page 25, line 15
8. Identity Types 8. Identity Types
The problem statement of STIR [RFC7340] focuses primarily on cases The problem statement of STIR [RFC7340] focuses primarily on cases
where the called and calling parties identified in the To and From where the called and calling parties identified in the To and From
header field values use telephone numbers, as this remains the header field values use telephone numbers, as this remains the
dominant use case in the deployment of SIP. However, the Identity dominant use case in the deployment of SIP. However, the Identity
header mechanism also works with SIP URIs without telephone numbers header mechanism also works with SIP URIs without telephone numbers
(of the form "sip:user@host"), and potentially other identifiers when (of the form "sip:user@host"), and potentially other identifiers when
SIP interworks with other protocols. SIP interworks with other protocols.
Authentication services vet the identity of the originator of a call, Authentication services confirm the identity of the originator of a
which is typically found in the From header field value. The call, which is typically found in the From header field value. The
guidance in this specification also applies to extracting the URI guidance in this specification also applies to extracting the URI
containing the originator's identity from the P-Asserted-Identity containing the originator's identity from the P-Asserted-Identity
header field value instead of the From header field value. In some header field value instead of the From header field value. In some
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.
skipping to change at page 25, line 28 skipping to change at page 26, line 9
URI (e.g., 'sip:+17005551008@chicago.example.com;user=phone'). The URI (e.g., 'sip:+17005551008@chicago.example.com;user=phone'). The
user part of SIP URIs with the "user=phone" parameter conforms to the user part of SIP URIs with the "user=phone" parameter conforms to the
syntax of the TEL URI scheme (RFC 3966 [RFC3966]). It is also syntax of the TEL URI scheme (RFC 3966 [RFC3966]). It is also
possible for a TEL URI to appear in SIP header fields outside the possible for a TEL URI to appear in SIP header fields outside the
context of a SIP or SIPS URI (e.g., 'tel:+17005551008'). Thus, in context of a SIP or SIPS URI (e.g., 'tel:+17005551008'). Thus, in
standards-compliant environments, numbers will be explicitly labeled standards-compliant environments, numbers will be explicitly labeled
by the use of TEL URIs or the 'user=phone' parameter. by the use of TEL URIs or the 'user=phone' parameter.
Alternatively, implementations in environments that do not conform to Alternatively, implementations in environments that do not conform to
those standards MAY follow local policies for identifying telephone those standards MAY follow local policies for identifying telephone
numbers. For exampple, implementations could infer that the user numbers. For example, implementations could infer that the user part
part is a telephone number due to the presence of the '+' indicator is a telephone number due to the presence of the '+' indicator at the
at the start of the user-portion. Absent even that indication, if start of the user-portion. Absent even that indication, if there are
there are numbers present in the user-portion, implementations might numbers present in the user-portion, implementations might
conceivably also detect that the user-portion of the URI contains a conceivably also detect that the user-portion of the URI contains a
telephone number by determining whether or not those numbers would be telephone number by determining whether or not those numbers would be
dialable or routable in the local environment -- bearing in mind that dialable or routable in the local environment -- bearing in mind that
the telephone number may be a valid [E.164] number, a nationally- the telephone number may be a valid [E.164] number, a nationally-
specific number, or even a private branch exchange number. specific number, or even a private branch exchange number.
Implementations could also rely on external hints: for example, a Implementations could also rely on external hints: for example, a
verification service implementation could infer from the type of verification service implementation could infer from the type of
credential that signed a request that the signature must be over a credential that signed a request that the signature must be over a
telephone number. telephone number.
skipping to change at page 38, line 30 skipping to change at page 39, line 18
does not meet policy constraints, the authentication service could does not meet policy constraints, the authentication service could
return a 403 response code. In this case, the reason phrase should return a 403 response code. In this case, the reason phrase should
indicate the nature of the problem; for example, "Inappropriate indicate the nature of the problem; for example, "Inappropriate
Display Name". However, the display-name is not always present, and Display Name". However, the display-name is not always present, and
in many environments the requisite operational procedures for in many environments the requisite operational procedures for
display-name validation may not exist, so no normative guidance is display-name validation may not exist, so no normative guidance is
given here. given here.
13. IANA Considerations 13. IANA Considerations
This document contains a number of actions for IANA. This document contains a number of actions for IANA. Primarily, the
previous references to RFC4474 in the sip-parameters registry should,
unless specified otherwise below, be updated to point to [RFCthis].
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 Also, the Identity-Info header reserved the compact form "n" at its
time of registration. Please remove that compact form from the time of registration. Please remove that compact form from the
registry. The Identity header however retains the compact form "y" registry. The Identity header however retains the compact form "y"
reserved by RFC4474. reserved by RFC4474.
skipping to change at page 39, line 11 skipping to change at page 39, line 47
The 437 "Unsupported Certificate" default reason phrase should be The 437 "Unsupported Certificate" default reason phrase should be
changed to "Unsupported Credential". changed to "Unsupported Credential".
13.3. Identity-Info Parameters 13.3. Identity-Info Parameters
The IANA manages a registry for Identity-Info parameters. The The IANA manages a registry for Identity-Info parameters. The
specification asks the IANA to change the name of this registry to specification asks the IANA to change the name of this registry to
"Identity Parameters". "Identity Parameters".
The "alg" parameter entry in the registry should be updated to
reference [RFCThis] as its specification.
This specification defines one new value for the registry: "info" as This specification defines one new value for the registry: "info" as
defined in this specification in Section 7.3. defined in this specification in Section 7.3.
13.4. Identity-Info Algorithm Parameter Values 13.4. Identity-Info Algorithm Parameter Values
This IANA manages an Identity-Info Algorithm Parameter Values This IANA manages an Identity-Info Algorithm Parameter Values
registry which this specification deprecates. We request that the registry which this specification deprecates. We request that the
IANA delete this registry. Since the algorithms for signing IANA deprecate and close this registry. Since the algorithms for
PASSporTs are defined in [I-D.ietf-stir-passport] rather than in this signing PASSporTs are defined in [I-D.ietf-stir-passport] rather than
specification, there is no longer a need for an algorithm parameter in this specification, there is no longer a need for an algorithm
registry for the Identity header field. parameter registry for the Identity header field.
14. Acknowledgments 14. Acknowledgments
The authors would like to thank Jim Schaad, Ning Zhang, Syed Ali, The authors would like to thank Adam Roach, Jim Schaad, Ning Zhang,
Olle Jacobson, Dave Frankel, Robert Sparks, Dave Crocker, Stephen Syed Ali, Olle Jacobson, Dave Frankel, Robert Sparks, Dave Crocker,
Kent, Brian Rosen, Alex Bobotek, Paul Kyzviat, Jonathan Lennox, Stephen Kent, Brian Rosen, Alex Bobotek, Paul Kyzviat, Jonathan
Richard Shockey, Martin Dolly, Andrew Allen, Hadriel Kaplan, Sanjay Lennox, Richard Shockey, Martin Dolly, Andrew Allen, Hadriel Kaplan,
Mishra, Anton Baskov, Pierce Gorman, David Schwartz, Eric Burger, Sanjay Mishra, Anton Baskov, Pierce Gorman, David Schwartz, Eric
Alan Ford, Christer Holmberg, Philippe Fouquart, Michael Hamer, Burger, Alan Ford, Christer Holmberg, Philippe Fouquart, Michael
Henning Schulzrinne, and Richard Barnes for their comments. Hamer, 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 40, line 4 skipping to change at page 40, line 41
Reduced the scope of the Identity signature to remove CSeq, Call- Reduced the scope of the Identity signature to remove CSeq, Call-
ID, Contact, and the message body; signing of key fingerprints in ID, Contact, and the message body; signing of key fingerprints in
SDP is now included SDP is now included
Deprecated the Identity-Info header field and relocated its Deprecated the Identity-Info header field and relocated its
components into parameters of the Identity header field (which components into parameters of the Identity header field (which
obsoletes the previous version of the header field) obsoletes the previous version of the header field)
The Identity header field can now appear multiple times in one The Identity header field can now appear multiple times in one
request request
Replaced previous signed-identity-digest format with PASSporT Replaced previous signed-identity-digest format with PASSporT
(signing algorithms now defined in a separate specification) (signing algorithms now defined in a separate specification)
Revised status code descriptions Revised status code descriptions
16. References 16. References
16.1. Normative References 16.1. Normative References
[E.164] ITU-T, "The international public telecommunication [E.164] ITU-T, "The international public telecommunication
numbering plan", E 164, February 2005, numbering plan", E 164, February 2005,
<https://www.itu.int/rec/T-REC-E.164/en>. <https://www.itu.int/rec/T-REC-E.164/en>.
[I-D.ietf-stir-passport] [I-D.ietf-stir-passport]
Wendt, C. and J. Peterson, "Personal Assertion Token Wendt, C. and J. Peterson, "Personal Assertion Token
(PASSporT)", draft-ietf-stir-passport-09 (work in (PASSporT)", draft-ietf-stir-passport-10 (work in
progress), October 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,
skipping to change at page 41, line 21 skipping to change at page 42, line 16
[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-10 (work in progress), October 2016. certificates-11 (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.
skipping to change at page 42, line 29 skipping to change at page 43, line 24
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation [RFC4916] Elwell, J., "Connected Identity in the Session Initiation
Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June
2007, <http://www.rfc-editor.org/info/rfc4916>. 2007, <http://www.rfc-editor.org/info/rfc4916>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>. <http://www.rfc-editor.org/info/rfc5234>.
[RFC5393] Sparks, R., Ed., Lawrence, S., Hawrylyshen, A., and B.
Campen, "Addressing an Amplification Vulnerability in
Session Initiation Protocol (SIP) Forking Proxies",
RFC 5393, DOI 10.17487/RFC5393, December 2008,
<http://www.rfc-editor.org/info/rfc5393>.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing a Secure Real-time Transport Protocol for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer (SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May
2010, <http://www.rfc-editor.org/info/rfc5763>. 2010, <http://www.rfc-editor.org/info/rfc5763>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS) of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <http://www.rfc-editor.org/info/rfc6698>. 2012, <http://www.rfc-editor.org/info/rfc6698>.
 End of changes. 53 change blocks. 
140 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/