draft-ietf-stir-rph-00.txt   draft-ietf-stir-rph-01.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: January 1, 2018 AT&T Expires: March 18, 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
June 30, 2017 September 14, 2017
PASSporT Extension for Resource-Priority Authorization PASSporT Extension for Resource-Priority Authorization
draft-ietf-stir-rph-00 draft-ietf-stir-rph-01
Abstract Abstract
This document extends the PASSporT object to convey This document extends the PASSporT object to convey
cryptographically-signed assertions of authorization for cryptographically-signed assertions of authorization for
communications 'Resource-Priority'. It extends PASSporT to allow communications 'Resource-Priority'. It extends PASSporT to allow
cryptographic-signing of the SIP 'Resource-Priority" header field cryptographic-signing of the SIP 'Resource-Priority" header field
which is used for communications resource prioritization. It also which is used for communications resource prioritization. It also
describes how the PASSPorT extension is used in SIP signaling to describes how the PASSPorT extension is used in SIP signaling to
convey assertions of authorization of the information in the SIP convey assertions of authorization of the information in the SIP
'Resource-Priority' header field. 'Resource-Priority' header field.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 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 January 1, 2018. This Internet-Draft will expire on March 18, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (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 . . . . . . . . . . . . . . . . . . . . 3 3. PASSporT 'rph' Claim . . . . . . . . . . . . . . . . . . . . 3
4. 'rph' in SIP . . . . . . . . . . . . . . . . . . . . . . . . 4 4. 'rph' in SIP . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Authentication Service Behavior . . . . . . . . . . . . . 4 4.1. Authentication Service Behavior . . . . . . . . . . . . . 4
4.2. Verification Service Behavior . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6.1. JSON Web Token Claims Registration . . . . . . . . . . . 6 6.1. JSON Web Token Claims Registration . . . . . . . . . . . 6
6.2. PASSporT RPH Types . . . . . . . . . . . . . . . . . . . 6 6.2. PASSporT 'rph' Types . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7.1. Avoidance of replay and cut and past attacks . . . . . . 7 7.1. Avoidance of replay and cut and past attacks . . . . . . 7
7.2. Solution Considerations . . . . . . . . . . . . . . . . . 7 7.2. Solution Considerations . . . . . . . . . . . . . . . . . 7
7.3. Acknowledgements . . . . . . . . . . . . . . . . . . . . 7 7.3. Acknowledgements . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
PASSporT [I-D.ietf-stir-passport] is a token format based on JWT PASSporT [I-D.ietf-stir-passport] is a token format based on 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; it is used with
STIR [I-D.ietf-stir-rfc4474bis] to convey a signed assertion of the STIR [I-D.ietf-stir-rfc4474bis] to convey a signed assertion of the
identity of the participants in real-time communications established identity of the participants in real-time communications established
skipping to change at page 3, line 28 skipping to change at page 3, line 28
convey an assertion of the authorization for 'Resource-Priority'. convey an assertion of the authorization for 'Resource-Priority'.
This will allow a receiving entity (including entities located in This will allow a receiving entity (including entities located in
different network domains/boundaries) to verify the validity of different network domains/boundaries) to verify the validity of
assertions authorizating Resource-Priority. Cryptographically-signed assertions authorizating Resource-Priority. Cryptographically-signed
SIP 'Resource-Priority' headers will allow a receiving entity to SIP 'Resource-Priority' headers will allow a receiving entity to
verify and act on the information with confidence that the verify and act on the information with confidence that the
information have not been spoofed or compromised. information have not been spoofed or compromised.
This specification documents an optional extension to PASSporT and This specification documents an optional extension to PASSporT and
the associated STIR mechanisms to provide a function to sign the SIP the associated STIR mechanisms to provide a function to sign the SIP
'Resource-Priority' header field. How the optional extension to 'Resource-Priority' header field. This PASSporT object is used to
PASSporT is used for real-time communications supported using SIP provide attestation of a calling user authorization for priority
'Resource-Priority' header field is defined in other documents and is communications. This is necessary in addition to the PASSporT object
outside the scope of this document. that is used for calling user telephone number attestation. How the
optional extension to PASSporT is used for real-time communications
supported using SIP 'Resource-Priority' header field is defined in
other documents and is outside the scope of this document.
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]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. PASSporT 'rph' Claim 3. PASSporT 'rph' Claim
This specification defines a new JSON Web Token claim for "rph", This specification defines a new JSON Web Token claim for "rph",
skipping to change at page 6, line 30 skipping to change at page 6, line 30
call that could be relevant to authorization for Resource-Priority. call that could be relevant to authorization for Resource-Priority.
This may include information related to the device subscription of This may include information related to the device subscription of
the caller, or to any institutions that the caller or device is the caller, or to any institutions that the caller or device is
associated with, or even categories of institutions. All of these associated with, or even categories of institutions. All of these
data elements would benefit from the secure attestations provided by data elements would benefit from the secure attestations provided by
the STIR and PASSporT frameworks. The specification of the "rph" the STIR and PASSporT frameworks. The specification of the "rph"
claim could entail the optional presence of one or more such claim could entail the optional presence of one or more such
additional information fields. additional information fields.
A new IANA registry has been defined to hold potential values of the A new IANA registry has been defined to hold potential values of the
"rph" array; see Section 8.3. Details of extensions to the "rph" "rph" array; see Section 6.2. The definition of the "rph" claim may
claim to encompass other data elements are left for future version of have one or more such additional information field(s). Details of
this specification. such "rph" claim to encompass other data elements are left for future
version of this specification.
6. IANA Considerations 6. IANA Considerations
6.1. JSON Web Token Claims Registration 6.1. JSON Web Token Claims Registration
o Claim Name: "rph" o Claim Name: "rph"
o Claim Description: Resource Priority Header o Claim Description: Resource Priority Header
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 3 of [RFCThis] o Specification Document(s): Section 3 of [RFCThis]
6.2. PASSporT RPH Types 6.2. PASSporT 'rph' Types
This document requests that the IANA create a new registry for
PASSporT RPH types. Registration of new PASSporT RPH types shall be
under the specification required policy.
This registry is to be initially populated with a single value for This document requests that the IANA add a new entry to the PASSporT
"namespace" which is specified in [RFCThis]. Types registry for the type "rph" which is specified in [RFCThis].
This specification also requests that the IANA create a new registry
for PASSporT "rph" types. Registration of new PASSporT "rph" types
shall be under the specification required policy. This registry is
to be initially populated with a single value for "auth" which is
specified in [RFCThis].
7. Security Considerations 7. Security Considerations
The security considerations discussed in [I-D.ietf-stir-rfc4474bis] The security considerations discussed in [I-D.ietf-stir-rfc4474bis]
in Section 10 are applicable here. in Section 10 are applicable here.
7.1. Avoidance of replay and cut and past attacks 7.1. Avoidance of replay and cut and past 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 is used to convey the with SIP INVITE when 'Resource-Priority' header is used to convey the
priority of the communication as defined in [RFC4412]. To avoid the priority of the communication as defined in [RFC4412]. To avoid the
replay, and cut and paste attacks, the procedures described in replay, and cut and paste attacks, the procedures described in
Section 10.1 of [I-D.ietf-stir-rfc4474bis] MUST be followed. Section 10.1 of [I-D.ietf-stir-rfc4474bis] MUST be followed.
7.2. Solution Considerations 7.2. Solution Considerations
The use of extension to PASSporT tokens with ppt value rph based on The use of extension to PASSporT tokens with "ppt" value "rph" based
the validation of the digital signature and the associated on the validation of the digital signature and the associated
certificate requires consideration of the authentication and certificate requires consideration of the authentication and
authority or reputation of the signer to attest to the identity being authority or reputation of the signer to attest to the identity being
asserted. The following considerations should be recognized when asserted. The following considerations should be recognized when
using PASSporT extension with "ppt" value of "rph": using PASSporT extension with "ppt" value of "rph":
o An authority (signer) is only allowed to sign the content of a SIP o An authority (signer) is only allowed to sign the content of a SIP
'Resource-Priority' header for which it has the right authority. 'Resource-Priority' header for which it has the right authority.
The authority that signs the token MUST have a secure method for The authority that signs the token MUST have a secure method for
authentication of the end user or the device. authentication of the end user or the device.
 End of changes. 13 change blocks. 
24 lines changed or deleted 29 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/