draft-ietf-stir-rph-05.txt   draft-ietf-stir-rph-06.txt 
STIR R. Singh STIR R. Singh
Internet-Draft Vencore Labs Internet-Draft Vencore Labs
Intended status: Standards Track M. Dolly Intended status: Standards Track M. Dolly
Expires: November 5, 2018 AT&T Expires: November 25, 2018 AT&T
S. Das S. Das
Vencore Labs Vencore Labs
A. Nguyen A. Nguyen
Office of Emergency Communication/DHS Office of Emergency Communication/DHS
May 04, 2018 May 24, 2018
PASSporT Extension for Resource Priority Authorization PASSporT Extension for Resource Priority Authorization
draft-ietf-stir-rph-05 draft-ietf-stir-rph-06
Abstract Abstract
This document extends the PASSporT (Personal Assertion Token) This document extends the PASSporT (Personal Assertion Token)
specification defined in [RFC8225] to allow the inclusion of specification defined in [RFC8225] to allow the inclusion of
cryptographically signed assertions of authorization for the values cryptographically signed assertions of authorization for the values
populated in the 'Session Initiation Protocol (SIP) Resource- populated in the 'Session Initiation Protocol (SIP) Resource-
Priority' header field, which is used for communications resource Priority' header field, which is used for communications resource
prioritization. prioritization.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 November 5, 2018. This Internet-Draft will expire on November 25, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. PASSporT 'rph' Claim . . . . . . . . . . . . . . . . . . . . 4 3. PASSporT 'rph' Claim . . . . . . . . . . . . . . . . . . . . 3
4. 'rph' in SIP . . . . . . . . . . . . . . . . . . . . . . . . 5 4. 'rph' in SIP . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Authentication Service Behavior . . . . . . . . . . . . . 5 4.1. Authentication Service Behavior . . . . . . . . . . . . . 5
4.2. Verification Service Behavior . . . . . . . . . . . . . . 6 4.2. Verification Service Behavior . . . . . . . . . . . . . . 5
5. Further Information Associated with 'Resource-Priority' . . . 6 5. Further Information Associated with 'Resource-Priority' . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6.1. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 7 6.1. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 6
6.2. PASSporT Types . . . . . . . . . . . . . . . . . . . . . 7 6.2. PASSporT Types . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7.1. Avoidance of replay and cut and paste attacks . . . . . . 7 7.1. Avoidance of replay and cut and paste attacks . . . . . . 7
7.2. Solution Considerations . . . . . . . . . . . . . . . . . 8 7.2. Solution Considerations . . . . . . . . . . . . . . . . . 7
7.3. Acknowledgements . . . . . . . . . . . . . . . . . . . . 8 7.3. Acknowledgements . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
PASSporT [RFC8225] is a token format based on JSON Web Token (JWT) PASSporT [RFC8225] is a token format based on JSON Web Token (JWT)
[RFC7519] for conveying cryptographically signed information about [RFC7519] for conveying cryptographically signed information about
the identities involved in personal communications; it is used with the identities involved in personal communications. PASSporT with
STIR [RFC8224] to convey a signed assertion of the identity of the STIR [RFC8224] provides a mechanism by which an authority on the
participants in real-time communications established via a protocol originating side of a call via a protocol like SIP [RFC3261] can
like SIP [RFC3261]. This specification extends PASSporT to allow provide a cryptographic assurance of the validity of the calling
cryptographic-signing of the 'SIP Resource-Priority' header field party telephone number in order to prevent impersonation attacks.
[RFC4412], which is used for communications resource prioritization.
[RFC4412] defines the 'SIP Resource-Priority' header field for [RFC4412] defines the 'SIP Resource-Priority' header field for
communications Resource Priority. As specified in [RFC4412], the communications 'Resource-Priority'. As specified in [RFC4412], the
'Resource-Priority' header field may be used by SIP user agents 'SIP Resource-Priority' header field may be used by SIP user agents
[RFC3261], including Public Switched Telephone Network (PSTN) [RFC3261] (including Public Switched Telephone Network (PSTN)
gateways and terminals, and by SIP proxy servers, to influence gateways and SIP proxy servers) to influence prioritization afforded
prioritization afforded to communication sessions, including PSTN to communication sessions including PSTN calls (e.g., to manage
calls (e.g., to manage scarce network resources during network scarce network resources during network congestion scenarios).
congestion scenarios). However, the 'SIP Resource-Priority' header However, the 'SIP Resource-Priority' header field could be spoofed
field could be spoofed and abused by unauthorized entities, the and abused by unauthorized entities, the threat models and use cases
threat models and use cases of which are described in [RFC7375] and of which are described in [RFC7375] and [RFC7340], respectively.
[RFC7340], respectively. Compromise of the 'SIP Resource-Priority'
header field [RFC4412] could lead to misuse of network resource
(i.e., during congestion scenarios) resulting in impacts to the
application services supported using the 'SIP Resource-Priority'
header field.
[RFC8225] provides a mechanism by which an authority on the Compromise of the 'SIP Resource-Priority' header field [RFC4412]
originating side of a call can provide a cryptographic assurance of could lead to misuse of network resource (i.e., during congestion
the validity of the calling party telephone number in order to scenarios) resulting in impacts to the application services supported
prevent impersonation attacks. [RFC8225] also allows extensions using the 'SIP Resource-Priority' header field.
that can be utilized by authorities supporting real-time
communication services using the 'SIP Resource-Priority' header field [RFC8225] allows extensions by which an authority on the originating
to cryptographically sign the 'Resource-Priority' header field and side verifying the authorization of a particular communication for
convey assertion of the authorization for 'Resource-Priority'. For 'SIP Resource-Priority' can use a PASSPorT claim to cryptographically
example, the authority on the originating side verifying the sign the 'SIP Resource-Priority' header field and convey assertion of
authorization of a particular communication for 'SIP Resource- the authorization for 'Resource-Priority'. Signed 'SIP Resource-
Priority' can use a PASSPorT claim to cryptographically sign the Priority' header field will allow a receiving entity (including
'Resource-Priority' header field and convey an assertion of the entities located in different network domains/boundaries) to verify
authorization for 'Resource-Priority'. This will allow a receiving the validity of assertions authorizing 'Resource-Priority' and to act
entity (including entities located in different network domains/ on the information with confidence that the information has not been
boundaries) to verify the validity of assertions authorizing spoofed or compromised.
'Resource-Priority'. Cryptographically signed 'SIP Resource-
Priority' header field will allow a receiving entity to verify and
act on the information with confidence that the information has not
been spoofed or compromised.
This specification documents an extension to PASSporT and the This specification documents an extension to PASSporT and the
associated STIR mechanisms to provide a function to sign the 'SIP associated STIR mechanisms to provide a function to cryptographically
Resource-Priority' header field. This PASSporT object is used to sign the 'SIP Resource-Priority' header field. This PASSporT object
provide attestation of a calling user authorization for priority is used to provide attestation of a calling user authorization for
communications. This is necessary in addition to the PASSporT object priority communications. This is necessary in addition to the
that is used for calling user telephone number attestation. How this PASSporT object that is used for calling user telephone number
extension to PASSporT is used for real-time communications supported attestation. How this extension to PASSporT is used for real-time
using 'SIP Resource-Priority' header field is outside the scope of communications supported using 'SIP Resource-Priority' header field
this document. is outside the scope of this document. In addition, the PASSPorT
extension defined in this document is intended for use in
environments where there are means to verify that the signer of the
'SIP Resource-Priority' header field is authoritative.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119] and document are to be interpreted as described in RFC 2119 [RFC2119] and
in RFC 8174 [RFC8174]. in RFC 8174 [RFC8174].
3. PASSporT 'rph' Claim 3. PASSporT 'rph' Claim
skipping to change at page 4, line 34 skipping to change at page 4, line 21
The "rph" claim will provide an assertion of authorization, "auth", The "rph" claim will provide an assertion of authorization, "auth",
for information in the 'SIP Resource-Priority' header field based on for information in the 'SIP Resource-Priority' header field based on
[RFC4412] and the syntax is: [RFC4412] and the syntax is:
{ {
Resource-Priority = "Resource-Priority" : r-value, Resource-Priority = "Resource-Priority" : r-value,
r-value= namespace "." r-priority r-value= namespace "." r-priority
} }
Specifically, the "rph" claim includes assertion of the priority- Specifically, the "rph" claim includes an assertion of the priority-
level of the user to be used for a given communication session. The level of the user to be used for a given communication session. The
value of the "rph" claim is an Object with one or more keys. Each value of the "rph" claim is an Object with one or more keys. Each
key is associated with a JSON Array. These arrays contain Strings key is associated with a JSON Array. These arrays contain Strings
that correspond to the r-values indicated in the 'SIP Resource- that correspond to the r-values indicated in the 'SIP Resource-
Priority' header field. Priority' header field.
The following is an example "rph" claim for a 'SIP Resource-Priority' The following is an example "rph" claim for a 'SIP Resource-Priority'
header field with a r-value of "ets.0" and with another r-value of header field with one r-value of "ets.0" and with another r-value of
"wps.0". "wps.0":
{ {
"orig":{"tn":"12155550112"}, "orig":{"tn":"12155550112"},
"dest":{["tn":"12125550113"]}, "dest":{["tn":"12125550113"]},
"iat":1443208345, "iat":1443208345,
"rph":{"auth":["ets.0", "wps.0"]} "rph":{"auth":["ets.0", "wps.0"]}
} }
After the header and claims PASSporT objects have been constructed, After the header and claims PASSporT objects have been constructed,
their signature is generated normally per the guidance in [RFC8225] their signature is generated normally per the guidance in [RFC8225]
skipping to change at page 6, line 29 skipping to change at page 6, line 15
This value would in turn be used for priority treatment in accordance This value would in turn be used for priority treatment in accordance
with local policy for the associated communication service. If the with local policy for the associated communication service. If the
signature validation fails, the verification service should infer signature validation fails, the verification service should infer
that the calling party is not authorized for 'SIP Resource-Priority' that the calling party is not authorized for 'SIP Resource-Priority'
as indicated in the claim. In such cases, the priority treatment for as indicated in the claim. In such cases, the priority treatment for
the associated communication service is handled as per the local the associated communication service is handled as per the local
policy of the verifier. In such scenarios, 'SIP Resource-Priority' policy of the verifier. In such scenarios, 'SIP Resource-Priority'
header field SHOULD be stripped from SIP request and the network header field SHOULD be stripped from SIP request and the network
entities should treat the call as an ordinary call. entities should treat the call as an ordinary call.
In addition, [RFC8224] Section 6.2 Step 4 requires "iat" value in In addition, [RFC8224] Section 6.2 Step 4 requires the "iat" value in
"rph" claim to be verified. "rph" claim to be verified.
The behavior of a SIP UA upon receiving an INVITE containing a The behavior of a SIP UA upon receiving an INVITE containing a
PASSporT object with a "rph" claim will largely remain a matter of PASSporT object with a "rph" claim will largely remain a matter of
implementation policy for the specific communication service. In implementation policy for the specific communication service. In
most cases, implementations would act based on confidence in the most cases, implementations would act based on confidence in the
veracity of this information. veracity of this information.
5. Further Information Associated with 'Resource-Priority' 5. Further Information Associated with 'Resource-Priority'
skipping to change at page 7, line 47 skipping to change at page 7, line 31
7. Security Considerations 7. Security Considerations
The security considerations discussed in [RFC8224] in Section 12 are The security considerations discussed in [RFC8224] in Section 12 are
applicable here. applicable here.
7.1. Avoidance of replay and cut and paste attacks 7.1. Avoidance of replay and cut and paste attacks
The PASSporT extension with a "ppt" value of "rph" MUST only be sent The PASSporT extension with a "ppt" value of "rph" MUST only be sent
with SIP INVITE when 'Resource-Priority' header field is used to with SIP INVITE when 'Resource-Priority' header field is used to
convey the priority of the communication as defined in [RFC4412]. To convey the priority of the communication as defined in [RFC4412]. To
avoid replay, and cut and paste attacks, the recommenations provided avoid replay, and cut and paste attacks, the recommendations provided
in Section 12.1 of [RFC8224] MUST be followed. in Section 12.1 of [RFC8224] MUST be followed.
7.2. Solution Considerations 7.2. Solution Considerations
Using extensions to PASSporT tokens with a "ppt" value of "rph" Using extensions to PASSporT tokens with a "ppt" value of "rph"
requires knowledge of the authentication, authorization, and requires knowledge of the authentication, authorization, and
reputation of the signer to attest to the identity being asserted, reputation of the signer to attest to the identity being asserted,
including validating the digital signature and the associated including validating the digital signature and the associated
certificate chain to a trust anchor. The following considerations certificate chain to a trust anchor. The following considerations
should be recognized when using PASSporT extensions with a "ppt" should be recognized when using PASSporT extensions with a "ppt"
 End of changes. 16 change blocks. 
61 lines changed or deleted 54 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/