draft-ietf-stir-rfc4474bis-08.txt   draft-ietf-stir-rfc4474bis-09.txt 
Network Working Group J. Peterson Network Working Group J. Peterson
Internet-Draft NeuStar Internet-Draft NeuStar
Intended status: Standards Track C. Jennings Intended status: Standards Track C. Jennings
Expires: September 22, 2016 Cisco Expires: November 26, 2016 Cisco
E. Rescorla E. Rescorla
RTFM, Inc. RTFM, Inc.
C. Wendt C. Wendt
Comcast Comcast
March 21, 2016 May 25, 2016
Authenticated Identity Management in the Session Initiation Protocol Authenticated Identity Management in the Session Initiation Protocol
(SIP) (SIP)
draft-ietf-stir-rfc4474bis-08.txt draft-ietf-stir-rfc4474bis-09.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 September 22, 2016. This Internet-Draft will expire on November 26, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 24 skipping to change at page 2, line 24
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview of Operations . . . . . . . . . . . . . . . . . . . 6 4. Overview of Operations . . . . . . . . . . . . . . . . . . . 6
5. Signature Generation and Validation . . . . . . . . . . . . . 7 5. Signature Generation and Validation . . . . . . . . . . . . . 7
5.1. Authentication Service Behavior . . . . . . . . . . . . . 7 5.1. Authentication Service Behavior . . . . . . . . . . . . . 7
5.2. Verifier Behavior . . . . . . . . . . . . . . . . . . . . 10 5.2. Verifier Behavior . . . . . . . . . . . . . . . . . . . . 10
6. Credentials . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.2.1. Handling 'canon' parameters . . . . . . . . . . . . . 12
6.1. Credential Use by the Authentication Service . . . . . . 11 6. Credentials . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2. Credential Use by the Verification Service . . . . . . . 12 6.1. Credential Use by the Authentication Service . . . . . . 13
6.3. Handling 'info' parameter URIs . . . . . . . . . . . . . 13 6.2. Credential Use by the Verification Service . . . . . . . 14
6.4. Credential System Requirements . . . . . . . . . . . . . 14 6.3. Handling 'info' parameter URIs . . . . . . . . . . . . . 15
7. Identity Types . . . . . . . . . . . . . . . . . . . . . . . 15 6.4. Credential System Requirements . . . . . . . . . . . . . 15
7.1. Telephone Numbers . . . . . . . . . . . . . . . . . . . . 15 7. Identity Types . . . . . . . . . . . . . . . . . . . . . . . 16
7.1.1. Canonicalization Procedures . . . . . . . . . . . . . 16 7.1. Telephone Numbers . . . . . . . . . . . . . . . . . . . . 16
7.2. Domain Names . . . . . . . . . . . . . . . . . . . . . . 18 7.1.1. Canonicalization Procedures . . . . . . . . . . . . . 17
8. Header Syntax . . . . . . . . . . . . . . . . . . . . . . . . 19 7.2. Domain Names . . . . . . . . . . . . . . . . . . . . . . 19
9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 22 8. Header Syntax . . . . . . . . . . . . . . . . . . . . . . . . 20
10. Gatewaying to PASSporT for non-SIP Transit . . . . . . . . . 22 9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 23
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24
12. Security Considerations . . . . . . . . . . . . . . . . . . . 25 11. Security Considerations . . . . . . . . . . . . . . . . . . . 26
12.1. Protected Request Fields . . . . . . . . . . . . . . . . 25 11.1. Protected Request Fields . . . . . . . . . . . . . . . . 26
12.1.1. Protection of the To Header and Retargeting . . . . 27 11.1.1. Protection of the To Header and Retargeting . . . . 28
12.2. Unprotected Request Fields . . . . . . . . . . . . . . . 27 11.2. Unprotected Request Fields . . . . . . . . . . . . . . . 28
12.3. Malicious Removal of Identity Headers . . . . . . . . . 28 11.3. Malicious Removal of Identity Headers . . . . . . . . . 29
12.4. Securing the Connection to the Authentication Service . 28 11.4. Securing the Connection to the Authentication Service . 29
12.5. Authorization and Transitional Strategies . . . . . . . 29 11.5. Authorization and Transitional Strategies . . . . . . . 30
12.6. Display-Names and Identity . . . . . . . . . . . . . . . 30 11.6. Display-Names and Identity . . . . . . . . . . . . . . . 31
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
13.1. Identity-Info Parameters . . . . . . . . . . . . . . . . 31 12.1. Identity-Info Parameters . . . . . . . . . . . . . . . . 32
13.2. Identity-Info Algorithm Parameter Values . . . . . . . . 31 12.2. Identity-Info Algorithm Parameter Values . . . . . . . . 32
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 12.3. Response Codes defined in RFC4474 . . . . . . . . . . . 32
15. Changes from RFC4474 . . . . . . . . . . . . . . . . . . . . 32 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 14. Changes from RFC4474 . . . . . . . . . . . . . . . . . . . . 34
16.1. Normative References . . . . . . . . . . . . . . . . . . 32 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
16.2. Informative References . . . . . . . . . . . . . . . . . 33 15.1. Normative References . . . . . . . . . . . . . . . . . . 34
15.2. Informative References . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
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 SIP URI, commonly a canonical address-of-record defined as either a SIP URI, commonly a canonical address-of-record
(AoR) employed to reach a user (such as (AoR) employed to reach a user (such as
'sip:alice@atlanta.example.com'), or a telephone number, which can be 'sip:alice@atlanta.example.com'), or a telephone number, which can be
represented as either a TEL URI [RFC3966] or as the user portion of a represented as either a TEL URI [RFC3966] or as the user portion of a
SIP URI. SIP URI.
[RFC3261] stipulates several places within a SIP request where users [RFC3261] specifies several places within a SIP request where users
can express an identity for themselves, primarily the user-populated can express an identity for themselves, most prominently the user-
From header field. However, the recipient of a SIP request has no populated From header field. However, the recipient of a SIP request
way to verify that the From header field has been populated has no way to verify that the From header field has been populated
appropriately, in the absence of some sort of cryptographic appropriately, in the absence of some sort of cryptographic
authentication mechanism. This leaves SIP vulnerable to a category authentication mechanism. This leaves SIP vulnerable to a category
of abuses, including impersonation attacks that enable robocalling of abuses, including impersonation attacks that enable robocalling
and related problems as described in [RFC7340]. Ideally, a and related problems as described in [RFC7340]. Ideally, a
cryptographic approach to identity can provide a much stronger and cryptographic approach to identity can provide a much stronger and
less spoofable assurance of identity than the Caller ID services that less spoofable assurance of identity than the Caller ID services that
the telephone network provides today. the telephone network provides today.
[RFC3261] specifies a number of security mechanisms that can be [RFC3261] encourages user agents (UAs) to implement a number of
employed by SIP user agents (UAs), 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 furthermore 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. It is desirable for SIP destination must share a prearranged secret. Practically speaking,
user agents to be able to send requests to destinations with which originating user agents need to be able to securely communicate their
they have no previous association. users' identity to destinations with which they have no previous
association.
[RFC4474] previously specified a means of signing portions of SIP As an initial attempt to address this gap, [RFC4474] specified a
requests in order to provide an identity assurance. However, RFC means of signing portions of SIP requests in order to provide an
4474 was in several ways misaligned with deployment realities (see identity assurance. However, RFC 4474 was in several ways misaligned
[I-D.rosenberg-sip-rfc4474-concerns]). Most significantly, RFC 4474 with deployment realities (see [I-D.rosenberg-sip-rfc4474-concerns]).
did not deal well with telephone numbers as identifiers, despite Most significantly, RFC 4474 did not deal well with telephone numbers
their enduring use in SIP deployments. RFC 4474 also provided a as identifiers, despite their enduring use in SIP deployments. RFC
signature over material that intermediaries in the field commonly 4474 also provided a signature over material that intermediaries in
altered. This specification therefore revises RFC 4474 in light of existing deployments commonly altered. This specification therefore
recent reconsideration of the problem space to align with the threat revises RFC 4474 in light of recent reconsideration of the problem
model in [RFC7375]. space to align with the threat model in [RFC7375], and aligns the
signature format with PASSporT [I-D.ietf-stir-passport].
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in RFC 2119 [RFC2119] and RFC 6919 [RFC6919]. described in RFC 2119 [RFC2119] and RFC 6919 [RFC6919].
3. Background 3. Background
skipping to change at page 4, line 35 skipping to change at page 4, line 37
may review to make a policy decision before answering a call. In may review to make a policy decision before answering a call. In
both of these cases, attackers might attempt to circumvent these both of these cases, attackers might attempt to circumvent these
authorization policies through impersonation. Since the primary authorization policies through impersonation. Since the primary
identifier of the sender of a SIP request, the From header field, can identifier of the sender of a SIP request, the From header field, can
be populated arbitrarily by the controller of a user agent, be populated arbitrarily by the controller of a user agent,
impersonation is very simple today in many environments. The impersonation is very simple today in many environments. The
mechanism described in this document provides a strong identity mechanism described in this document provides a strong identity
system for detecting attempted impersonation in SIP requests. system for detecting attempted impersonation in SIP requests.
This identity architecture for SIP depends on a logical This identity architecture for SIP depends on a logical
"authentication service" which validates outgoing requests; the "authentication service" which validates outgoing requests. An
authentication service may be implemented either as part of a user authentication service may be implemented either as part of a user
agent or as a proxy server. Once the sender of the message has been agent or as a proxy server; typically, it is a component of a network
intermediary like a proxy to which originating user agents send
unsigned requests. Once the sender of the message has been
authenticated, the authentication service then computes and adds authenticated, the authentication service then computes and adds
cryptographic information (including a digital signature over some cryptographic information (including a digital signature over some
components of messages) to requests to communicate to other SIP components of messages) to requests to communicate to other SIP
entities that the sending user has been authenticated and its claim entities that the sending user has been authenticated and its claim
of a particular identity has been authorized. A "verification of a particular identity has been authorized. A "verification
service" on the receiving end then validates this signature and service" on the receiving end then validates this signature and
enables policy decisions to be made based on the results of the enables policy decisions to be made based on the results of the
verification. verification.
Identities are issued to users by authorities. When a new user Identities are issued to users by authorities. When a new user
skipping to change at page 6, line 29 skipping to change at page 6, line 36
Imagine a case where Alice, who has the home proxy of example.com and Imagine a case where Alice, who has the home proxy of example.com and
the address-of-record sip:alice@example.com, wants to communicate the address-of-record sip:alice@example.com, wants to communicate
with Bob at sip:bob@example.org. They have no prior relationship, with Bob at sip:bob@example.org. They have no prior relationship,
and Bob implements best practices to prevent impersonation attacks. and Bob implements best practices to prevent impersonation attacks.
Alice generates an INVITE and places her identity, in this case her Alice generates an INVITE and places her identity, in this case her
address-of-record, in the From header field of the request. She then address-of-record, in the From header field of the request. She then
sends an INVITE over TLS to an authentication service proxy for the sends an INVITE over TLS to an authentication service proxy for the
example.com domain. example.com domain.
The authentication service authenticates Alice (possibly by sending a The proxy authenticates Alice (possibly by sending a Digest
Digest authentication challenge) and validates that she is authorized authentication challenge), and validates that she is authorized to
to assert the identity that she populated in the From header field. assert the identity that she populated in the From header field.
This value is Alice's AoR, but in other cases it could be some This value could be Alice's AoR, but in other cases it could be some
different value that the proxy server has authority over, such as a different value that the authentication service has authority over,
telephone number. The authentication service then constructs a JSON such as a telephone number. The proxy authentication service then
PASSporT object that mirrors particular SIP headers and fields, constructs a PASSporT object which contains a JSON representations of
including part of the From header field of the message, and generates headers and claims which mirror certain parts of the SIP request,
a hash of the object. This hash is then signed with the appropriate including the identity in the From header field. As a part of
credential for the identity (example.com, in the generating the PASSporT object, the authentication service signs a
sip:alice@example.com case) and the signature is inserted by the hash of those headers and claims with the appropriate credential for
proxy server into the Identity header field value of the request. the identity (in this case, the certificate for example.com, which
covers the identity sip:alice@example.com), and the signature is
inserted by the proxy server into the Identity header field value of
the request. Optionally, the JSON headers and claims themselves may
also be included in the object, encoded in the "canon" parameter of
the Identity header.
The proxy, as the holder of the private key for the example.com The proxy, as the holder of the private key for the example.com
domain, is asserting that the originator of this request has been domain, is asserting that the originator of this request has been
authenticated and that she is authorized to claim the identity that authenticated and that she is authorized to claim the identity that
appears in the From header field. The proxy inserts an "info" appears in the From header field. The proxy inserts an "info"
parameter into the Identity header that tells Bob how to acquire parameter into the Identity header that tells Bob how to acquire
keying material necessary to validate its credentials (a public key), keying material necessary to validate its credentials (a public key),
in case he doesn't already have it. in case he doesn't already have it.
When Bob's domain receives the request, it verifies the signature When Bob's domain receives the request, it verifies the signature
skipping to change at page 8, line 18 skipping to change at page 8, line 31
field uses the TEL URI scheme [RFC3966], or the identity field is a field uses the TEL URI scheme [RFC3966], or the identity field is a
SIP or SIPS URI with a telephone number in the user portion, the SIP or SIPS URI with a telephone number in the user portion, the
authentication service determines whether or not it is responsible authentication service determines whether or not it is responsible
for this telephone number; see Section 7.1 for more information. An for this telephone number; see Section 7.1 for more information. An
authentication service proceeding with a signature over a telephone authentication service proceeding with a signature over a telephone
number MUST then follow the canonicalization procedures described in number MUST then follow the canonicalization procedures described in
Section 7.1.1. If the authentication service is not authoritative Section 7.1.1. If the authentication service is not authoritative
for the identity in question, it SHOULD process and forward the for the identity in question, it SHOULD process and forward the
request normally unless the local policy is to block such requests. request normally unless the local policy is to block such requests.
The authentication service MUST NOT add an Identity header if the The authentication service MUST NOT add an Identity header if the
authentication service does not hav ethe authority to make the claim authentication service does not have the authority to make the claim
it asserts. it asserts.
Step 2: Step 2:
The authentication service MUST then determine whether or not the The authentication service MUST then determine whether or not the
sender of the request is authorized to claim the identity given in sender of the request is authorized to claim the identity given in
the identity field. In order to do so, the authentication service the identity field. In order to do so, the authentication service
MUST authenticate the sender of the message. Some possible ways in MUST authenticate the sender of the message. Some possible ways in
which this authentication might be performed include: which this authentication might be performed include:
skipping to change at page 8, line 47 skipping to change at page 9, line 13
to the user agent. to the user agent.
Authorization of the use of a particular username or telephone number Authorization of the use of a particular username or telephone number
in the user part of the From header field is a matter of local policy in the user part of the From header field is a matter of local policy
for the authentication service; see Section 6.1 for more information. for the authentication service; see Section 6.1 for more information.
Note that this check is performed only on the addr-spec in the Note that this check is performed only on the addr-spec in the
identity field (e.g., the URI of the sender, like identity field (e.g., the URI of the sender, like
'sip:alice@atlanta.example.com'); it does not convert the display- 'sip:alice@atlanta.example.com'); it does not convert the display-
name portion of the From header field (e.g., 'Alice Atlanta'). For name portion of the From header field (e.g., 'Alice Atlanta'). For
more information, see Section 12.6. more information, see Section 11.6.
Step 3: Step 3:
An authentication service MUST add a Date header field to SIP An authentication service MUST add a Date header field to SIP
requests that do not have one. The authentication service MUST requests that do not have one. The authentication service MUST
ensure that any preexisting Date header in the request is accurate. ensure that any preexisting Date header in the request is accurate.
Local policy can dictate precisely how accurate the Date must be; a Local policy can dictate precisely how accurate the Date must be; a
RECOMMENDED maximum discrepancy of sixty seconds will ensure that the RECOMMENDED maximum discrepancy of sixty seconds will ensure that the
request is unlikely to upset any verifiers. If the Date header request is unlikely to upset any verifiers. If the Date header
contains a time different by more than one minute from the current contains a time different by more than one minute from the current
time noted by the authentication service, the authentication service time noted by the authentication service, the authentication service
SHOULD reject the request. This behavior is not mandatory because a SHOULD reject the request. This behavior is not mandatory because a
user agent client (UAC) could only exploit the Date header in order user agent client (UAC) could only exploit the Date header in order
to cause a request to fail verification; the Identity header is not to cause a request to fail verification; the Identity header is not
intended to provide a source of non-repudiation or a perfect record intended to provide a source of non-repudiation or a perfect record
of when messages are processed. Finally, the authentication service of when messages are processed. Finally, the authentication service
MUST verify that both the Date header and the current time fall MUST verify that both the Date header and the current time fall
within the validity period of its credential. within the validity period of its credential.
See Section 12 for information on how the Date header field assists See Section 11 for information on how the Date header field assists
verifiers. verifiers.
Step 4: Step 4:
Subsequently, the authentication service MUST form a PASSporT object Subsequently, the authentication service MUST form a PASSporT object
and add a corresponding an Identity header to the request containing and add a corresponding an Identity header to the request containing
this signature. For baseline PASSporT objects headers (without an this signature. For baseline PASSporT objects headers (without an
Identity header "ppt" parameter), this follows the procedures in Identity header "ppt" parameter), this follows the procedures in
Section 8; if the authentication service is using an alternative Section 8; if the authentication service is using an alternative
"ppt", it MUST add an appropriate "ppt" parameter and follow the "ppt" format, it MUST add an appropriate "ppt" parameter and follow
procedures associated with it (see Section 9). After the Identity the procedures associated with that extension (see Section 9). After
header has been added to the request, the authentication service MUST the Identity header has been added to the request, the authentication
also add a "info" parameter to the Identity header. The "info" service MUST also add a "info" parameter to the Identity header. The
parameter contains a URI from which the authentication service's "info" parameter contains a URI from which the authentication
credential can be acquired; see Section 6.3 for more on credential service's credential can be acquired; see Section 6.3 for more on
acquisition. credential acquisition.
Step 5:
In the circumstances described below, an authentication service will
add a "canon" parameter to the Identity header. The syntax of
"canon" is given in Section 8; essentially, it contains a base64
encoding of the JSON header and claims in the PASSporT object. The
presence of "canon" is OPTIONAL baseline PASSporT objects in SIP as a
because the information carried in the baseline PASSporT object's
headers and claims is usually redundant with information already
carried elsewhere in the SIP request. Omitting "canon" can
significantly reduce SIP message size, especially when the PASSporT
object contains media keys.
When however an authentication service creates a PASSporT that uses
extension claims beyond the baseline PASSporT object, including
"canon" is REQUIRED in order for the verification service to be
capable of validating the signature. See Section 9.
Also, in some cases, a request signed by an authentication service
will be rejected by the verification service on the receiving side,
and the authentication service will receive a SIP 4xx status code in
the backwards direction, such as a 438 indicating a verification
failure. If the authentication service did not originally send the
Identity header with the "canon" parameter, it SHOULD retry a request
once after receiving a 438 response, this time including the "canon".
The information in "canon" is useful on the verification side for
debugging errors, and there are some known causes of verification
failures (such as the Date header changing in transit, see
Section 11.1 for more information) that can be resolved by the
inclusion of "canon".
Finally, the authentication service MUST forward the message Finally, the authentication service MUST forward the message
normally. normally.
In some cases, a request sent through an authentication service will
be rejected by the verification service, and the authentication
service will receive a 4xx status code (such as 438) in the backwards
direction. If the authentication service did not originally send the
request with the "canon" parameter, it MAY retry a request once after
receiving a 438 response, this time including the "canon". The
information in "canon" is useful for debugging errors, and there are
some known causes of verification failures (such as the Date header
changing in transit, see Section 12.1 for more information) that can
be resolved by the inclusion of "canon".
5.2. Verifier Behavior 5.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 headers, it inspects the message containing one or more Identity headers, it inspects the
signature to verify the identity of the sender of the message. The signature(s) to verify the identity of the sender of the message.
results of a verification are provided as input to an authorization The results of a verification are provided as input to an
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 headers. A A SIP request may contain zero, one, or more Identity headers. A
verification service performs the procedures below on each Identity verification service performs the procedures above on each Identity
header that appears in a request. If the verifier does not support header that appears in a request. If the verifier does not support
an Identity header present in a request due to the presence of an an Identity header present in a request due to the presence of an
unsupported "ppt" parameter, or if no Identity header is present, and unsupported "ppt" parameter, or if no Identity header is present, and
the presence of an Identity header is required by local policy (for the presence of an Identity header is required by local policy (for
example, based on a per-sending-domain policy, or a per-sending-user example, based on a per-sending-domain policy, or a per-sending-user
policy), then a 428 'Use Identity Header' response MUST be sent in policy), then a 428 'Use Identity Header' response MUST be sent in
the backwards direction. the backwards direction. For more on this and other failure
responses, see Section 12.3.
In order to verify the identity of the sender of a message, an entity In order to verify an Identity header in a message, an entity acting
acting as a verifier MUST perform the following steps, in the order as a verifier MUST perform the following steps, in the order here
here specified. specified. Note that when an Identity header contains the optional
"canon" parameter, the verifier MUST follow the additional procedures
in Section 5.2.1.
Step 1: Step 1:
The verifier MUST inspect any optional "ppt" parameter appearing the The verifier MUST inspect any optional "ppt" parameter appearing the
Identity request. If no "ppt" parameter is present, then the Identity request. If no "ppt" parameter is present, then the
verifier proceeds normally below. If a "ppt" parameter value is verifier proceeds normally below. If a "ppt" parameter value is
present, and the verifier does not support it, it MUST ignore the present, and the verifier does not support it, it MUST ignore the
Identity header. If a supported "ppt" parameter value is present, Identity header. If a supported "ppt" parameter value is present,
the verifier follows the procedures below, including the variations the verifier follows the procedures below, including the variations
described in Step 5. described in Step 5.
skipping to change at page 11, line 9 skipping to change at page 11, line 42
domains, the verifier MUST follow the process described in domains, the verifier MUST follow the process described in
Section 7.2 to determine if the signer is authoritative for the Section 7.2 to determine if the signer is authoritative for the
identity field. identity field.
Step 3: Step 3:
The verifier must first ensure that it possesses the proper keying The verifier must first ensure that it possesses the proper keying
material to validate the signature in the Identity header field, material to validate the signature in the Identity header field,
which usually involves dereferencing a URI in the "info" parameter of which usually involves dereferencing a URI in the "info" parameter of
the Identity header. See Section 6.2 for more information on these the Identity header. See Section 6.2 for more information on these
procedures. If the verifier does not suport the credential described procedures. If the verifier does not support the credential
in the "info" parameter, it MUST return a 437 "Unsupported described in the "info" parameter, then it should consider the
Certificate" response. credential for this header unsupported. If a SIP request contains no
Identity headers with a supported credential, then the verifier MUST
return a 437 "Unsupported Credential" response.
Step 4: Step 4:
The verifier MUST furthermore ensure that the value of the Date The verifier MUST furthermore ensure that the value of the Date
header meets local policy for freshness (usually, within sixty header of the request meets local policy for freshness (usually,
seconds) and that it falls within the validity period of the within sixty seconds) and that it falls within the validity period of
credential used to sign the Identity header. For more on the attacks the credential used to sign the Identity header. For more on the
this prevents, see Section 12.1. attacks this prevents, see Section 11.1. If the "canon" parameter is
present, the verifier should follow the Date-related behavior in
Section 5.2.1.
Step 5: Step 5:
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 "ppt" parameter) the verifier MUST follow the Identity header "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 8. If a "ppt" parameter is present, the described in Section 8. If a "ppt" parameter is present (and per
verifier follows the procedures for that "ppt" (see Section 9). If a Step 1, is understood), the verifier follows the procedures for that
verifier determines that the signature on the message does not "ppt" (see Section 9). If a verifier determines that the that the
correspond to the reconstructed signed-identity-digest, then a 438 signature in the Identity does not correspond to the reconstructed
'Invalid Identity Header' response MUST be returned. signed-identity-digest, then the Identity header should be considered
invalid.
The handling of the message after the verification process depends on The presence of multiple Identity headers within a message raises the
how the implementation service is implemented and on local policy. prospect that a verification services could receive a message
This specification does not propose any authorization policy for user containing some valid and some invalid Identity headers. If the
agents or proxy servers to follow based on the presence of a valid verifier determines all Identity headers within a message are
Identity header, the presence of an invalid Identity header, or the invalid, then a 438 'Invalid Identity Header' response MUST be
absence of an Identity header, but it is anticipated that local returned.
policies could involve making different forwarding decisions in
intermediary implementations, or changing how the user is alerted, or The verification of an Identity header does not entail any particular
how identity is rendered, in user agent implementations. treatment of the request. The handling of the message after the
verification process depends on how the implementation service is
implemented and on local policy. This specification does not propose
any authorization policy for user agents or proxy servers to follow
based on the presence of a valid Identity header, the presence of an
invalid Identity header, or the absence of an Identity header, but it
is anticipated that local policies could involve making different
forwarding decisions in intermediary implementations, or changing how
the user is alerted, or how identity is rendered, in user agent
implementations.
5.2.1. Handling 'canon' parameters
If the optional "canon" parameter of the Identity header is present,
it contains a base64 encoding of the header and claim component of
the PASSporT object constructed by the authentication service, and
this it conveys any canonical telephone number formats created by the
authentication service (see Section 7.1.1), as well as an "iat" claim
corresponding to the Date header that the authentication service
used. The "canon" is provided purely as an optimization and
debugging mechanism for the verification service.
When "canon" is present, the verification service MAY compute its own
canonicalization of the numbers and compare them to the values in the
"canon" parameter before performing any cryptographic functions in
order to ascertain whether or not the two ends agree on the canonical
number form. Also, when "canon" is present, during Step 4 the
verification service SHOULD compare the "iat" value in the "canon" to
its Date header field value. If the two are different, and the "iat"
value is later but within verification service policy for freshness,
the verification service SHOULD perform the computation required by
Step 5 using the "iat" value instead of the Date value. As some
deployments in the field have been observed to change the Date header
in transit, this procedure will prevent some unnecessary verification
failures.
6. Credentials 6. Credentials
6.1. Credential Use by the Authentication Service 6.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 have
access to the private keying material of one or more credentials that access to 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 an entire domain (such as example.com) or represent authority over an entire domain (such as example.com) or
potentially a set of domains enumerated by the credential. potentially a set of domains enumerated by the credential.
skipping to change at page 12, line 37 skipping to change at page 14, line 13
follows: the URI in the From header field MUST correspond exactly to follows: the URI in the From header field MUST correspond exactly to
one of the mapped URIs associated with the 'username' given in the one of the mapped URIs associated with the 'username' given in the
Proxy-Authorization header. This is a suitable approach for Proxy-Authorization header. This is a suitable approach for
telephone numbers in particular. 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 implementors 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.
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.
6.2. Credential Use by the Verification Service 6.2. Credential Use by the Verification Service
skipping to change at page 14, line 7 skipping to change at page 15, line 31
which particular credential was used to sign a request, when there which particular credential was used to sign a request, when there
are potentially multiple authorities eligible to sign. For example, are potentially multiple authorities eligible to sign. For example,
imagine a case where a domain implements the authentication service imagine a case where a domain implements the authentication service
role for a range of telephone and a user agent belonging to Alice has role for a range of telephone and a user agent belonging to Alice has
acquired a credential for a single telephone number within that acquired a credential for a single telephone number within that
range. Either would be eligible to sign a SIP request for the number range. Either would be eligible to sign a SIP request for the number
in question. Verification services however need a means to in question. Verification services however need a means to
differentiate which one performed the signature. The "info" differentiate which one performed the signature. The "info"
parameter performs that function. parameter performs that function.
If the optional "canon" parameter is present, it contains the bae64
encoded result of JSON object construction process performed by the
authentication service (see Section 7.1.1), including the
canonicalization processes applied to the identity in the identity
fields of the sender and intended recipient. The "canon" is provided
purely as an optimization for the verification service. The
verification service MAY compute its own canonicalization of the
numbers and compare them to the values in the "canon" parameter
before performing any cryptographic functions in order to ascertain
whether or not the two ends agree on the canonical number form.
6.4. Credential System Requirements 6.4. Credential System Requirements
This document makes no recommendation for the use of any specific This document makes no recommendation for the use of any specific
credential system. Today, there are two primary credential systems credential system. Today, there are two primary credential systems
in place for proving ownership of domain names: certificates (e.g., in place for proving ownership of domain names: certificates (e.g.,
X.509 v3, see [RFC5280]) and the domain name system itself (e.g., X.509 v3, see [RFC5280]) and the domain name system itself (e.g.,
DANE, see [RFC6698]). It is envisioned that either could be used in DANE, see [RFC6698]). It is envisioned that either could be used in
the SIP identity context: an "info" parameter could for example give the SIP identity context: an "info" parameter could for example give
an HTTP URL of the form 'application/pkix-cert' pointing to a an HTTP URL of the Content-Type 'application/pkix-cert' pointing to a
certificate (following the conventions of [RFC2585]). The "info" certificate (following the conventions of [RFC2585]). The "info"
parameter may use the DNS URL scheme (see [RFC4501]) to designate parameter may use the DNS URL scheme (see [RFC4501]) to designate
keys in the DNS. keys in the DNS.
While no comparable public credentials exist for telephone numbers, While no comparable public credentials exist for telephone numbers,
either approach could be applied to telephone numbers. A credential either approach could be applied to telephone numbers. A credential
system based on certificates is given in system based on certificates is given in
[I-D.ietf-stir-certificates]. One based on the domain name system is [I-D.ietf-stir-certificates], but this specification can work with
given in [I-D.kaplan-stir-cider]. other credential systems; for example, using the DNS was proposed in
[I-D.kaplan-stir-cider].
In order for a credential system to work with this mechanism, its In order for a credential system to work with this mechanism, its
specification must detail: specification must detail:
which URIs schemes the credential will use in the "info" which URIs schemes the credential will use in the "info"
parameter, and any special procedures required to dereference the parameter, and any special procedures required to dereference the
URIs URIs
how the verifier can learn the scope of the credential how the verifier can learn the scope of the credential
any special procedures required to extract keying material from any special procedures required to extract keying material from
the resources designated by the URI the resources designated by the URI
any algorithms that would appear in the Identity-Info "alg" any algorithms required to validate the credentials (e.g. for
parameter other than 'RS256.' Note that the policy for adding certificates, any algorithms used by certificate authorities to
algorithms to this registry requires Standards Action sign certificates themselves)
It is furthermore required that all credential specifications
describe how the associated credentials will support the mandatory
signing algorithm(s) required by PASSporT [I-D.ietf-stir-passport].
SIP entities cannot reliably predict where SIP requests will SIP entities cannot reliably predict where SIP requests will
terminate. When choosing a credential scheme for deployments of this terminate. When choosing a credential scheme for deployments of this
specification, it is therefore essential that the trust anchor(s) for specification, it is therefore essential that the trust anchor(s) for
credentials be widely trusted, or that deployments restrict the use credentials be widely trusted, or that deployments restrict the use
of this mechanism to environments where the reliance on particular of this mechanism to environments where the reliance on particular
trust anchors is assured by business arrangements or similar trust anchors is assured by business arrangements or similar
constraints. constraints.
Note that credential systems must address key lifecycle management Note that credential systems must address key lifecycle management
skipping to change at page 16, line 35 skipping to change at page 18, line 7
the sender of a request; while it is not envisioned that most of the sender of a request; while it is not envisioned that most of
those networks would or should make use of the Identity mechanism those networks would or should make use of the Identity mechanism
described in this specification, where they do, local policy might described in this specification, where they do, local policy might
therefore dictate that the canonical string derive from the P- therefore dictate that the canonical string derive from the P-
Asserted-Identity header field rather than the From. In any case Asserted-Identity header field rather than the From. In any case
where local policy canonicalizes the number into a form different where local policy canonicalizes the number into a form different
from how it appears in the From header field, the use of the "canon" from how it appears in the From header field, the use of the "canon"
parameter by authentication services is RECOMMENDED, but because parameter by authentication services is RECOMMENDED, but because
"canon" itself could then divulge information about users or "canon" itself could then divulge information about users or
networks, implementers should be mindful of the guidelines in networks, implementers should be mindful of the guidelines in
Section 11. Section 10.
First, implementations must assess if the user-portion of the URI First, implementations must assess if the user-portion of the URI
constitutes a telephone number. In some environments, numbers constitutes a telephone number. In some environments, numbers
will be explicitly labeled by the use of TEL URIs or the will be explicitly labeled by the use of TEL URIs or the
'user=phone' parameter, or implicitly by the presence of the '+' 'user=phone' parameter, or implicitly by the presence of the '+'
indicator at the start of the user-portion. Absent these indicator at the start of the user-portion. Absent these
indications, if there are numbers present in the user-portion, indications, if there are numbers present in the user-portion,
implementations may also detect that the user-portion of the URI implementations may also detect that the user-portion of the URI
contains a telephone number by determining whether or not those contains a telephone number by determining whether or not those
numbers would be dialable or routable in the local environment -- numbers would be dialable or routable in the local environment --
skipping to change at page 17, line 25 skipping to change at page 18, line 45
the number from a dial string (see [RFC3966]), removing any the number from a dial string (see [RFC3966]), removing any
national or international dialing prefixes or performing similar national or international dialing prefixes or performing similar
procedures. It is only in the case that an implementation cannot procedures. It is only in the case that an implementation cannot
determine how to convert the number to a globally-routable format determine how to convert the number to a globally-routable format
that this step may be skipped. This will be the case, for that this step may be skipped. This will be the case, for
example, for nationally-specific service numbers (e.g. 911, 112); example, for nationally-specific service numbers (e.g. 911, 112);
however, the routing procedures associated with those numbers will however, the routing procedures associated with those numbers will
likely make sure that the verification service understands the likely make sure that the verification service understands the
context of their use. context of their use.
Oher transformations during canonicalization MAY be made in Other transformations during canonicalization MAY be made in
accordance with specific policies used within a local domain. For accordance with specific policies used within a local domain. For
example, one domain may only use local number formatting and need example, one domain may only use local number formatting and need
to convert all To/From user portions to E.164 by prepending to convert all To/From user portions to E.164 by prepending
country-code and region code digits; another domain might prefix country-code and region code digits; another domain might prefix
usernames with trunk-routing codes and need to remove the prefix. usernames with trunk-routing codes and need to remove the prefix.
This specification cannot anticipate all of the potential This specification cannot anticipate all of the potential
transformations that might be useful. transformations that might be useful.
The resulting canonical number string will be used as input to the The resulting canonical number string will be used as input to the
hash calculation during signing and verifying processes. hash calculation during signing and verifying processes.
The ABNF of this number string is: The ABNF of this number string is:
tn-spec = [ "#" / "*" ] 1*DIGIT tn-spec = [ "#" / "*" ] 1*DIGIT
skipping to change at page 20, line 17 skipping to change at page 21, line 48
For SIP implementations to populate the PASSporT header object from a For SIP implementations to populate the PASSporT header object from a
SIP request, the following elements message MUST be placed as the SIP request, the following elements message MUST be placed as the
values corresponding to the designated JSON keys: values corresponding to the designated JSON keys:
First, per baseline [I-D.ietf-stir-passport], the JSON key "typ" First, per baseline [I-D.ietf-stir-passport], the JSON key "typ"
key MUST have the value "passport". key MUST have the value "passport".
Second, the JSON key "alg" MUST mirror the value of the optional Second, the JSON key "alg" MUST mirror the value of the optional
"alg" parameter in the SIP Identity header. Note if the "alg" "alg" parameter in the SIP Identity header. Note if the "alg"
parameter is absent, the default value is "RS256". parameter is absent, the default value is "ES256".
Third, the JSON key "x5u" MUST have a value equivalent to the Third, the JSON key "x5u" MUST have a value equivalent to the
quoted URI in the "info" parameter. quoted URI in the "info" parameter.
Fourth, the optional JSON key "ppt", if present, MUST have a value Fourth, the optional JSON key "ppt", if present, MUST have a value
equivalent to the quoted value of the "ppt" parameter of the equivalent to the quoted value of the "ppt" parameter of the
Identity header. If the "ppt" parameter is absent from the Identity header. If the "ppt" parameter is absent from the
header, the "ppt" key MUST NOT not appear in the JSON heaer header, the "ppt" key MUST NOT not appear in the JSON heaer
object. object.
For example: For example:
{ "typ":"passport", { "typ":"passport",
"alg":"RS256", "alg":"ES256",
"x5u":"https://www.example.com/cert.pkx" } "x5u":"https://www.example.com/cert.pkx" }
To populate the PASSporT claims JSON object, the following elements To populate the PASSporT claims JSON object from a SIP request, the
MUST be placed as values corresponding to the designated JSON keys: following elements MUST be placed as values corresponding to the
designated JSON keys:
First, if the originating identity is a telephone number, the JSON First, if the originating identity is a telephone number, the JSON
key "otn" MUST be used, set to the value of the quoted originating key "otn" MUST be used, set to the value of the quoted originating
identity, a canonicalized telephone number (see Section 7.1.1). identity, a canonicalized telephone number (see Section 7.1.1).
Otherwise, the JSON key "ouri" MUST be used, set to the value of Otherwise, the JSON key "ouri" MUST be used, set to the value of
the AoR of the UA sending the message as taken from addr-spec of the AoR of the UA sending the message as taken from addr-spec of
the From header field. the From header field.
Second, if the destination identity is a telephone number, the Second, if the destination identity is a telephone number, the
JSON key "dtn" MUST be used, set to the value of the quoted JSON key "dtn" MUST be used, set to the value of the quoted
skipping to change at page 21, line 11 skipping to change at page 22, line 41
Section 7.1.1). Otherwise, the JSON key "duri" MUST be used, set Section 7.1.1). Otherwise, the JSON key "duri" MUST be used, set
to the value of the addr-spec component of the To header field, to the value of the addr-spec component of the To header field,
which is the AoR to which the request is being sent. which is the AoR to which the request is being sent.
Third, the JSON key "iat" MUST appear, set to the value of a Third, the JSON key "iat" MUST appear, set to the value of a
quoted encoding of the value of the SIP Date header field as a quoted encoding of the value of the SIP Date header field as a
JSON NumericDate (as UNIX time, per [RFC7519] Section 2). JSON NumericDate (as UNIX time, per [RFC7519] Section 2).
Fourth, if the request contains an SDP message body, and if that Fourth, if the request contains an SDP message body, and if that
SDP contains one or more "a=fingerprint" attributes, then the JSON SDP contains one or more "a=fingerprint" attributes, then the JSON
key "mky" MUST appear with the quoted value(s) of the fingerprint key "mky" MUST appear with the algorithm(s) and value(s) of the
attributes (if they differ). Each attribute value consists of all fingerprint attributes (if they differ), following the format
characters following the colon after "a=fingerprint" including the given in [I-D.ietf-stir-passport] Section 3.2.2.2.
algorithm description and hexadecimal key representation, after
removing any whitespace, carriage returns, and "/" line break
indicators. If multiple non-identical "a=fingerprint" attributes
appear in an SDP body, then all non-identical attributes values
MUST be concatenated, with no separating character, after sorting
the values in alphanumeric order. If the SDP body contains no
"a=fingerprint" attribute, then no JSON "mky" key is added to the
object.
For example: For example:
{ "otn":"12155551212", { "otn":"12155551212",
"dtn":"12155551213", "dtn":"12155551213",
"iat":"1443208345" } "iat":"1443208345" }
For more information on the security properties of these SIP message For more 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 and [RFC3893]. Section 11 and [RFC3893]. Note that future extensions to the
PASSporT object could introduce new claims, and that further SIP
procedures could be required to extract further information from the
SIP request to populate the values of those claims; see Section 9.
After these two JSON objects, the header and the claims, have been After these two JSON objects, the header and the claims, have been
constructed, they must each be hashed per [I-D.ietf-stir-passport] constructed, they must each be hashed per [I-D.ietf-stir-passport]
Section 3.3. The signed value of those concatenated hashes then Section 3.3. The signed value of those concatenated hashes then
becomes the signed-identity-string of the Identity header. The becomes the signed-identity-string of the Identity header. The
hashing and signing algorithm is specified by the 'alg' parameter of hashing and signing algorithm is specified by the 'alg' parameter of
the Identity header and the mirrored "alg" parameter of PASSporT. the Identity header and the mirrored "alg" parameter of PASSporT.
This specification defines only one value for the 'alg' parameter: This specification inherits from the PASSporT specification one value
'RS256', as defined in [RFC7519], which connotes a SHA-256 hash for the 'alg' parameter: 'ES256', as defined in [RFC7519], which
followed by a RSASSA-PKCS1-v1_5 signature. All implementations of connotes an ECDSA P-256 digital signature. All implementations of
this specification MUST support 'RS256'. Any further 'alg' values this specification MUST support the required signing algorithms of
MUST be defined in a Standards Track RFC, see Section 13.2 for more PASSporT.
information.
The complete form of the Identity header will therefore look like the The complete form of the Identity header will therefore look like the
following example: following example:
Identity: "sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9dlxkWzo Identity: "sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9dlxkWzo
eU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0Lu5csIp eU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgtw0Lu5csIp
pPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs="; \ pPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs="; \
info=<https://biloxi.example.org/biloxi.cer>;alg=RS256 info=<https://biloxi.example.org/biloxi.cer>;alg=ES256
In a departure from JWT practice, the SIP usage of PASSporT MAY NOT In a departure from JWT practice, the SIP usage of PASSporT MAY NOT
include the base64 encoded version of the JSON objects in the include the base64 encoded version of the JSON objects in the
Identity header: only the signature component of the PASSporT is Identity header: only the signature component of the PASSporT is
REQUIRED. Optionally, as a debugging measure or optimization, the REQUIRED. Optionally, as a debugging measure or optimization, the
base64 encoded concatenation of the JSON header and claims may be base64 encoded concatenation of the JSON header and claims may be
included as the value of a "canon" parameter of the Identity header. included as the value of a "canon" parameter of the Identity header.
Note that this may be lengthy string. Note that this may be lengthy string.
9. Extensibility 9. Extensibility
For the extensibility of baseline PASSporT with now claims, see
[I-D.ietf-stir-passport] Section 4.
As future requirements may warrant increasing the scope of the As future requirements may warrant increasing the scope of the
Identity mechanism, this specification defines an optional "ppt" Identity mechanism, this specification defines an optional "ppt"
parameter of the Identity header, which mirrors the "ppt" header key parameter of the Identity header, which mirrors the "ppt" header key
in PASSporT. The "ppt" parameter value MUST consist of a token in PASSporT. The "ppt" parameter value MUST consist of a token
containing an extension specification, which denotes an extended set containing an extension specification, which denotes an extended set
of one or more signed claims per the type extensibility mechanism of one or more signed claims per the type extensibility mechanism
specified in [I-D.ietf-stir-passport]. specified in [I-D.ietf-stir-passport].
An authentication service cannot assume that verifiers will An authentication service cannot assume that verifiers will
understand any given extension. Verifiers that do support an understand any given extension. Verifiers that do support an
extension may then trigger appropriate application-level behavior in extension may then trigger appropriate application-level behavior in
the presence of an extension; authors of extensions should provide the presence of an extension; authors of extensions should provide
appropriate extension-specific guidance to application developers on appropriate extension-specific guidance to application developers on
this point. this point.
If any claim in an extension contains a JSON value that does not If any claim in an extension contains a JSON value that does not
correspond to any field of the SIP request, but then the optional correspond to any field of the SIP request, but then the optional
"canon" parameter MUST be used for the Identity header containing "canon" parameter MUST be used for the Identity header containing
that extension. that extension.
10. Gatewaying to PASSporT for non-SIP Transit 10. Privacy Considerations
As defined in this specification, the signature in the Identity
header is equivalent to the signature that would appear in a PASSporT
token. This is so that a valid PASSporT can be generated based on a
SIP request containing an Identity header. This PASSporT could then
be transported in alternate protocols, stored in a repository and
later accessed, or similarly used outside the context of establishing
an end-to-end SIP session. Third-party services could also generate
PASSporT tokens which could be transformed into Identity headers and
added to SIP requests in transit by authentication services.
Because the base64 encoding of JSON objects containing headers and
claims can be quite long, and because the information baseline
PASSporT contains is necessarily redundant with information in the
header field values of the SIP request itself, SIP does not require
implementations to carry the base64 encodings of those objects. The
optional "canon" parameter of the Identity-Info, if present, contains
the encoded objects used to generate the hash and signature (see
Section 8), but if the "canon" parameter is not present, the contents
of the objects can be regenerated by constructing the object anew
from the SIP header fields received.
Alternative transports for PASSporT and their requirements are left
to future specifications.
11. Privacy Considerations
The purpose of this mechanism is to provide a strong identification The purpose of this mechanism is to provide a strong identification
of the originator of a SIP request, specifically a cryptographic of the originator of a SIP request, specifically a cryptographic
assurance that an authority asserts the orginator can claim the URI assurance that an authority asserts the originator can claim the URI
given in the From header field. This URI may contain a variety of given in the From header field. This URI may contain a variety of
personally identifying information, including the name of a human personally identifying information, including the name of a human
being, their place of work or service provider, and possibly further being, their place of work or service provider, and possibly further
details. The intrinsic privacy risks associated with that URI are, details. The intrinsic privacy risks associated with that URI are,
however, no different from those of baseline SIP. Per the guidance however, no different from those of baseline SIP. Per the guidance
in [RFC6973], implementors should make users aware of the privacy in [RFC6973], implementers should make users aware of the privacy
trade-off of providing secure identity. trade-off of providing secure identity.
The identity mechanism presented in this document is compatible with The identity mechanism presented in this document is compatible with
the standard SIP practices for privacy described in [RFC3323]. A SIP the standard SIP practices for privacy described in [RFC3323]. A SIP
proxy server can act both as a privacy service and as an proxy server can act both as a privacy service and as an
authentication service. Since a user agent can provide any From authentication service. Since a user agent can provide any From
header field value that the authentication service is willing to header field value that the authentication service is willing to
authorize, there is no reason why private SIP URIs that contain authorize, there is no reason why private SIP URIs that contain
legitimate domains (e.g., sip:anonymous@example.com) cannot be signed legitimate domains (e.g., sip:anonymous@example.com) cannot be signed
by an authentication service. The construction of the Identity by an authentication service. The construction of the Identity
skipping to change at page 25, line 9 skipping to change at page 26, line 9
Identity with the Identity "canon" parameter in this fashion is NOT Identity with the Identity "canon" parameter in this fashion is NOT
RECOMMENDED outside of environments where SIP requests will never RECOMMENDED outside of environments where SIP requests will never
leave the trust domain. As a side note, history shows that closed leave the trust domain. As a side note, history shows that closed
networks never stay closed and one should design their implementation networks never stay closed and one should design their implementation
assuming connectivity to the broader Internet. assuming connectivity to the broader Internet.
Finally, note that unlike [RFC3325], the mechanism described in this Finally, note that unlike [RFC3325], the mechanism described in this
specification adds no information to SIP requests that has privacy specification adds no information to SIP requests that has privacy
implications. implications.
12. Security Considerations 11. Security Considerations
This document describes a mechanism that provides a signature over This document describes a mechanism that provides a signature over
the Date header field of SIP requests, parts of the To and From the Date header field of SIP requests, parts of the To and From
header fields, and when present any media keying material in the header fields, and when present any media keying material in the
message body. In general, the considerations related to the security message body. In general, the considerations related to the security
of these headers are the same as those given in [RFC3261] for of these headers are the same as those given in [RFC3261] for
including headers in tunneled 'message/sip' MIME bodies (see including headers in tunneled 'message/sip' MIME bodies (see
Section 23 of RFC3261 in particular). The following section details Section 23 of RFC3261 in particular). The following section details
the individual security properties obtained by including each of the individual security properties obtained by including each of
these header fields within the signature; collectively, this set of these header fields within the signature; collectively, this set of
header fields provides the necessary properties to prevent header fields provides the necessary properties to prevent
impersonation. It addresses the solution-specific attacks against impersonation. It addresses the solution-specific attacks against
in-band solutions enumerated in [RFC7375] Section 4.1. in-band solutions enumerated in [RFC7375] Section 4.1.
12.1. Protected Request Fields 11.1. Protected Request Fields
The From header field value (in ordinary operations) indicates the The From header field value (in ordinary operations) indicates the
identity of the sender of the message. The SIP address-of-record identity of the sender of the message. The SIP address-of-record
URI, or an embedded telephone number, in the From header field is the URI, or an embedded telephone number, in the From header field is the
identity of a SIP user, for the purposes of this document. Note that identity of a SIP user, for the purposes of this document. Note that
in some deployments the identity of the sender may reside in P- in some deployments the identity of the sender may reside in P-
Asserted-Id instead. The sender's identity is the key piece of Asserted-Id instead. The sender's identity is the key piece of
information that this mechanism secures; the remainder of the signed information that this mechanism secures; the remainder of the signed
parts of a SIP request are present to provide reference integrity and parts of a SIP request are present to provide reference integrity and
to prevent certain types of cut-and-paste attacks. to prevent certain types of cut-and-paste attacks.
skipping to change at page 25, line 49 skipping to change at page 26, line 49
header field (the RECOMMENDED interval is that the Date header must header field (the RECOMMENDED interval is that the Date header must
indicate a time within 60 seconds of the receipt of a message). Note indicate a time within 60 seconds of the receipt of a message). Note
that per baseline [RFC3261] behavior, servers keep state of recently that per baseline [RFC3261] behavior, servers keep state of recently
received requests, and thus if an Identity header is replayed by an received requests, and thus if an Identity header is replayed by an
attacker within the Date interval, verifiers can detect that it is attacker within the Date interval, verifiers can detect that it is
spoofed because a message with an identical Date from the same source spoofed because a message with an identical Date from the same source
had recently been received. had recently been received.
It has been observed in the wild that some networks change the Date It has been observed in the wild that some networks change the Date
header field value of SIP requests in transit, and that alternative header field value of SIP requests in transit, and that alternative
behavior might be necessary to accomodate that use case. behavior might be necessary to accommodate that use case.
Verification services that observe a signature validation failure MAY Verification services that observe a signature validation failure MAY
therefore reconstruct the Date header field component of the therefore reconstruct the Date header field component of the
signature from the "iat" carried in PASSporT via the "canon" signature from the "iat" carried in PASSporT via the "canon"
parameter: provided that time recorded by "iat" falls within the parameter: provided that time recorded by "iat" falls within the
local policy for freshness that would ordinarily apply to the Date local policy for freshness that would ordinarily apply to the Date
header, the verification service MAY treat the signature as valid, header, the verification service MAY treat the signature as valid,
provided it keeps adequate state to detect recent replays. Note that provided it keeps adequate state to detect recent replays. Note that
this will require the inclusion of the "canon" parameter by this will require the inclusion of the "canon" parameter by
authentication services in networks where such failures are observed. authentication services in networks where such failures are observed.
The To header field value provides the identity of the SIP user that The To header field value provides the identity of the SIP user that
this request originally targeted. Providing the To header field in this request originally targeted. Covering the identity in the To
the Identity signature serves two purposes. First, it prevents cut- header field with the Identity signature serves two purposes. First,
and-paste attacks in which an Identity header from legitimate request it prevents cut-and-paste attacks in which an Identity header from
for one user is cut-and-pasted into a request for a different user. legitimate request for one user is cut-and-pasted into a request for
Second, it preserves the starting URI scheme of the request, which a different user. Second, it preserves the starting URI scheme of
helps prevent downgrade attacks against the use of SIPS. The To the request, which helps prevent downgrade attacks against the use of
offers additional protection against cut-and-paste attacks beyond the SIPS. The To identity offers additional protection against cut-and-
Date header field. For example, without a signature over the To, an paste attacks beyond the Date header field. For example, without a
attacker who receives a call from a target could immediately forward signature over the To identity, an attacker who receives a call from
the INVITE to the target's voicemail service within the Date a target could immediately forward the INVITE to the target's
interval, and the voicemail service would have no way knowing that voicemail service within the Date interval, and the voicemail service
the Identity header it received had been originally signed for a call would have no way knowing that the Identity header it received had
intended for a different number. However, note the caveats below in been originally signed for a call intended for a different number.
Section 12.1.1. However, note the caveats below in Section 11.1.1.
When signing a request that contains a fingerprint of keying material When signing a request that contains a fingerprint of keying material
in SDP for DTLS-SRTP [RFC5763], this mechanism always provides a in SDP for DTLS-SRTP [RFC5763], this mechanism always provides a
signature over that fingerprint. This signature prevents certain signature over that fingerprint. This signature prevents certain
classes of impersonation attacks in which an attacker forwards or classes of impersonation attacks in which an attacker forwards or
cut-and-pastes a legitimate request. Although the target of the cut-and-pastes a legitimate request. Although the target of the
attack may accept the request, the attacker will be unable to attack may accept the request, the attacker will be unable to
exchange media with the target as they will not possess a key exchange media with the target as they will not possess a key
corresponding to the fingerprint. For example, there are some corresponding to the fingerprint. For example, there are some
baiting attacks, launched with the REFER method or through social baiting attacks, launched with the REFER method or through social
skipping to change at page 27, line 5 skipping to change at page 28, line 5
prevented by securing a fingerprint for DTLS-SRTP. While this is a prevented by securing a fingerprint for DTLS-SRTP. While this is a
different form of impersonation than is commonly used for different form of impersonation than is commonly used for
robocalling, ultimately there is little purpose in establishing the robocalling, ultimately there is little purpose in establishing the
identity of the user that originated a SIP request if this assurance identity of the user that originated a SIP request if this assurance
is not coupled with a comparable assurance over the contents of the is not coupled with a comparable assurance over the contents of the
subsequent media communication. This signature also, per [RFC7258], subsequent media communication. This signature also, per [RFC7258],
reduces the potential for passive monitoring attacks against the SIP reduces the potential for passive monitoring attacks against the SIP
media. In environments where DTLS-SRTP is unsupported, however, no media. In environments where DTLS-SRTP is unsupported, however, no
field is signed and no protections are provided. field is signed and no protections are provided.
12.1.1. Protection of the To Header and Retargeting 11.1.1. Protection of the To Header and Retargeting
The mechanism in this document provides a signature over the identity The mechanism in this document provides a signature over the identity
information in the To header field value of requests. This provides information in the To header field value of requests. This provides
a means for verifiers to detect replay attacks where a signed request a means for verifiers to detect replay attacks where a signed request
originally sent to one target is modified and then forwarded by an originally sent to one target is modified and then forwarded by an
attacker to another, unrelated target. Armed with the original value attacker to another, unrelated target. Armed with the original value
of the To header field, the recipient of a request may compare it to of the To header field, the recipient of a request may compare it to
their own identity in order to determine whether or not the identity their own identity in order to determine whether or not the identity
information in this call might have been replayed. However, any information in this call might have been replayed. However, any
request may be legitimately retargeted as well, and as a result request may be legitimately retargeted as well, and as a result
skipping to change at page 27, line 40 skipping to change at page 28, line 40
guidance is given for implementers here regarding the 'connected guidance is given for implementers here regarding the 'connected
party' problem (see [RFC4916]); authentication service behavior is party' problem (see [RFC4916]); authentication service behavior is
unchanged if retargeting has occurred for a dialog-forming request. unchanged if retargeting has occurred for a dialog-forming request.
Ultimately, the authentication service provides an Identity header Ultimately, the authentication service provides an Identity header
for requests in the backwards dialog when the user is authorized to for requests in the backwards dialog when the user is authorized to
assert the identity given in the From header field, and if they are assert the identity given in the From header field, and if they are
not, an Identity header is not provided. And per the threat model of not, an Identity header is not provided. And per the threat model of
[RFC7375], resolving problems with 'connected' identity has little [RFC7375], resolving problems with 'connected' identity has little
bearing on detecting robocalling or related impersonation attacks. bearing on detecting robocalling or related impersonation attacks.
12.2. Unprotected Request Fields 11.2. Unprotected Request Fields
RFC4474 originally had protections for the Contact, Call-ID and CSeq. RFC4474 originally had protections for the Contact, Call-ID and CSeq.
These are removed from RFC4474bis. The absence of these header These are removed from RFC4474bis. The absence of these header
values creates some opportunities for determined attackers to values creates some opportunities for determined attackers to
impersonate based on cut-and-paste attacks; however, the absence of impersonate based on cut-and-paste attacks; however, the absence of
these headers does not seem impactful to preventing the simple these headers does not seem impactful to preventing the simple
unauthorized claiming of an identity for the purposes of robocalling, unauthorized claiming of an identity for the purposes of robocalling,
voicemail hacking, or swatting, which is the primary scope of the voicemail hacking, or swatting, which is the primary scope of the
current document. current document.
skipping to change at page 28, line 24 skipping to change at page 29, line 24
guarantee that no Via hops are inserted between the sending user guarantee that no Via hops are inserted between the sending user
agent and the authentication service, it could not prevent an agent and the authentication service, it could not prevent an
attacker from adding a Via hop after the authentication service, and attacker from adding a Via hop after the authentication service, and
thereby preempting responses. It is necessary for the proper thereby preempting responses. It is necessary for the proper
operation of SIP for subsequent intermediaries to be capable of operation of SIP for subsequent intermediaries to be capable of
inserting such Via header fields, and thus it cannot be prevented. inserting such Via header fields, and thus it cannot be prevented.
As such, though it is desirable, securing Via is not possible through As such, though it is desirable, securing Via is not possible through
the sort of identity mechanism described in this document; the best the sort of identity mechanism described in this document; the best
known practice for securing Via is the use of SIPS. known practice for securing Via is the use of SIPS.
12.3. Malicious Removal of Identity Headers 11.3. Malicious Removal of Identity Headers
In the end analysis, the Identity header cannot protect itself. Any In the end analysis, the Identity header cannot protect itself. Any
attacker could remove the header from a SIP request, and modify the attacker could remove the header from a SIP request, and modify the
request arbitrarily afterwards. However, this mechanism is not request arbitrarily afterwards. However, this mechanism is not
intended to protect requests from men-in-the-middle who interfere intended to protect requests from men-in-the-middle who interfere
with SIP messages; it is intended only to provide a way that the with SIP messages; it is intended only to provide a way that the
originators of SIP requests can prove that they are who they claim to originators of SIP requests can prove that they are who they claim to
be. At best, by stripping identity information from a request, a be. At best, by stripping identity information from a request, a
man-in-the-middle could make it impossible to distinguish any man-in-the-middle could make it impossible to distinguish any
illegitimate messages he would like to send from those messages sent illegitimate messages he would like to send from those messages sent
by an authorized user. However, it requires a considerably greater by an authorized user. However, it requires a considerably greater
amount of energy to mount such an attack than it does to mount amount of energy to mount such an attack than it does to mount
trivial impersonations by just copying someone else's From header trivial impersonations by just copying someone else's From header
field. This mechanism provides a way that an authorized user can field. This mechanism provides a way that an authorized user can
provide a definitive assurance of his identity that an unauthorized provide a definitive assurance of his identity that an unauthorized
user, an impersonator, cannot. user, an impersonator, cannot.
12.4. Securing the Connection to the Authentication Service 11.4. Securing the Connection to the Authentication Service
In the absence of user agent-based authentication services, the In the absence of user agent-based authentication services, the
assurance provided by this mechanism is strongest when a user agent assurance provided by this mechanism is strongest when a user agent
forms a direct connection, preferably one secured by TLS, to an forms a direct connection, preferably one secured by TLS, to an
intermediary-based authentication service. The reasons for this are intermediary-based authentication service. The reasons for this are
twofold: twofold:
If a user does not receive a certificate from the authentication If a user does not receive a certificate from the authentication
service over the TLS connection that corresponds to the expected service over the TLS connection that corresponds to the expected
domain (especially when the user receives a challenge via a domain (especially when the user receives a challenge via a
skipping to change at page 29, line 39 skipping to change at page 30, line 39
constrain UAC behavior, and moreover there will be some deployment constrain UAC behavior, and moreover there will be some deployment
architectures where a direct connection is simply infeasible and the architectures where a direct connection is simply infeasible and the
UAC cannot act as an authentication service itself. Accordingly, UAC cannot act as an authentication service itself. Accordingly,
when a direct connection and TLS are not possible, a UAC should use when a direct connection and TLS are not possible, a UAC should use
the SIPS mechanism, Digest 'auth-int' for body integrity, or both the SIPS mechanism, Digest 'auth-int' for body integrity, or both
when it can. The ultimate decision to add an Identity header to a when it can. The ultimate decision to add an Identity header to a
request lies with the authentication service, of course; domain request lies with the authentication service, of course; domain
policy must identify those cases where the UAC's security association policy must identify those cases where the UAC's security association
with the authentication service is too weak. with the authentication service is too weak.
12.5. Authorization and Transitional Strategies 11.5. Authorization and Transitional Strategies
Ultimately, the worth of an assurance provided by an Identity header Ultimately, the worth of an assurance provided by an Identity header
is limited by the security practices of the authentication service is limited by the security practices of the authentication service
that issues the assurance. Relying on an Identity header generated that issues the assurance. Relying on an Identity header generated
by a remote administrative domain assumes that the issuing domain by a remote administrative domain assumes that the issuing domain
uses recommended administrative practices to authenticate its users. uses recommended administrative practices to authenticate its users.
However, it is possible that some authentication services will However, it is possible that some authentication services will
implement policies that effectively make users unaccountable (e.g., implement policies that effectively make users unaccountable (e.g.,
ones that accept unauthenticated registrations from arbitrary users). ones that accept unauthenticated registrations from arbitrary users).
The value of an Identity header from such authentication services is The value of an Identity header from such authentication services is
skipping to change at page 30, line 42 skipping to change at page 31, line 42
Finally, it is worth noting that the presence or absence of the Finally, it is worth noting that the presence or absence of the
Identity headers cannot be the sole factor in making an authorization Identity headers cannot be the sole factor in making an authorization
decision. Permissions might be granted to a message on the basis of decision. Permissions might be granted to a message on the basis of
the specific verified Identity or really on any other aspect of a SIP the specific verified Identity or really on any other aspect of a SIP
request. Authorization policies are outside the scope of this request. Authorization policies are outside the scope of this
specification, but this specification advises any future specification, but this specification advises any future
authorization work not to assume that messages with valid Identity authorization work not to assume that messages with valid Identity
headers are always good. headers are always good.
12.6. Display-Names and Identity 11.6. Display-Names and Identity
As a matter of interface design, SIP user agents might render the As a matter of interface design, SIP user agents might render the
display-name portion of the From header field of a caller as the display-name portion of the From header field of a caller as the
identity of the caller; there is a significant precedent in email identity of the caller; there is a significant precedent in email
user interfaces for this practice. Securing the display-name user interfaces for this practice. Securing the display-name
component of the From header field value is outside the scope of this component of the From header field value is outside the scope of this
document, but may be the subject of future work, such as through the document, but may be the subject of future work, such as through the
"ppt" name mechanism. "ppt" name mechanism.
In the absence of signing the display-name, authentication services In the absence of signing the display-name, authentication services
might check and validate it, and compare it to a list of acceptable might check and validate it, and compare it to a list of acceptable
display-names that may be used by the sender; if the display-name display-names that may be used by the sender; if the display-name
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 12. IANA Considerations
This document relies on the headers and response codes defined in RFC This document relies on the headers and response codes defined in RFC
4474. It also retains the requirements for the specification of new 4474. It also retains the requirements for the specification of new
algorithms or headers related to the mechanisms described in that algorithms or headers related to the mechanisms described in that
document. document.
13.1. Identity-Info Parameters 12.1. Identity-Info Parameters
The IANA has already created a registry for Identity-Info parameters. The IANA has already created a registry for Identity-Info parameters.
This specification defines a new value called "canon" as defined in This specification defines a new value called "canon" as defined in
Section 6.3. Note however that unlike in RFC4474, Identity-Info Section 6.3. Note however that unlike in RFC4474, Identity-Info
parameters now appear in the Identity header. parameters now appear in the Identity header.
13.2. Identity-Info Algorithm Parameter Values 12.2. Identity-Info Algorithm Parameter Values
The IANA has already created a registry for Identity-Info "alg" The IANA has already created a registry for Identity-Info "alg"
parameter values. This registry is to be populated with a value for parameter values. Note that now, the "alg" parameter appears in the
'RS256', which describes the algorithm used to create the signature Identity header rather than the deprecated Identity-Info header.
that appears in the Identity header. Registry entries must contain Since the algorithms for signing PASSporT objects are defined in
the name of the 'alg' parameter value and the specification in which PASSporT rather than in this specification, there is no longer a need
the value is described. New values for the 'alg' parameter may be for an algorithm parameter registry for the Identity header. This
defined only in Standards Track RFCs. registry is therefore deprecated.
RFC4474 defined the 'rsa-sha1' value for this registry. That value 12.3. Response Codes defined in RFC4474
is hereby deprecated, and should be treated as such. It is not
believed that any implementations are making use of this value.
Future specifications may consider elliptical curves for smaller key RFC4474 defined four response codes for failure conditions specific
sizes. to the Identity header and its original mechanism. These status
codes are retained in this specification, with some modifications.
Note that the Identity-Info header is also deprecated by this The semantics of the 428 'Use Identity Header' response code are
specification, and thus the "alg" parameter is now a value of the slightly altered by the potential presence of the "ppt" parameter.
Identity header, not Identity-Info. Now, a 428 response MUST be sent when an Identity header is required,
but no Identity header without a "ppt" parameter, or with a support
"ppt" value, has been received. In the case where one or more
Identity headers with unsupported "ppt" values have been received,
then a verification service SHOULD send a 428 with the reason phrase
"Use Supported PASSporT Format". Note however that this
specification gives no guidance on how a verification service might
decide to require an Identity header for a particular SIP request.
Such authorization policies are outside the scope of this
specification.
14. Acknowledgments For 436 'Bad Identity-Info' response, the default reason phrase is
now renamed 'Bad Identity info', as the deprecation of the Identity-
Info header has made 'info' a parameter of the Identity header.
Again, given the potential presence of multiple Identity headers,
this response code is sent when the verification service is unable to
deference the URIs and/or acquire the credentials associated with all
Identity headers in the request. This failure code could be
repairable if the authentication service resends the request with an
'info' parameter pointing to a credential that the verification
service can access.
The 437 'Unsupported Certificate' default reason phrase is now
changed to 'Unsupported Credential'. This response is sent when a
verification service can acquire, or already holds, the credential
represented by the 'info' parameter of at least one Identity header
in the request, but does not support said credential(s), for reasons
such as failing to trust the issuing CA, or failing to support the
algorithm with which the credential was signed.
Finally, the 438 'Invalid Identity Header' response now indicates
that of the set of Identity headers in a request, no header with a
valid and supported PASSporT object has been received. Like the 428
response, this is sent by a verification service when its local
policy dictates that a broken signature in an Identity header is
grounds for rejecting a request. Note that in some cases, an
Identity header may be broken for other reasons than that an
originator is attempting to spoof an identity: for example, when a
transit network alters the Date header of the request. Relying on
the full PASSporT object presented through the "canon" parameter can
repair some of these conditions (see Section 5.2.1), so the
recommended way to attempt to repair this failure is to retry the
request with "canon".
13. Acknowledgments
The authors would like to thank Stephen Kent, Brian Rosen, Alex The authors would like to thank Stephen Kent, Brian Rosen, Alex
Bobotek, Paul Kyzviat, Jonathan Lennox, Richard Shockey, Martin Bobotek, Paul Kyzviat, Jonathan Lennox, Richard Shockey, Martin
Dolly, Andrew Allen, Hadriel Kaplan, Sanjay Mishra, Anton Baskov, Dolly, Andrew Allen, Hadriel Kaplan, Sanjay Mishra, Anton Baskov,
Pierce Gorman, David Schwartz, Philippe Fouquart, Michael Hamer, Pierce Gorman, David Schwartz, Eric Burger, Alan Ford, Philippe
Henning Schulzrinne, and Richard Barnes for their comments. Fouquart, Michael Hamer, Henning Schulzrinne, and Richard Barnes for
their comments.
15. Changes from RFC4474 14. Changes from RFC4474
The following are salient changes from the original RFC 4474: The following are salient changes from the original RFC 4474:
Generalized the credential mechanism; credential enrollment, Generalized the credential mechanism; credential enrollment,
acquisition and trust is now outside the scope of this document acquisition and trust is now outside the scope of this document
Reduced the scope of the Identity signature to remove CSeq, Call- Reduced the scope of the Identity signature to remove CSeq, Call-
ID, Contact, and the message body ID, Contact, and the message body
Removed the Identity-Info header and relocated its components into Removed the Identity-Info header and relocated its components into
parameters of the Identity header parameters of the Identity header
Added any DTLS-SRTP fingerprint in SDP as a mandatory element of The Identity header can now appear multiple times in one request
the PASSporT
Deprecated 'rsa-sha1' in favor of new baseline signing algorithm Replaced previous signed-identity-digest format with PASSporT
(signing algorithms now defined there)
Changed the signed-identity-digest format for compatibility with Revised status code descriptions
PASSporT
16. References 15. References
16.1. Normative References 15.1. Normative References
[I-D.ietf-stir-passport] [I-D.ietf-stir-passport]
Wendt, C. and J. Peterson, "Persona Assertion Token", Wendt, C. and J. Peterson, "Persona Assertion Token",
draft-ietf-stir-passport-00 (work in progress), February draft-ietf-stir-passport-02 (work in progress), May 2016.
2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000, DOI 10.17487/RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>. <http://www.rfc-editor.org/info/rfc2818>.
skipping to change at page 33, line 41 skipping to change at page 35, line 30
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>. <http://www.rfc-editor.org/info/rfc5280>.
[RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words
for Use in RFCs to Indicate Requirement Levels", RFC 6919, for Use in RFCs to Indicate Requirement Levels", RFC 6919,
DOI 10.17487/RFC6919, April 2013, DOI 10.17487/RFC6919, April 2013,
<http://www.rfc-editor.org/info/rfc6919>. <http://www.rfc-editor.org/info/rfc6919>.
16.2. Informative References 15.2. Informative References
[I-D.ietf-stir-certificates] [I-D.ietf-stir-certificates]
Peterson, J., "Secure Telephone Identity Credentials: Peterson, J., "Secure Telephone Identity Credentials:
Certificates", draft-ietf-stir-certificates-02 (work in Certificates", draft-ietf-stir-certificates-03 (work in
progress), July 2015. progress), March 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. 73 change blocks. 
247 lines changed or deleted 325 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/