summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8443.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8443.txt')
-rw-r--r--doc/rfc/rfc8443.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc8443.txt b/doc/rfc/rfc8443.txt
new file mode 100644
index 0000000..0be9b8d
--- /dev/null
+++ b/doc/rfc/rfc8443.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) R. Singh
+Request for Comments: 8443 Vencore Labs
+Category: Standards Track M. Dolly
+ISSN: 2070-1721 AT&T
+ S. Das
+ Vencore Labs
+ A. Nguyen
+ Office of Emergency Communications/DHS
+ August 2018
+
+
+ Personal Assertion Token (PASSporT) Extension
+ for Resource Priority Authorization
+
+Abstract
+
+ This document extends the Personal Assertion Token (PASSporT)
+ specification defined in RFC 8225 to allow the inclusion of
+ cryptographically signed assertions of authorization for the values
+ populated in the Session Initiation Protocol (SIP) 'Resource-
+ Priority' header field, which is used for communications resource
+ prioritization.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc8443.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Singh, et al. Standards Track [Page 1]
+
+RFC 8443 PASSporT-ext August 2018
+
+
+Copyright Notice
+
+ Copyright (c) 2018 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (https://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3. PASSporT "rph" Claim . . . . . . . . . . . . . . . . . . . . 4
+ 4. "rph" in SIP . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 4.1. Authentication Service Behavior . . . . . . . . . . . . . 5
+ 4.2. Verification Service Behavior . . . . . . . . . . . . . . 6
+ 5. Further Information Associated with the SIP
+ 'Resource-Priority' Header Field . . . . . . . . . . . . . . 7
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
+ 6.1. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 7
+ 6.2. PASSporT Types . . . . . . . . . . . . . . . . . . . . . 7
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
+ 7.1. Avoidance of Replay and Cut-and-Paste Attacks . . . . . . 8
+ 7.2. Solution Considerations . . . . . . . . . . . . . . . . . 8
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 8.1. Normative References . . . . . . . . . . . . . . . . . . 8
+ 8.2. Informative References . . . . . . . . . . . . . . . . . 9
+ Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
+
+1. Introduction
+
+ PASSporT [RFC8225] is a token format based on JSON Web Token (JWT)
+ [RFC7519] for conveying cryptographically signed information about
+ the identities involved in personal communications. PASSporT with
+ Secure Telephone Identity Revisited (STIR) [RFC8224] provides a
+ mechanism by which an authority on the originating side of a call,
+ using a protocol like SIP [RFC3261], can provide a cryptographic
+ assurance of the validity of the calling party telephone number in
+ order to prevent impersonation attacks.
+
+
+
+
+Singh, et al. Standards Track [Page 2]
+
+RFC 8443 PASSporT-ext August 2018
+
+
+ [RFC4412] defines a mechanism to prioritize access to SIP-signaled
+ resources during periods of communications resource scarcity using
+ the SIP 'Resource-Priority' header. As specified in [RFC4412], the
+ SIP 'Resource-Priority' header field may be used by SIP user agents
+ (UAs) [RFC3261] (including Public Switched Telephone Network (PSTN)
+ gateways and SIP proxy servers) to influence prioritization afforded
+ to communication sessions, including PSTN calls (e.g., to manage
+ scarce network resources during network congestion scenarios).
+ However, the SIP 'Resource-Priority' header field could be spoofed
+ and abused by unauthorized entities, the threat models and use cases
+ of which are described in [RFC7375] and [RFC7340], respectively.
+
+ Compromise of the SIP 'Resource-Priority' header field [RFC4412]
+ could lead to misuse of network resources (i.e., during congestion
+ scenarios), impacting the application services supported using the
+ SIP 'Resource-Priority' header field.
+
+ [RFC8225] allows extensions by which an authority on the originating
+ side verifying the authorization of a particular communication for
+ the SIP 'Resource-Priority' header field can use a PASSPorT claim to
+ cryptographically sign the SIP 'Resource-Priority' header field and
+ convey assertion of the authorization for the SIP 'Resource-Priority'
+ header field. A signed SIP 'Resource-Priority' header field will
+ allow a receiving entity (including entities located in different
+ network domains/boundaries) to verify the validity of assertions
+ authorizing the SIP 'Resource-Priority' header field and to act on
+ the information with confidence that the information has not been
+ spoofed or compromised.
+
+ This specification documents an extension to PASSporT and the
+ associated STIR mechanisms to provide a function to cryptographically
+ sign the SIP 'Resource-Priority' header field. This PASSporT object
+ is used to provide attestation of a calling-user authorization for
+ priority communications. This is necessary in addition to the
+ PASSporT object that is used for calling-user telephone-number
+ attestation. How this extension to PASSporT is used for real-time
+ communications supported using the SIP 'Resource-Priority' header
+ field 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.
+
+
+
+
+
+
+
+
+
+
+Singh, et al. Standards Track [Page 3]
+
+RFC 8443 PASSporT-ext August 2018
+
+
+2. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+ capitals, as shown here.
+
+3. PASSporT "rph" Claim
+
+ This specification defines a new JSON Web Token claim for "rph" that
+ provides an assertion for information in the SIP 'Resource-Priority'
+ header field.
+
+ The creator of a PASSporT object adds a "ppt" value of "rph" to the
+ header of a PASSporT object. The PASSporT claims MUST contain an
+ "rph" claim, and any entities verifying the PASSporT object will be
+ required to understand the "ppt" extension in order to process the
+ PASSporT in question. A PASSPorT header with the "ppt" included will
+ look as follows:
+
+ {
+ "typ":"passport",
+ "ppt":"rph",
+ "alg":"ES256",
+ "x5u":"https://www.example.org/cert.cer"
+ }
+
+ The "rph" claim will provide an assertion of authorization, "auth",
+ for information in the SIP 'Resource-Priority' header field based on
+ [RFC4412]. The syntax is:
+
+ {
+ Resource-Priority = "Resource-Priority" : r-value,
+ r-value = namespace "." r-priority
+ }
+
+ Specifically, the "rph" claim includes an assertion of the priority
+ 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
+ key is associated with a JSON array. These arrays contain strings
+ that correspond to the r-values indicated in the SIP 'Resource-
+ Priority' header field.
+
+
+
+
+
+
+
+
+Singh, et al. Standards Track [Page 4]
+
+RFC 8443 PASSporT-ext August 2018
+
+
+ The following is an example "rph" claim for a SIP 'Resource-Priority'
+ header field with one r-value of "ets.0" and with another r-value of
+ "wps.0":
+
+ {
+ "orig":{"tn":"12155550112"},
+ "dest":{["tn":"12125550113"]},
+ "iat":1443208345,
+ "rph":{"auth":["ets.0", "wps.0"]}
+ }
+
+ After the header and claims PASSporT objects have been constructed,
+ their signature is generated normally per the guidance in [RFC8225]
+ using the full form of PASSPorT. The credentials (i.e., Certificate)
+ used to create the signature must have authority over the namespace
+ of the "rph" claim, and there is only one authority per claim. The
+ authority MUST use its credentials associated with the specific
+ service supported by the resource priority namespace in the claim.
+ If r-values are added or dropped by the intermediaries along the
+ path, the intermediaries must generate a new "rph" header and sign
+ the claim with their own authority.
+
+ The use of the compact form of PASSporT is not specified in this
+ document.
+
+4. "rph" in SIP
+
+ This section specifies SIP-specific usage for the "rph" claim in
+ PASSporT.
+
+4.1. Authentication Service Behavior
+
+ The Authentication Service will create the "rph" claim using the
+ values discussed in Section 3 of this document that are based on
+ [RFC4412]. The construction of the "rph" claim follows the steps
+ described in Section 4.1 of [RFC8224].
+
+ The resulting Identity header for "rph" might look as follows
+ (backslashes shown for line folding only):
+
+ Identity:eyJhbGciOiJFUzI1NiIsInBwdCI6InJwaCIsInR5cCI6InBhc3Nwb3J0\
+ IiwieDV1IjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQo.eyJkZ\
+ XN0Ijp7WyJ0biI6IjEyMTI1NTUwMTEzIl19LCJpYXQiOiIxNDQzMjA4MzQ1Iiwib3\
+ JpZyI6eyJ0biI6IjEyMTU1NTUwMTEyIn0sInJwaCI6eyJhdXRoIjpbImV0cy4wIiw\
+ id3BzLjAiXX19Cg.s37S6VC8HM6Dl6YzJeQDsrZcwJ0lizxhUrA7f_98oWBHvo-cl\
+ -n8MIhoCr18vYYFy3blXvs3fslM_oos2P2Dyw;info=<https://www.example.\
+ org/cert.cer>;alg=ES256;ppt="rph"
+
+
+
+
+Singh, et al. Standards Track [Page 5]
+
+RFC 8443 PASSporT-ext August 2018
+
+
+ A SIP authentication service will derive the value of "rph" from the
+ SIP 'Resource-Priority' header field based on policy associated with
+ service-specific use of r-values, defined as follows in [RFC4412]:
+
+ r-value = namespace "." r-priority
+
+ The authentication service derives the value of the PASSPorT claim by
+ verifying the authorization for the SIP 'Resource-Priority' header
+ field (i.e., verifying a calling-user privilege for the SIP
+ 'Resource-Priority' header field based on its identity). The
+ authorization might be derived from customer-profile data or access
+ to external services.
+
+ [RFC4412] allows multiple "namespace "." priority value" pairs,
+ either in a single SIP 'Resource-Priority' header field or across
+ multiple SIP 'Resource-Priority' header fields. An authority is
+ responsible for signing all the content of a SIP 'Resource-Priority'
+ header field for which it has the authority.
+
+4.2. Verification Service Behavior
+
+ [RFC8224], Section 6.2, Step 5 requires that specifications defining
+ "ppt" values describe any additional verifier behavior. The behavior
+ specified for the "ppt" values of "rph" is as follows:
+
+ The verification service MUST extract the value associated with the
+ "auth" key in a full-form PASSPorT with a "ppt" value of "rph". If
+ the signature validates, then the verification service can use the
+ value of the "rph" claim as validation that the calling party is
+ authorized for SIP 'Resource-Priority' header fields as indicated in
+ the claim. This value would, in turn, be used for priority treatment
+ in accordance with local policy for the associated communication
+ service. If the signature validation fails, the verification service
+ should infer that the calling party is not authorized for SIP
+ 'Resource-Priority' header fields as indicated in the claim. In such
+ cases, the priority treatment for the associated communication
+ service is handled as per the local policy of the verifier. In such
+ scenarios, the SIP 'Resource-Priority' header field SHOULD be
+ stripped from the SIP request, and the network entities should treat
+ the call as an ordinary call.
+
+ In addition, [RFC8224], Section 6.2, Step 4 requires the "iat" value
+ in "rph" claim to be verified.
+
+
+
+
+
+
+
+
+Singh, et al. Standards Track [Page 6]
+
+RFC 8443 PASSporT-ext August 2018
+
+
+ The behavior of a SIP UA upon receiving an INVITE containing a
+ PASSporT object with an "rph" claim will largely remain a matter of
+ implementation policy for the specific communication service. In
+ most cases, implementations would act based on confidence in the
+ veracity of this information.
+
+5. Further Information Associated with the SIP 'Resource-Priority'
+ Header Field
+
+ There may be additional information about the calling party or the
+ call that could be relevant to authorization for the SIP 'Resource-
+ Priority' header field. This may include information related to the
+ device subscription of the caller, to any institutions that the
+ caller or device is associated with, or even to categories of
+ institutions. All of these data elements would benefit from the
+ secure attestations provided by the STIR and PASSporT frameworks.
+ The specification of the "rph" claim could entail the optional
+ presence of one or more such additional information fields applicable
+ to the SIP 'Resource-Priority' header field.
+
+ A new IANA registry has been defined to hold potential values of the
+ "rph" array; see Section 6.2. The definition of the "rph" claim may
+ have one or more such additional information field(s). Details of
+ how an "rph" claim encompasses other data elements are left for
+ future specifications.
+
+6. IANA Considerations
+
+6.1. JSON Web Token Claims
+
+ IANA has added a new claim to the "JSON Web Token Claims" registry as
+ defined in [RFC7519].
+
+ o Claim Name: "rph"
+
+ o Claim Description: Resource Priority Header Authorization
+
+ o Change Controller: IESG
+
+ o Specification Document(s): Section 3 of RFC 8443
+
+6.2. PASSporT Types
+
+ IANA has created a new entry in the "Personal Assertion Token
+ (PASSporT) Extensions" registry for the type "rph", which is
+ specified in this document. In addition, the "PASSporT Resource
+ Priority Header (rph) Types" registry has been created in which each
+ entry must contain two fields: the name of the "rph" type and the
+
+
+
+Singh, et al. Standards Track [Page 7]
+
+RFC 8443 PASSporT-ext August 2018
+
+
+ specification in which the type is described. This registry has been
+ initially populated with the single value for "auth", which is
+ specified in this document. Registration of new "rph" types shall be
+ under the Specification Required policy[RFC8126].
+
+7. Security Considerations
+
+ The security considerations discussed in [RFC8224], Section 12, are
+ applicable here.
+
+7.1. Avoidance of Replay and Cut-and-Paste Attacks
+
+ The PASSporT extension with a "ppt" value of "rph" MUST only be sent
+ with SIP INVITE when the SIP 'Resource-Priority' header field is used
+ to convey the priority of the communication, as defined in [RFC4412].
+ To avoid replay and cut-and-paste attacks, the recommendations
+ provided in Section 12.1 of [RFC8224] MUST be followed.
+
+7.2. Solution Considerations
+
+ Using extensions to PASSporT tokens with a "ppt" value of "rph"
+ requires knowledge of the authentication, authorization, and
+ reputation of the signer to attest to the identity being asserted,
+ including validating the digital signature and the associated
+ certificate chain to a trust anchor. The following considerations
+ should be recognized when using PASSporT extensions with a "ppt"
+ value of "rph":
+
+ o A signer is only allowed to sign the content of a SIP 'Resource-
+ Priority' header field for which it has the proper authorization.
+ Before signing tokens, the signer MUST have a secure method for
+ authentication of the end user or the device being granted a
+ token.
+
+ o The verification of the signature MUST include means of verifying
+ that the signer is authoritative for the signed content of the
+ resource priority namespace in the PASSporT.
+
+8. References
+
+8.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+
+
+
+
+Singh, et al. Standards Track [Page 8]
+
+RFC 8443 PASSporT-ext August 2018
+
+
+ [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+ A., Peterson, J., Sparks, R., Handley, M., and E.
+ Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+ DOI 10.17487/RFC3261, June 2002,
+ <https://www.rfc-editor.org/info/rfc3261>.
+
+ [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource
+ Priority for the Session Initiation Protocol (SIP)",
+ RFC 4412, DOI 10.17487/RFC4412, February 2006,
+ <https://www.rfc-editor.org/info/rfc4412>.
+
+ [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
+ (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
+ <https://www.rfc-editor.org/info/rfc7519>.
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+ 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+ May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+ [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
+ "Authenticated Identity Management in the Session
+ Initiation Protocol (SIP)", RFC 8224,
+ DOI 10.17487/RFC8224, February 2018,
+ <https://www.rfc-editor.org/info/rfc8224>.
+
+ [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
+ Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
+ <https://www.rfc-editor.org/info/rfc8225>.
+
+8.2. Informative References
+
+ [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure
+ Telephone Identity Problem Statement and Requirements",
+ RFC 7340, DOI 10.17487/RFC7340, September 2014,
+ <https://www.rfc-editor.org/info/rfc7340>.
+
+ [RFC7375] Peterson, J., "Secure Telephone Identity Threat Model",
+ RFC 7375, DOI 10.17487/RFC7375, October 2014,
+ <https://www.rfc-editor.org/info/rfc7375>.
+
+ [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+ Writing an IANA Considerations Section in RFCs", BCP 26,
+ RFC 8126, DOI 10.17487/RFC8126, June 2017,
+ <https://www.rfc-editor.org/info/rfc8126>.
+
+
+
+
+
+
+
+Singh, et al. Standards Track [Page 9]
+
+RFC 8443 PASSporT-ext August 2018
+
+
+Acknowledgements
+
+ We would like to thank STIR Working Group members, the ATIS/SIP Forum
+ Task Force on IPNNI members, and the NS/EP Priority Services
+ community for contributions to this problem statement and
+ specification. We would also like to thank David Hancock and Ning
+ Zhang for their valuable inputs.
+
+Authors' Addresses
+
+ Ray P. Singh
+ Vencore Labs
+ 150 Mount Airy Road
+ New Jersey, NJ 07920
+ United States of America
+
+ Email: rsingh@vencorelabs.com
+
+
+ Martin Dolly
+ AT&T
+ 200 Laurel Avenue
+ Middletown, NJ 07748
+ United States of America
+
+ Email: md3135@att.com
+
+ Subir Das
+ Vencore Labs
+ 150 Mount Airy Road
+ New Jersey, NJ 07920
+ United States of America
+
+ Email: sdas@vencorelabs.com
+
+
+ An Nguyen
+ Office of Emergency Communications
+ Department of Homeland Security
+ 245 Murray Lane, Building 410
+ Washington, DC 20528
+ United States of America
+
+ Email: an.p.nguyen@HQ.DHS.GOV
+
+
+
+
+
+
+
+Singh, et al. Standards Track [Page 10]
+