draft-ietf-stir-passport-05.txt   draft-ietf-stir-passport-06.txt 
STIR C. Wendt STIR C. Wendt
Internet-Draft Comcast Internet-Draft Comcast
Intended status: Standards Track J. Peterson Intended status: Standards Track J. Peterson
Expires: January 23, 2017 Neustar Inc. Expires: February 23, 2017 Neustar Inc.
July 22, 2016 August 22, 2016
Persona Assertion Token Persona Assertion Token
draft-ietf-stir-passport-05 draft-ietf-stir-passport-06
Abstract Abstract
This document defines a token format for verifying with non- This document defines a canonical string object or 'token' for
repudiation the sender of and authorization to send information verifying with non-repudiation the author of the token, their
related to the originator of personal communications. A authority to author the token and, minimally, the asserted
cryptographic signature is defined to protect the integrity of the originating identity or persona contained within the token
information used to identify the originator of a personal corresponding specifically to the originator of 'personal
communications session (e.g. the telephone number or URI) and verify communications', or any signalled communications between a set of
the accuracy of this information at the destination. The parties with identities. A cryptographic signature is defined to
cryptographic signature is defined with the intention that it can protect the integrity of the information used to identify the
confidently verify the originating persona even when the signature is originator of a personal communications session (e.g. the telephone
sent to the destination party over an unsecure channel. The Persona number or URI) and verify the assertion of the identity information
Assertion Token (PASSporT) is particularly useful for many personal at the destination. The cryptographic signature is defined with the
communications applications over IP networks and other multi-hop intention that it can confidently verify the originating persona even
interconnection scenarios where the originating and destination when the signature is sent to the destination party over an insecure
parties may not have a direct trusted relationship. channel. The Persona Assertion Token (PASSporT) is particularly
useful for many personal communications applications over IP networks
and other multi-hop interconnection scenarios where the originating
and destination parties may not have a direct trusted relationship.
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 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 January 23, 2017. This Internet-Draft will expire on February 23, 2017.
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
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Token Overview . . . . . . . . . . . . . . . . . . . . . . . 4 2. PASSporT Token Overview . . . . . . . . . . . . . . . . . . . 3
3. PASSporT Definition . . . . . . . . . . . . . . . . . . . . . 4 3. PASSporT Components . . . . . . . . . . . . . . . . . . . . . 4
3.1. PASSporT Header . . . . . . . . . . . . . . . . . . . . . 4 3.1. PASSporT Header . . . . . . . . . . . . . . . . . . . . . 4
3.1.1. "typ" (Type) Header Parameter . . . . . . . . . . . . 4 3.1.1. "typ" (Type) Header Parameter . . . . . . . . . . . . 4
3.1.2. "alg" (Algorithm) Header Parameter . . . . . . . . . 5 3.1.2. "alg" (Algorithm) Header Parameter . . . . . . . . . 4
3.1.3. "x5u" (X.509 URL) Header Parameter . . . . . . . . . 5 3.1.3. "x5u" (X.509 URL) Header Parameter . . . . . . . . . 4
3.2. PASSporT Payload . . . . . . . . . . . . . . . . . . . . 5 3.2. PASSporT Payload . . . . . . . . . . . . . . . . . . . . 5
3.2.1. JWT defined claims . . . . . . . . . . . . . . . . . 5 3.2.1. JWT defined claims . . . . . . . . . . . . . . . . . 5
3.2.1.1. "iat" - Issued at claim . . . . . . . . . . . . . 5 3.2.1.1. "iat" - Issued At claim . . . . . . . . . . . . . 5
3.2.2. PASSporT specific claims . . . . . . . . . . . . . . 6 3.2.2. PASSporT specific claims . . . . . . . . . . . . . . 5
3.2.2.1. Originating and Destination Identity Claims . . . 6 3.2.2.1. Originating and Destination Identity Claims . . . 5
3.2.2.2. "mky" - Media Key claim . . . . . . . . . . . . . 7 3.2.2.2. "mky" - Media Key claim . . . . . . . . . . . . . 7
3.3. PASSporT Signature . . . . . . . . . . . . . . . . . . . 8 3.3. PASSporT Signature . . . . . . . . . . . . . . . . . . . 8
4. Extending PASSporT . . . . . . . . . . . . . . . . . . . . . 8 4. Extending PASSporT . . . . . . . . . . . . . . . . . . . . . 8
4.1. "ppt" (PASSporT) header parameter . . . . . . . . . . . . 8 4.1. "ppt" (PASSporT) header parameter . . . . . . . . . . . . 8
4.2. Extended PASSporT Claims . . . . . . . . . . . . . . . . 9 4.2. Extended PASSporT Claims . . . . . . . . . . . . . . . . 9
5. Deterministic JSON Serialization . . . . . . . . . . . . . . 9 5. Deterministic JSON Serialization . . . . . . . . . . . . . . 9
5.1. Example PASSport deterministic JSON form . . . . . . . . 10 5.1. Example PASSport deterministic JSON form . . . . . . . . 10
6. Human Readability . . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6.1. Avoidance of replay and cut and paste attacks . . . . . . 10
7.1. Avoidance of replay and cut and paste attacks . . . . . . 10 6.2. Solution Considerations . . . . . . . . . . . . . . . . . 10
7.2. Solution Considerations . . . . . . . . . . . . . . . . . 11 6.3. Privacy Considerations . . . . . . . . . . . . . . . . . 11
7.3. Privacy Considerations . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7.1. Media Type Registration . . . . . . . . . . . . . . . . . 11
8.1. Media Type Registration . . . . . . . . . . . . . . . . . 11 7.1.1. Media Type Registry Contents Additions Requested . . 11
8.1.1. Media Type Registry Contents Additions Requested . . 11 7.2. JSON Web Token Claims Registration . . . . . . . . . . . 12
8.2. JSON Web Token Claims Registration . . . . . . . . . . . 13 7.2.1. Registry Contents Additions Requested . . . . . . . . 12
8.2.1. Registry Contents Additions Requested . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 14 Appendix A. Example PASSporT JWS Serialization and Signature . . 14
Appendix A. Example PASSporT JWS Serialization and Signature . . 15
A.1. X.509 Private Key Certificate for Example . . . . . . . . 16 A.1. X.509 Private Key Certificate for Example . . . . . . . . 16
A.2. X.509 Public Key Certificate for Example . . . . . . . . 17 A.2. X.509 Public Key Certificate for Example . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
In today's IP-enabled telecommunications world, there is a growing In today's IP-enabled telecommunications world, there is a growing
concern about the ability to trust incoming invitations for concern about the ability to trust incoming invitations for
communications sessions, including video, voice and messaging. communications sessions, including video, voice and messaging.
[RFC7340] As an example, modern telephone networks provide the [RFC7340] As an example, modern telephone networks provide the
ability to spoof the calling party telephone number for many ability to spoof the calling party telephone number for many
legitimate purposes including providing network features and services legitimate purposes including providing network features and services
on the behalf of a legitimate telephone number. However, as we have on the behalf of a legitimate telephone number. However, as we have
seen, bad actors have taken advantage of this ability for seen, bad actors have taken advantage of this ability for
illegitimate and fraudulent purposes meant to trick telephone users illegitimate and fraudulent purposes meant to trick telephone users
to believe they are someone they are not. This problem can be to believe they are someone they are not. This problem can be
extended to many emerging forms of personal communications. extended to many emerging forms of personal communications.
This document defines a common method for creating and validating a This document defines a method for creating and validating a token
token that cryptographically verifies an originating identity, or that cryptographically verifies an originating identity, or more
more generally a URI or application specific identity string generally a URI or telephone number representing the originator of
representing the originator of personal communications. Through personal communications. Through extensions defined in this
extended profiles other information relevant to the personal document, other information relevant to the personal communications
communications can also be attached to the token. The primary goal can also be added to the token. The goal of PASSporT is to provide a
of PASSporT is to provide a common framework for signing persona common framework for signing originating identity related information
related information in an extensible way. A secondary goal is to in an extensible way. Additionally, this functionality is
provide this functionality independent of any specific personal independent of any specific personal communications signaling call
communications signaling call logic, so that creation and logic, so that the assertion of originating identity related
verification of persona information can be implemented in a flexible information can be implemented in a flexible way and can be used in
way and can be used in many personal communications applications applications including end-to-end applications that require different
including end-to-end applications that require different signaling signaling protocols or gateways between different communications
protocols. It is anticipated that signaling protocol specific systems. It is anticipated that signaling protocol specific guidance
guidance will be provided in other related documents and will be provided in other related documents and specifications to
specifications to specify how to use and transport PASSporT tokens, specify how to use and transport PASSporT tokens, however this is
however this is intentionally out of scope for this document. intentionally out of scope for this document.
Note: As of the authoring of this document, Note: As of the authoring of this document,
[I-D.ietf-stir-rfc4474bis] provides details of how to use PASSporT [I-D.ietf-stir-rfc4474bis] provides details of how to use PASSporT
within SIP signaling for the signing and verification of telephone within SIP signaling for the signing and verification of telephone
numbers. numbers.
2. Token Overview 2. PASSporT Token Overview
Tokens are a convenient way of encapsulating information with JSON Web Token (JWT) [RFC7519] and JSON Web Signature (JWS) [RFC7515]
associated digital signatures. They are used in many applications and related specifications define a standard token format that can be
that require authentication, authorization, encryption, non- used as a way of encapsulating claimed or asserted information with
repudiation and other use cases. JSON Web Token (JWT) [RFC7519] and an associated digital signature using X.509 based certificates. JWT
JSON Web Signature (JWS) [RFC7515] are designed to provide a compact provides a set of claims in JSON format that can conveniently
form for many of these purposes and define a specific method and accomidate asserted originating identity information and is easily
syntax for signing a specific set of information or "claims" within extensible for extension mechanisms defined below. Additionally, JWS
the token and therefore providing an extensible set of claims. provides a path for updating methods and cryptographic algorithms
Additionally, JWS provides extensible mechanisms for specifying the used for the associated digital signatures.
method and cryptographic algorithms used for the associated digital
signatures.
3. PASSporT Definition 3. PASSporT Components
The PASSporT is constructed based on JWT [RFC7519] and JWS [RFC7515] The PASSporT is constructed based on JWT [RFC7519] and JWS [RFC7515]
specifications. JWS defines the use of JSON data structures in a specifications. JWS defines the use of JSON data structures in a
specified canonical format for signing data corresponding to JOSE specified canonical format for signing data corresponding to JOSE
header, JWS Payload, and JWS Signature. JWT defines specific set of header, JWS Payload, and JWS Signature. JWT defines specific set of
claims that are represented by specified key value pairs which can be claims that are represented by specified key value pairs which can be
extended with custom keys for specific applications. extended with custom keys for specific applications.
3.1. PASSporT Header 3.1. PASSporT Header
The JWS token header is a JOSE header [RFC7515] that defines the type The JWS token header is a JOSE header [RFC7515] that defines the type
and encryption algorithm used in the token. and encryption algorithm used in the token.
An example of the header for the case of an ECDSA P-256 digital PASSporT header should include, at a minimum, the following header
signature would be the following, parameters defined the the next three subsections.
{
"typ":"passport",
"alg":"ES256",
"x5u":"https://cert.example.org/passport.cer"
}
3.1.1. "typ" (Type) Header Parameter 3.1.1. "typ" (Type) Header Parameter
JWS defines the "typ" (Type) Header Parameter to declare the media JWS defines the "typ" (Type) Header Parameter to declare the media
type of the JWS. type of the JWS.
For PASSporT Token the "typ" header MUST minimally include and begin For PASSporT Token the "typ" header MUST be the string "passport".
with "passport". This represents that the encoded token is a JWT of This represents that the encoded token is a JWT of type passport.
type passport.
3.1.2. "alg" (Algorithm) Header Parameter 3.1.2. "alg" (Algorithm) Header Parameter
For PASSporT, the "alg" should be defined as follows, for the For PASSporT, the "alg" should be defined as follows, for the
creation and verification of PASSporT tokens and their digital creation and verification of PASSporT tokens and their digital
signatures ES256 MUST be implemented. signatures ES256 MUST be implemented.
Note that JWA [RFC7518] defines other algorithms that may be utilized Note that JWA [RFC7518] defines other algorithms that may be utilized
or updated in the future depending on cryptographic strength or updated in the future depending on cryptographic strength
requirements guided by current security best practice. requirements guided by current security best practice.
3.1.3. "x5u" (X.509 URL) Header Parameter 3.1.3. "x5u" (X.509 URL) Header Parameter
As defined in JWS, the "x5u" header parameter is used to provide a As defined in JWS, the "x5u" header parameter is used to provide a
URI [RFC3986] referring to the resource for the X.509 public key URI [RFC3986] referring to the resource for the X.509 public key
certificate or certificate chain [RFC5280] corresponding to the key certificate or certificate chain [RFC5280] corresponding to the key
used to digitally sign the JWS. Note: The definition of what the URI used to digitally sign the JWS. Generally this would correspond to
represents in terms of the actor serving the X.509 public key is out an HTTPS or DNSSEC resource with the guidance that it MUST be TLS
of scope of this document. However, generally this would correspond protected, per JWS spec.
to an HTTPS or DNSSEC resource with the guidance that it MUST be a
TLS protected, per JWS spec. An example of the header, would be the following,
{
"typ":"passport",
"alg":"ES256",
"x5u":"https://cert.example.org/passport.cer"
}
3.2. PASSporT Payload 3.2. PASSporT Payload
The token payload claims should consist of the information which The token claims consist of the information which needs to be
needs to be verified at the destination party. This claim should verified at the destination party. These claims follow the
correspond to a JWT claim [RFC7519] and be encoded as defined by the definition of a JWT claim [RFC7519] and be encoded as defined by the
JWS Payload [RFC7515] JWS Payload [RFC7515].
The PASSporT defines the use of a number of standard JWT defined PASSporT defines the use of a standard JWT defined claim as well as
headers as well as two new custom headers corresponding to the two custom claims corresponding to the two parties associated with
parties associated with personal communications, the originator and personal communications, the originator and destination as detailed
terminator. These headers or key value pairs are detailed below. below.
Key values outside the US-ASCII range should be encoded using percent Key values outside the US-ASCII range should be encoded using percent
encoding as described in section 2.1 of RFC 3986, case normalized as encoding as described in section 2.1 of [RFC3986], case normalized as
described in 6.2.2.1 of [RFC3986]. Matching of these values should described in 6.2.2.1 of [RFC3986]. Matching of these values should
use string exact match. use string exact match.
3.2.1. JWT defined claims 3.2.1. JWT defined claims
3.2.1.1. "iat" - Issued at claim 3.2.1.1. "iat" - Issued At claim
The JSON claim MUST include the "iat" [RFC7519] defined claim issued The JSON claim MUST include the "iat" [RFC7519] Section 4.1.6 defined
at. As defined this should be set to a date cooresponding to the claim Issued At. As defined this should be set to the date and time
origination of the personal communications. The time value should be of the origination of the personal communications. The time value
of the format defined in [RFC7519] Section 2 NumericDate. This is should be of the format defined in [RFC7519] Section 2 NumericDate.
included for securing the token against replay and cut and paste This is included for securing the token against replay and cut and
attacks, as explained further in the security considerations in paste attacks, as explained further in the security considerations in
section 7. section 6.
3.2.2. PASSporT specific claims 3.2.2. PASSporT specific claims
3.2.2.1. Originating and Destination Identity Claims 3.2.2.1. Originating and Destination Identity Claims
Baseline PASSporT defines claims that convey the identity of the PASSporT defines claims that convey the identity of the origination
origination and destination of personal communications. There are and destination of personal communications. There are two claims
two claims that are required for PASSporT, the "orig" and "dest" that are required for PASSporT, the "orig" and "dest" claims. Both
claims. Both "orig" and "dest" should have values that are JSON "orig" and "dest" MUST have claims where the key represents an
objects that include identities represented by key value pairs, where identity type and the value is the identity string, both defined in
the key represents an identity type and the value is the identity subsecquent subsections. Currently, these identities can be
string. Currently, these identities can be represented as either represented as either telephone numbers or Uniform Resource
telephone numbers or Uniform Resource Indicators (URIs). The Indicators (URIs).
definition of how telephone numbers or URIs and examples are provided
below.
The "orig" JSON object MUST only have one key value pair representing The "orig" JSON object MUST only have one key value pair representing
the asserted identity of any type (currently either "tn" or "uri") of the asserted identity of any type (currently either "tn" or "uri") of
the originator of the personal communications signaling. the originator of the personal communications signaling.
The "dest" JSON object MUST have at least have one key value pair, The "dest" JSON object MUST have at least have one key value pair,
but could have multiple identity types (i.e. "tn" and/or "uri") but but could have multiple identity types (i.e. "tn" and/or "uri") but
only one of each. Additionaly, in the case of "dest" only, the only one of each. Additionaly, in the case of "dest" only, the
identity type key value MUST be an array signaled by standard JSON identity type key value MUST be an array signaled by standard JSON
brackets, even when there is a single identity value in the identity brackets, even when there is a single identity value in the identity
type key value. type key value.
3.2.2.1.1. "tn" - Telephone Number identity 3.2.2.1.1. "tn" - Telephone Number identity
If the originating or destination identity is a telephone number, the If the originating or destination identity is a telephone number, the
key representing the identity should be "tn". key representing the identity MUST be "tn".
Telephone Number strings for "tn" MUST be canonicalized according to Telephone Number strings for "tn" MUST be canonicalized according to
the procedures specified in [I-D.ietf-stir-rfc4474bis] Section 7.2. the procedures specified in [I-D.ietf-stir-rfc4474bis] Section 7.2.
3.2.2.1.2. "uri" - URI identity 3.2.2.1.2. "uri" - URI identity
If any of the originating or destination identities is of the form If any of the originating or destination identities is of the form
URI, as defined in [RFC3986], the key representing the identity URI, as defined in [RFC3986], the key representing the identity MUST
should be "uri" URI form of the identity. be "uri" URI form of the identity.
3.2.2.1.3. Future identity forms 3.2.2.1.3. Future identity forms
We recognize that in the future there may be other standard We recognize that in the future there may be other standard
mechanisms for representing identities. The "orig" and "dest" JSON mechanisms for representing identities. The "orig" and "dest" claims
objects with "tn" and "uri" allow for other identity types with currently support "tn" and "uri" but could be extended in the future
unique keys to represent these forms. to allow for other identity types with new IANA registered unique
types to represent these forms.
3.2.2.1.4. Examples 3.2.2.1.4. Examples
Single Originator to Single Destination example: Single Originator, with telephone number identity +12155551212, to
Single Destination, with URI identity 'sip:alice@example.com',
example:
{ {
"dest":{"uri":["sip:alice@example.com"]}, "dest":{"uri":["sip:alice@example.com"]},
"iat":"1443208345", "iat":"1443208345",
"orig":{"tn":"12155551212"} "orig":{"tn":"12155551212"}
} }
Single Originator to Multiple Destination Identities example: Single Originator, with telephone number identity +12155551212, to
Multiple Destination Identities, with telephone number identity
+12125551212 and two URI identities, sip:alice@example.com and
sip:bob@example.com, example:
{ {
"dest":{ "dest":{
"tn":["12125551212"], "tn":["12125551212"],
"uri":["sip:alice@example.com", "uri":["sip:alice@example.com",
"sip:bob@example.net"] "sip:bob@example.net"]
}, },
"iat":"1443208345", "iat":"1443208345",
"orig":{"tn":"12155551212"} "orig":{"tn":"12155551212"}
} }
3.2.2.2. "mky" - Media Key claim 3.2.2.2. "mky" - Media Key claim
Some protocols that use PASSporT convey hashes for media security Some protocols that use PASSporT convey hashes for media security
keys within their signaling in order to bind those keys to the keys within their signaling in order to bind those keys to the
identities established in the signaling layers. One example would be identities established in the signaling layers. One example would be
the DTLS-SRTP key fingerprints carried in SDP via the "a=fingerprint" the DTLS-SRTP key fingerprints carried in SDP [RFC4566] via the
attribute; multiple instances of that fingerprint may appear in a "a=fingerprint" attribute; multiple instances of that fingerprint may
single SDP body corresponding to difference media streams offered. appear in a single SDP body corresponding to media streams offered.
The "mky" value of PASSporT contains a hexadecimal key presentation
of any hash(es) necessary to establish media security via DTLS-SRTP. The "mky" claim MUST be formated in a JSON form including the 'alg'
This mky value should be formated in a JSON form including the 'alg'
and 'dig' keys with the corresponding algorithm and hexadecimal and 'dig' keys with the corresponding algorithm and hexadecimal
values. Note that per guidance of Section 5 of this document any values. If there is multiple fingerprint values, for example
whitespace and line feeds must be removed. If there is multiple associated with different media streams in SDP, the fingerprint
fingerprint values, more than one, the fingerprint values should be values MUST be constructed as a JSON array denoted by bracket
constructed as a JSON array denoted by bracket characters. For the characters.
'dig' key value, the hash value should be the hexadecimal value
without any colons, in order to provide a more efficient, compact For the 'dig' key value, the hash value MUST be the hexadecimal value
form to be encoded in PASSporT token claim. without any colons.
An example claim with "mky" claim is as follows: An example claim with "mky" claim is as follows:
For an SDP offer that includes the following fingerprint values, For an SDP offer that includes the following fingerprint values,
a=fingerprint:sha-256 02:1A:CC:54:27:AB:EB:9C:53:3F:3E:4B:65: a=fingerprint:sha-256 02:1A:CC:54:27:AB:EB:9C:53:3F:3E:4B:65:
2E:7D:46:3F:54:42:CD:54:F1:7A:03:A2:7D:F9:B0:7F:46:19:B2 2E:7D:46:3F:54:42:CD:54:F1:7A:03:A2:7D:F9:B0:7F:46:19:B2
a=fingerprint:sha-256 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E: a=fingerprint:sha-256 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:
5D:49:6B:19:E5:7C:AB:3E:4B:65:2E:7D:46:3F:54:42:CD:54:F1 5D:49:6B:19:E5:7C:AB:3E:4B:65:2E:7D:46:3F:54:42:CD:54:F1
the PASSporT Payload object would be: the PASSporT Payload object would be:
{ {
"dest":{"uri":["sip:alice@example.com"]}, "dest":{"uri":["sip:alice@example.com"]},
"iat":"1443208345", "iat":"1443208345",
skipping to change at page 8, line 37 skipping to change at page 8, line 33
} }
3.3. PASSporT Signature 3.3. PASSporT Signature
The signature of the PASSporT is created as specified by JWS using The signature of the PASSporT is created as specified by JWS using
the private key corresponding to the X.509 public key certificate the private key corresponding to the X.509 public key certificate
referenced by the "x5u" header parameter. referenced by the "x5u" header parameter.
4. Extending PASSporT 4. Extending PASSporT
PASSporT represents the bare minimum set of claims needed to assert PASSporT includes the bare minimum set of claims needed to securely
the originating identity and support the secure propoerties discussed assert the originating identity and support the secure propoerties
in various parts of this document, however there will certainly be discussed in various parts of this document. JWT supports a straight
both new uses and ways of extending the application and usage of forward way to add additional claims by simply adding new claim key
PASSPorT that requires the ability to extend the defined base set of pairs. PASSporT can be extended beyond the defined base set of
claims to represent other information requiring assertion or claims to represent other information requiring assertion or
validation beyond the identity itself. validation beyond the originating identity itself as needed.
4.1. "ppt" (PASSporT) header parameter 4.1. "ppt" (PASSporT) header parameter
For the extension of the base set of claims defined in this document, For extension of the base set of claims defined in this document, a
a new JWS header parameter "ppt" MUST be used with a string that new JWS header parameter "ppt" MUST be used with a unique string.
uniquely identifies and points to a profile specification that Any PASSporT extension should be defined in a specification
defines any new claims that would extend the base set of claims of describing the PASSporT extension and the string used in the "ppt"
PASSporT. hedaer string that defines any new claims that would extend the base
set of claims of PASSporT.
An example header with an extended PASSporT profile of "foo" is as An example header with a PASSporT extension type of "foo" is as
follows: follows:
{ {
"alg":"ES256", "alg":"ES256",
"ppt":"foo", "ppt":"foo",
"typ":"passport", "typ":"passport",
"x5u":"https://tel.example.org/passport.cer" "x5u":"https://tel.example.org/passport.cer"
} }
4.2. Extended PASSporT Claims 4.2. Extended PASSporT Claims
Future specifications that define such extensions to the PASSporT Specifications that define extensions to the PASSporT mechanism MUST
mechanism MUST explicitly designate what claims they include beyond explicitly specify what claims they include beyond the base set of
the base set of claims from this document, the order in which they claims from this document, the order in which they will appear, and
will appear, and any further information necessary to implement the any further information necessary to implement the extension. All
extension. All extensions MUST incorporate the baseline JWT elements extensions MUST include the baseline JWT elements specified in
specified in Section 3; claims may only be appended to the claims Section 3; claims may only be appended to the claims object
object specified; they can never be subtracted or re-ordered. specified; they can never be removed or re-ordered. Specifying new
Specifying new claims follows the baseline JWT procedures ([RFC7519] claims follows the baseline JWT procedures ([RFC7519] Section 10.1).
Section 10.1). Note that understanding an extension as a verifier is Understanding an extension or new claims defined by the extension on
always optional for compliance with this specification (though future the destination verification of the PASSporT token is optional. The
specifications or profiles for deployment environments may make other creator of a PASSporT object cannot assume that destination systems
"ppt" values mandatory). The creator of a PASSporT object cannot will understand any given extension. Verification of PASSporT tokens
assume that verifiers will understand any given extension. Verifiers by destination systems that do support an extension may then trigger
that do support an extension may then trigger appropriate appropriate application-level behavior in the presence of an
application-level behavior in the presence of an extension; authors extension; authors of extensions should provide appropriate
of extensions should provide appropriate extension-specific guidance extension-specific guidance to application developers on this point.
to application developers on this point.
5. Deterministic JSON Serialization 5. Deterministic JSON Serialization
In order to provide a deterministic representation of the PASSporT JSON, as a canonical format, can include spaces, line breaks and key
Header and Claims, particularly if PASSporT is used across multiple value pairs can occur in any order and therefore makes it, from a
signaling environments, the JSON header object and JSON Claim object string format, non-deterministic. In order to make the digitial
MUST be computed as follows. signature verification work deterministically, the JSON
representation of the PASSporT Header and Claims, particularly if
PASSporT is used across multiple signaling environments, specifically
the JSON header object and JSON Claim object MUST be computed as
follows.
The JSON object MUST follow the rules for the construction of the The JSON object MUST follow the rules for the construction of the
thumbprint of a JSON Web Key (JWK) as defined in [RFC7638] Section 3. thumbprint of a JSON Web Key (JWK) as defined in [RFC7638] Section 3.
Each JSON object MUST contain no whitespace or line breaks before or Each JSON object MUST contain no whitespace or line breaks before or
after any syntactic elements and with the required members ordered after any syntactic elements and with the required members ordered
lexicographically by the Unicode [UNICODE] code points of the member lexicographically by the Unicode [UNICODE] code points of the member
names. names.
In addition, the JSON header and claim members MUST follow the In addition, the JSON header and claim members MUST follow the
lexicographical ordering and character and string rules defined in lexicographical ordering and character and string rules defined in
skipping to change at page 10, line 16 skipping to change at page 10, line 16
For the example PASSporT Payload shown in Section 3.2.2.2, the For the example PASSporT Payload shown in Section 3.2.2.2, the
following is the deterministic JSON object form. following is the deterministic JSON object form.
{"dest":{"uri":["sip:alice@example.com"],"iat": 1443208345,"mky" {"dest":{"uri":["sip:alice@example.com"],"iat": 1443208345,"mky"
:[{"alg":"sha-256","dig":"021ACC5427ABEB9C533F3E4B652E7D463F5442 :[{"alg":"sha-256","dig":"021ACC5427ABEB9C533F3E4B652E7D463F5442
CD54F17A03A27DF9B07F4619B2"},{"alg":"sha-256","dig":"4AADB9B13F8 CD54F17A03A27DF9B07F4619B2"},{"alg":"sha-256","dig":"4AADB9B13F8
2183B540212DF3E5D496B19E57CAB3E4B652E7D463F5442CD54F1"}], 2183B540212DF3E5D496B19E57CAB3E4B652E7D463F5442CD54F1"}],
"orig":{"tn":"12155551212"}} "orig":{"tn":"12155551212"}}
6. Human Readability 6. Security Considerations
JWT [RFC7519] and JWS [RFC7515] are defined to use Base64 and/or UTF8
encoding to the Header, Payload, and Signature sections. However,
many personal communications protocols, such as SIP and XMPP, use a
"human readable" format to allow for ease of use and ease of
operational debugging and monitoring. As such, specifications using
PASSporT may provide guidance on whether Base64 encoding or plain
text will be used for the construction of the PASSporT Header and
Claim sections.
7. Security Considerations
7.1. Avoidance of replay and cut and paste attacks 6.1. Avoidance of replay and cut and paste attacks
There are a number of security considerations for use of the token There are a number of security considerations for use of the token
for avoidance of replay and cut and paste attacks. PASSporT tokens for avoidance of replay and cut and paste attacks. PASSporT tokens
must be sent along with other application level protocol information should be sent with other application level protocol information
(e.g. for SIP an INVITE as defined in [RFC3261]). There should be a (e.g. for SIP an INVITE as defined in [RFC3261]). In order to make
link between various information provided in the token and the token signature unique to a specific origination of personal
information provided by the application level protocol information. communications there should be a link between various information
provided in the token and information provided by the application
These would include: level protocol information. This uniqueness specified using the
following two claims:
o "iat" claim should closely correspond to a date/time the message o 'iat' claim should correspond to a date/time the message was
was originated. It should also be within a relative delta time originated. It should also be within a relative time that is
that is reasonable for clock drift and transmission time reasonable for clock drift and transmission time characteristics
characteristics associated with the application using the PASSporT associated with the application using the PASSporT token.
token. Therefore, validation of the token should consider date and time
correlation, which could be influenced by signaling protocol
specific use and network time differences.
o "dest" claim is included to prevent the ability to use a o 'dest' claim is included to prevent the valid re-use of a
previously originated message to send to another destination party previously originated message to send to another destination
party.
7.2. Solution Considerations 6.2. Solution Considerations
It should be recognized that the use of this token should not, in It should be recognized that the use of this token should not, in
it's own right, be considered a full solution for absolute non- it's own right, be considered a full solution for absolute non-
repudiation of the persona being asserted. This only provides non- repudiation of the persona being asserted. This only provides non-
repudiation of the signer of PASSporT. If the signer and the persona repudiation of the signer of PASSporT. If the signer and the persona
are not one in the same, which can and often will be the case in are not one in the same, which can and often will be the case in
telecommunications networks today, protecting the destination party telecommunications networks today, protecting the destination party
from being spoofed may take some interpretation or additional from being spoofed may take some interpretation or additional
verification of the link between the PASSporT signature and the verification of the link between the PASSporT signature and the
persona being asserted. persona being asserted.
skipping to change at page 11, line 33 skipping to change at page 11, line 21
o Accounting for entities that may route calls from other peer or o Accounting for entities that may route calls from other peer or
interconnected telecommunications networks that are not part of interconnected telecommunications networks that are not part of
the "trusted" communications network or may not be following the the "trusted" communications network or may not be following the
usage of PASSporT or the profile of PASSporT appropriate to that usage of PASSporT or the profile of PASSporT appropriate to that
network network
o Following best practices around management and security of X.509 o Following best practices around management and security of X.509
certificates certificates
7.3. Privacy Considerations 6.3. Privacy Considerations
Because PASSporT explicity includes claims of identitifiers of Because PASSporT explicitly includes claims of identifiers of parties
parties involved in communications, times, and potentially other call involved in communications, date and times, and potentially other
detail, care should be taken outside of traditional protected or call detail, care should be taken outside of traditional protected or
private telephony communications paths where there may be concerns private telephony communications paths where there may be concerns
about exposing information to either unintended or illegitimately about exposing information to either unintended or illegitimate
intented actors. These identifiers are often exposed through many actors. These identifiers are often exposed through many
communications signaling protocols as of today, but appropriate communications signaling protocols as of today, but appropriate
precautions should be taken. precautions should be taken.
8. IANA Considerations 7. IANA Considerations
8.1. Media Type Registration 7.1. Media Type Registration
8.1.1. Media Type Registry Contents Additions Requested 7.1.1. Media Type Registry Contents Additions Requested
This section registers the "application/passport" media type This section registers the "application/passport" media type
[RFC2046] in the "Media Types" registry in the manner described in [RFC2046] in the "Media Types" registry in the manner described in
[RFC6838], which can be used to indicate that the content is a [RFC6838], which can be used to indicate that the content is a
PASSporT defined JWT and JWS. PASSporT defined JWT and JWS.
o Type name: application o Type name: application
o Subtype name: passport o Subtype name: passport
o Required parameters: n/a o Required parameters: n/a
o Optional parameters: n/a o Optional parameters: n/a
skipping to change at page 13, line 5 skipping to change at page 12, line 40
o Intended usage: COMMON o Intended usage: COMMON
o Restrictions on usage: none o Restrictions on usage: none
o Author: Chris Wendt, chris-ietf@chriswendt.net o Author: Chris Wendt, chris-ietf@chriswendt.net
o Change Controller: IESG o Change Controller: IESG
o Provisional registration? No o Provisional registration? No
8.2. JSON Web Token Claims Registration 7.2. JSON Web Token Claims Registration
8.2.1. Registry Contents Additions Requested 7.2.1. Registry Contents Additions Requested
o Claim Name: "orig" o Claim Name: "orig"
o Claim Description: Originating Identity String o Claim Description: Originating Identity String
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 3.2 of draft-ietf-stir- o Specification Document(s): Section 3.2 of draft-ietf-stir-
passport-05 passport-05
skipping to change at page 13, line 36 skipping to change at page 13, line 23
o Claim Name: "mky" o Claim Name: "mky"
o Claim Description: Media Key Fingerprint String o Claim Description: Media Key Fingerprint String
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 3.2 of draft-ietf-stir- o Specification Document(s): Section 3.2 of draft-ietf-stir-
passport-05 passport-05
9. Acknowledgements 8. Acknowledgements
Particular thanks to members of the ATIS and SIP Forum NNI Task Group Particular thanks to members of the ATIS and SIP Forum NNI Task Group
including Jim McEchern, Martin Dolly, Richard Shockey, John Barnhill, including Jim McEchern, Martin Dolly, Richard Shockey, John Barnhill,
Christer Holmberg, Victor Pascual Avila, Mary Barnes, Eric Burger for Christer Holmberg, Victor Pascual Avila, Mary Barnes, Eric Burger for
their review, ideas, and contributions also thanks to Henning their review, ideas, and contributions also thanks to Henning
Schulzrinne, Russ Housley, Alan Johnston, Richard Barnes, Mark Schulzrinne, Russ Housley, Alan Johnston, Richard Barnes, Mark
Miller, and Ted Hardie for valuable feedback on the technical and Miller, and Ted Hardie for valuable feedback on the technical and
security aspects of the document. Additional thanks to Harsha Bellur security aspects of the document. Additional thanks to Harsha Bellur
for assistance in coding the example tokens. for assistance in coding the example tokens.
10. References 9. References
10.1. Normative References
9.1. Normative References
[I-D.ietf-stir-rfc4474bis] [I-D.ietf-stir-rfc4474bis]
Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session "Authenticated Identity Management in the Session
Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-10 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-10
(work in progress), July 2016. (work in progress), July 2016.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
DOI 10.17487/RFC2046, November 1996, DOI 10.17487/RFC2046, November 1996,
skipping to change at page 14, line 46 skipping to change at page 14, line 29
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<http://www.rfc-editor.org/info/rfc7519>. <http://www.rfc-editor.org/info/rfc7519>.
[RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK) [RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK)
Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September
2015, <http://www.rfc-editor.org/info/rfc7638>. 2015, <http://www.rfc-editor.org/info/rfc7638>.
[UNICODE] "The Unicode Consortium, "The Unicode Standard"", [UNICODE] "The Unicode Consortium, "The Unicode Standard"",
<http://www.unicode.org/versions/latest/>. <http://www.unicode.org/versions/latest/>.
10.2. Informative References 9.2. Informative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>. <http://www.rfc-editor.org/info/rfc3261>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
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
 End of changes. 54 change blocks. 
212 lines changed or deleted 212 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/