Internet DRAFT - draft-wendt-verified-token
draft-wendt-verified-token
Internet Engineering Task Force C. Wendt, Ed.
Internet-Draft Comcast
Intended status: Informational October 8, 2015
Expires: April 10, 2016
Verified Token
draft-wendt-verified-token-00
Abstract
This memo defines a token format for verifying with non-repudiation
the originator of a set of information. The originator uses a
cryptographic signature generally with a key that proves
authorization from a trust anchor to prove to a terminating party
that the originator is both an authorized sender and the information
wasn't altered or modified in transit. The token incorporates the
ability for the originator to assert a application specific but
extensible set of information that could include network identity,
device identity, realm of origin, and other metadata. Verification
of this information in the telephony world is important for
validating telephone calls and the telephone numbers they are
presenting and can be utilized as an important tool for combat
spoofing of identity and other forms of impersonation.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 10, 2016.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wendt Expires April 10, 2016 [Page 1]
Internet-Draft Verified Token October 2015
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://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. Token Overview . . . . . . . . . . . . . . . . . . . . . . . 3
3. Verified Token (VT) . . . . . . . . . . . . . . . . . . . . . 3
3.1. Verified Token Header . . . . . . . . . . . . . . . . . . 3
3.2. Verified Token Claim . . . . . . . . . . . . . . . . . . 4
3.3. Verified Token Signature . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
4.1. Validation of the Issuer and Certificate Signature . . . 5
4.2. Avoidance of replay and cut and paste attacks . . . . . . 5
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
Appendix A. Example Usage of Verified Tokens for SIP . . . . . . 7
Appendix B. Example Reference Tokens . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
This document will define a method for the creation and verification
of an extensible canonical token that is intended for
cryptographically verifying both an originator, the validity of the
originator, information associated with a specific transaction and an
application specific a set of information through digital signatures
and the associated chain of trust. A goal of this approach is to be
implementable in a straight-forward, extensible way. A second goal
is to be separable from any specific signaling call logic, so
creation and verification of information can be implemented in a
flexible way with minimal dependence on specific signaling
constructs. A third goal is to utilize as much as possible existing
technologies and infrastructure dependency to allow flexible
deployment strategies. Deployment specifics will be out of scope for
this document to allow industry specific solutions for managing PKI
and other dependencies.
Wendt Expires April 10, 2016 [Page 2]
Internet-Draft Verified Token October 2015
2. Token Overview
Tokens are a convenient way of encapsulating information with
associated cryptographic signatures. They are used in many
applications that require authentication, authorization, encryption
and other use cases that involve digital signatures. JWT [RFC7519]
and JWS [RFC7515] are designed to provide a compact form for many of
these purposes and define a specific form for specifying information
associated with the token and an extensible mechanisms for applying
digital signatures and the cryptographic algorithms used. JWT has
the form "header.claim.signature" and JWS provides standard ways to
form a digital signature. Note: In this document, we will focus on
digital signatures, but JWT and JWS also support HMAC symmetric key
based algorithms as well.
3. Verified Token (VT)
The Verify Token (VT) is constructed based on JWT [RFC7519] and JWS
[RFC7515] specifications. JWS defines the use of JSON data
structures in a specified canonical format for signing data
corresponding to JOSE header, JWS Payload, and JWS Signature. JWT
defines specific set of claims that are represented by specified key
value pairs which can be extended with custom keys for specific
applications.
3.1. Verified Token Header
The JWS token header is a JOSE header that defines the type and
encryption algorithm used in the token. An example of the header for
the case of a RSASSA-PKCS1-v1_5 SHA-256 digital signature would be
the following,
{ "typ":"JWT",
"alg":"RS256"}
This represents that the encoded token is a JWT, and the JWT is a JWS
using the RSASSA-PKCS1-v1_5 SHA-256 algorithm.
For Verified Token the "typ" header MUST be "JWT".
Because Verified Token is defined for use with PKI based digital
signatures, the "alg" header is recommended to be one of the
following algorithms as defined in JWA [RFC7518]:
o RS256
o ES256
Wendt Expires April 10, 2016 [Page 3]
Internet-Draft Verified Token October 2015
The "alg" header could optionally be one of the following:
o RS384
o RS512
o ES384
o ES512
3.2. Verified Token Claim
The token claim should consist of the information which needs to be
verified at the terminating party. This claim should correspond to a
JWT claim [RFC7519] and be encoded as defined by the JWS Payload
[RFC7515].
The Verified Token should use a number of standard defined token
headers as well as some addition custom headers specifically required
for two party communications with an originator and terminator.
These headers or key value pairs will be explained here, but some of
the security implications will be explained further in the security
considerations section below.
The JSON claim MUST include the following registered JWT defined
claims unless noted optional:
o "iss" - required - principal that issued and signed the JWT. This
is an https URL with the domain of the authorized originator of
the token (e.g. "https://pstn.example.com)
o "jti" - required - unique identifier of the JWT, useful for both
tracking and avoiding replay of JWT
o "iat" - required - issued at, time the JWT was issued, used for
expiration
Verified Token specific claims MUST be included unless noted
optional:
o "orig" - required - the identity claimed by the originating party.
(e.g. for SIP, the FROM or PAI associated e.164 telephone number,
TEL or SIP URI) This MAY be in URI format as defined in [RFC3986]
or an application specific identity string.
o "term" - required - the terminating identity claimed by the
originating party. (e.g. for SIP, the TO associated e.164
Wendt Expires April 10, 2016 [Page 4]
Internet-Draft Verified Token October 2015
telephone number, TEL or SIP URI) This MAY be in URI format as
defined in [RFC3986] or an application specific identity string.
NOTE: for identities such as SIP URIs where there is a domain
associated with a user part, i.e. user@domain, the domain in the
claim, may or may not correspond to either the TO/FROM/PAI and/or the
"iss". The determination of the validity of the claimed identity,
either user part alone or the full user@domain would be up to the
application.
An example claim is as follows,
{ "orig":"+12155551212",
"term":"sip:+12155551213@example.com",
"iss":"https://pstn.example.com",
"jti": "FAhNaPk0onffyJvykJZC2A==",
"iat": 1443208345 }
3.3. Verified Token Signature
The signature of the verified token is computed fully as specified by
JWS.
4. Security Considerations
There are a number of security considerations required for preventing
various attacks on the validity or impersonation of the signature.
4.1. Validation of the Issuer and Certificate Signature
Use of X.509 based signatures for the JWT implies normal validation
of the certificate ownership based on the binding of the public key
certificate to the distinguished name representing the authorized
originator. The iss field of the signed claim should also match this
distinguished name of the certificate used for signing the verified
token.
4.2. Avoidance of replay and cut and paste attacks
There are a number of security considerations for use of the token
for avoidance of replay and cut and paste attacks.
Verified tokens must be sent along with other application level
protocol information (e.g. for SIP an INVITE as defined in
[RFC3261]). There should be a link between various information
provided in the token and information provided by the application
level protocol information.
Wendt Expires April 10, 2016 [Page 5]
Internet-Draft Verified Token October 2015
These would include:
o "iat" claim should closely correspond to a date/time the message
was originated. It should also be within a relative delta time
that is reasonable for clock drift and transmission time
characteristics associated with the application using the verified
token.
o "jti" claim could be used to exactly correspond to a unique
identifier (e.g. INSIPID for SIP)
o "term" claim is included to prevent the ability to use a
previously originated message to send to another terminating party
5. Acknowledgements
Particular thanks to members of the ATIS and SIP Forum NNI Task Group
including Martin Dolly, Richard Shockey, Jim McEchern, John Barnhill,
Christer Holmberg, Victor Pascual Avila, Mary Barnes, Eric Burger for
their review, ideas, and contributions also thanks to Henning
Schulzrinne, Russ Housley, Jon Peterson, Alan Johnston for valuable
feedback on the technical and security aspects of the document.
Would also like to acknowledge the RFC4474bis framework for providing
inspiration on this document particularly the security protection
aspects.
6. References
[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,
<http://www.rfc-editor.org/info/rfc3261>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <http://www.rfc-editor.org/info/rfc7515>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI
10.17487/RFC7518, May 2015,
<http://www.rfc-editor.org/info/rfc7518>.
Wendt Expires April 10, 2016 [Page 6]
Internet-Draft Verified Token October 2015
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<http://www.rfc-editor.org/info/rfc7519>.
Appendix A. Example Usage of Verified Tokens for SIP
Specific usage of verified tokens shall be defined for various usage,
however to serve as an example and illustrate the need to link
certain message metadata for security reasons as discussed in the
security considerations section above
Appendix B. Example Reference Tokens
Example tokens with corresponding certificates and keys to serve as
test data for reference implementation.
Author's Address
Chris Wendt (editor)
Comcast
One Comcast Center
Philadelphia, PA 19103
USA
Email: chris-ietf@chriswendt.net
Wendt Expires April 10, 2016 [Page 7]
