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.

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. Token Overview
• 3. Verified Token (VT)
• 3.1. Verified Token Header
• 3.2. Verified Token Claim
• 3.3. Verified Token Signature
• 4. Security Considerations
• 4.1. Validation of the Issuer and Certificate Signature
• 4.2. Avoidance of replay and cut and paste attacks
• 5. Acknowledgements
• 6. References
• Appendix A. Example Usage of Verified Tokens for SIP
• Appendix B. Example Reference Tokens
• Author's Address

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.

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

            { "typ":"JWT",
              "alg":"RS256"}
            

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,

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]:

• RS256
• ES256

The "alg" header could optionally be one of the following:

• RS384
• RS512
• ES384
• 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:

• "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)
• "jti" - required - unique identifier of the JWT, useful for both tracking and avoiding replay of JWT
• "iat" - required - issued at, time the JWT was issued, used for expiration

Verified Token specific claims MUST be included unless noted optional:

• "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.
• "term" - required - the terminating identity claimed by the originating party. (e.g. for SIP, the TO 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.

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.

              { "orig":"+12155551212",
                "term":"sip:+12155551213@example.com",
                "iss":"https://pstn.example.com",
                "jti": "FAhNaPk0onffyJvykJZC2A==",
                "iat": 1443208345 }
              
            

An example claim is as follows,

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.

These would include:

• "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.
• "jti" claim could be used to exactly correspond to a unique identifier (e.g. INSIPID for SIP)
• "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

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