Internet-Draft JSON Web Service Binding v1.0 April 2018
Hallam-Baker Expires October 13, 2018 [Page]
Stream:
Independent Submission
Series:
Internet-Draft
Status:
Informational
Published:
Expires
Authors:
Phillip Hallam-Baker (Comodo Group Inc.)

JSON Key Exchange
draft-hallambaker-json-key-exchange-03

Abstract

The JSON Key Exchange

This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-json-key-exchange.html.

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 October 13, 2018

Table of Contents

1. Introduction

This document describes a lightweight key agreement mechanism using between 2 and four Diffe-Hellman or Elliptic Curve Diffie-Hallman keys. The mechanism may be used establish a shared session key with authentication of any or none of the initiator and the responder.

The approach described is similar to that adopted in the X3DH Key agreement [X3DH] used in Signal.

The objective of the key exchange is limited to establishing a shared secret between two mutually authenticated parties that cannot be derived by any other parties and cannot be reconstructed by either of the parties after the ephemeral contributions have been deleted.

The key exchange is intended for use as one component in a multi-layer security approach in which comprehensive security is provided through use of encryption and authentication at multiple layers in the protocol stack.

Figure 1 : Multi-layer security

Specifically, this key exchange is intended for use at the presentation layer (e.g. authenticate and encrypt HTTP message bodies) to establish keys for authentication and optional encryption of messages in Web Service transactions.

Data Layer
Encryption of cryptographic keys, protocol configuration profiles.
Presentation Layer
Authentication of parties to a Web Service transaction.
Transport Layer
Protect metadata against interception at single point on the message path (link or node)
Link Layer
Protect messages against traffic analysis by means of interception at multiple points on the message path

2. Definitions

This section presents the related specifications and standard, the terms that are used as terms of art within the documents and the terms used as requirements language.

2.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

2.2. Defined Terms

No terms of art are defined.

2.4. Implementation Status

The implementation status of the reference code base is described in the companion document [draft-hallambaker-mesh-developer].

3. Key Exchange Protocol

3.1. Parameters

The following parameters are defined

Algorithm
The key exchange protocol. Diffie Hellman in discrete log, EdECDH25519 or EdECDH448.[RFC8032]
Key Derivation Function
The key derivation function. This is always HKDF [RFC5869]
Key Wrap Function
The Key Wrap function. This is always RFC3394 [RFC3394]

It should be noted that the algorithm described makes use of the Edwards form of the curve and not the Montgomery form described in [RFC7748]. While these curves are isomorphic, implementations of the Montgomery ladder do not lend themselves easily to the approach shown.

3.2. Notation

The notation adopted in [X3DH] is applied with minor modifications.

X ||Y
The concatenation of the byte sequence X followed by the byte sequence Y.
KE (PK1, PK2)
The result of performing the key exchange (Diffie-Hellman or Elliptic Curve Diffie Hellman) with the public parameters of PK1 and the private parameters of PK2.
PK1+PK2
The public, private key pair formed by combining the public, private parameters of PK1 and PK2.
Expand (PRK, info, L)
The KDF expansion function that derives a key of length L bits from the Pre Random Key PRK using the string info as the salt.
Extract (IKM, salt)
The KDF extraction function that derives a Pre-Random Key from the Initial Keying Material IKM and the salt value salt. If the salt value is specified as 0, the default salt of a string of zero bits the same length as the Pre-Random Key to be extracted is used.

3.3. Roles

Client
The party that initiates the key exchange
Service
The party that responds to the key exchange

3.4. Keys

IKC
The identification key of the client. The encoding of this key MAY include one or more credentials such as a Mesh personal profile or an X.509 certificate binding the key to an identity.
IKS 
The identification key of the service. The encoding of this key MAY include one or more credentials such as a Mesh personal profile or an X.509 certificate binding the key to an identity.
EKC 
The ephemeral key of the client.
EKS 
The ephemeral key of the service.

3.5. Derived Keys

The key derivation function is used to derive separate keys for different purposes as shown below. The value L is the number of bits requires to key the algorithm specified. The salt value used to derive the PRK from the IKM is either the default salt value (all zeros) or the previous Rekey value as described below.

AK (PRK)
Authentication Key = Expand (PRK, "authentication", L)
EK (PRK)
Encryption Key = Expand (PRK, "encryption", L)
RA (PRK)
Rekey Key = Expand (PRK, "rekey", L)
W (PRK)
Witness value= Expand (PRK, "witness", L)

3.6. Initial Keying Request

A key exchange request is either an initial key exchange request or a rekeying request. An initial key exchange request MAY be issued at any time but a rekeying request cannot be sent until at least one initial keying request has been completed.

Rekey messages are authenticated under a Rekey shared secret established in a previous session. This may be the immediately preceding session or any prior session whose rekey token has not expired.

3.6.1. Initial Request Message

The client sends their identity and ephemeral key to the service. { IKC, EKC }

If the request message is an initial keying request, a credential associated with the identity key MAY be provided. The request MAY be authenticated by means of a digital signature.

3.6.2. Initial Response Message

The service calculates the IKM value as follows:

IKM = KE (IKC + EKC, IKS + EKS)

PRK = Extract (IKM, 0)

The service returns the values { IKS, EKS, W(IKM) } in a message authenticated under AK(IKM)

3.7. Rekeying.

Unless the key agreement is performed to a device of restricted capability, rekeying imposes minimal load on client or server and can be performed often, particularly if the Ed25519 curve is used for rekeying.

The state required for rekeying is separate from the keys used to encrypt and/or authenticate messages. This allows an application to store the rekeying key between communication sessions without risk of compromising the confidentiality or integrity of messages.

The use of the chaining salt ensures that rekeying cannot compromise the security of an already established key, even if a weaker key exchange algorithm is used. Thus a client MAY use an Ed488 key to perform an initial key exchange and then preform rekey operations using a

3.7.1. Rekeying Request Message

The client sends a new ephemeral key to the service. { CEK }

The request message MUST be authenticated under the rekeying key of the shared secret of any unexpired session previously agreed. This allows the credentials of the parties to be omitted while providing the advantage of establishing a fresh forward secrecy session.

3.7.2. Rekeying Response Message

The service calculates the IKM value as follows:

IKM = KE (EKC, EKS)

The service returns the values { EKS, W(IKM) } in a message authenticated under AK(IKM)

PRK = Extract (IKM, RA')

Where RA' is the previous rekeying key output.

3.8. Initial Key Exchange Example

Alice requests access to a service using her account identifier alice@example.com. She has already registered her Mesh personal profile with the service where it is bound to her account identifier as the corresponding credential.

The Key exchange request is:

POST /.well-known/jwcexchange/HTTP/1.1
Host: example.com
Content-Length: 1068

{
  "ExchangeRequest": {
    "ClientCredential": {
      "PublicKeyDH": {
        "kid": "MB5OU-335BC-AUKOZ-E62ZE-4ME2J-IYUVJ",
        "Domain": "
YE6bnq1MlX5ojaJto6PLP_PEwA",
        "Public": "
5PxAR4YJvsf7XS1m25OnhkSh_F5yopwHCClxQZO4I2w5uc-twDYhRhFPazUBBKkT
G7ruS1qFJC-vuzcI6UL9Ee0QeJ9plnWoJA5CsoTFg_dHQVKEkdW5D227NT5OnvCe
AH1yinKSoIcRh4CXSG3MMC9oBOIj7YF4oWSgJ-T4ruMLXONac-o6T_2h-00dD9OP
Mpkj8_OdX3TdNwKnkSNJRrGj5F8UunJU9C85Tr1eh-U7wzW753RaqwN3R-B3LVjl
t4d1qiKbqGEzSjknSrjtUIReuAYtCI0fqOTap-6XcvdB_SHs4vPZ8oErIU0aTB65
VTtje5fm16tp-3o8P7x6WQ"}},
    "ClientNonce": {
      "PublicKeyDH": {
        "kid": "MB6Z6-GUF3J-RQRD3-IHIPS-UNOCI-HZDDR",
        "Domain": "
YE6bnq1MlX5ojaJto6PLP_PEwA",
        "Public": "
rVQmfx5-bSS6pTLwARcg_SyCBlNjZzWJ0yu9F7SE_2FuOJneQSqXOg1Gefz5UB2T
dD3W8wyKHJHAPyvX05vhQcicGNKLB9MO5x4Pzn2Klwm0-W4jJNZ1qHjuy_l81six
VqdGlRT44q9LTG326BJMmZMv_bij_lz3qTa8vOb9WTXfk458OV0ELphXmGSghi5t
x_rrS9z9gpKR5a22qTraHpdQJvIpXO0HPGddn_sQ3K2DWCtfVTi7aiwr7kwsO3p6
-NIHuAG4zRo86NE0UM_e6B4b7zX5cLt2n1_rqVNzwJOER1pRxgiFRtdJ43HyBVzv
uW1BMrZzT0JCR9g5kGG_OA"}}}}

The Keyu Exchange response is

HTTP/1.1 200 OK
Date: Wed 11 Apr 2018 09:01:08
Content-Length: 1360

{
  "ExchangeResponse": {
    "Status": 201,
    "StatusDescription": "Operation completed successfully",
    "Ticket": "
T3BhcXVlIHZhbHVlIG91dHNpZGUgc2NvcGUgb2Ygc3BlY2lmaWNhdGlvbg",
    "Witness": "
tKE46P84C0qjGur7cbZNLxhfrU7NSEj98AKEIVh_zzg",
    "ServerCredential": {
      "PublicKeyDH": {
        "kid": "MDD5A-RFNE7-JNUOS-23LTY-O4NIJ-PAYKM",
        "Domain": "
YE6bnq1MlX5ojaJto6PLP_PEwA",
        "Public": "
W-SCGVPSf1zgtgj_hwlLLt_CQnYttpxn4Ze4r18B5UO-a8G1XxeQEUjjUUvRqDMX
6KIWbrctjKOx2pIxAbMM3k9EzIk1lyvdhaXnSs-bBEHJpuqWzaz46JEt_49Nwppb
_Qr0j4gFvqrr0Fr7uXIuoihF8byL7b4M69dvRT9wE1KQSw0hTdcnmWgN0x0IcWcY
v3DTqGImtMibFkbgozj7csH-4UsMYDfqQx-DgGXLd0OkvN5CFqS030GRD9iDT9R4
98TQgLK8YD6J08_i2ADAGiP_GwHvDHZHkq0jFkgris5JJvEbfXgS7h8yYEnzgUPL
7xKt1vGcYs5ZQzHu8X6RGg"}},
    "ServerNonce": {
      "PublicKeyDH": {
        "kid": "MBD52-J4WFR-XKDUI-5BGL7-VHCQK-ZEHI7",
        "Domain": "
YE6bnq1MlX5ojaJto6PLP_PEwA",
        "Public": "
FkxMhJ64ZzdWI9QoBAeFEnB-9BupOu-B0FLmGMB9kkusumORQI-qiYQiGkEH93hH
qSelOLGuM83VzC-SS3UQKmlDVb1rbRSCqZXbkLCnc8KHeiBp0r8rmVIH8XicYLhP
_k9N5EjGmfcowGzOxZkO1d7g4sXEIv_Djr5hFf57F41zAvB34-ny2ZsD2jMyG4r5
26bMr69ceLEwfqXx5_rDc3CljfC1cAdBMsZSslFokurzq9X0nF2maPeYRpN3Ytbn
opzWmSyQZkoFg8Is9vnk6Dzy0mRHALpY0L6cMEEyYwNEhV7uGLMZsRtRLVDHvkAN
q2vUlh-CxthTdIWYFLjw4wA"}},
    "Encryption": ["A256CBC-HS512"],
    "Authentication": ["HS512"]}}

Note that the example has the witness value but does not authenticate the signed result at present. Perhaps it would be better to create the witness value from the ticket data which eliminates the need for authenticating the response??

3.9. Rekey Example

(TBS)

4. Key Exchange Service

Supports key exchange to establish a shared secret and bound ticket between a client and a service

HTTP Well Known Service Prefix: /.well-known/jwcexchange

Every Recrypt Service transaction consists of exactly one request followed by exactly one response.

4.1. Shared classes

4.1.1. Structure: Algorithms

Describes an algorithm suite. Each suite consists of sets of authentication and encryption algorithms which are mutually compatible. i.e. the counterparty MAY select any one of the encryption algorithms and use it with any one of the authentication algorithms.

Encryption: String [0..Many]
Algorithm identifiers of encryption and authenticated encryption algorithms offered
Authentication: String [0..Many]
Authentication algorithm offer

4.2. Utility Transactions

4.3. Transaction: Exchange

Request: ExchangeRequest
Response: ExchangeResponse

Perform Key Exchange to establish shared key bound to a ticket.

4.3.1. Message: ExchangeRequest

Initiate the key exchange request.

Offer: Algorithms [0..Many]
Set of message authentication and encryption algorithms offered by the client
4.3.2. Message: ExchangeResponse

Returns the server parameters.

Ticket: Binary (Optional)
Opaque session identifier.
Witness: Binary (Optional)
Opaque witness value used to prove binding to the ticket.
Encryption: String [0..Many]
Algorithm identifiers of encryption or authenticated encryption algorithm chosen
Authentication: String [0..Many]
Algorithm identifiers of authentication algorithm chosen

5. Security Considerations

6. IANA Considerations

The following registrations are required:

HTTP Content Coding Registry
jose-jwb
Well-Known URIs
/.well-known/srv/
[Or change registry to FCFS]

References

Normative References

[RFC8032]
S. Josefsson and I. Liusvaara "Edwards-Curve Digital Signature Algorithm (EdDSA)" RFC 8032 DOI 10.17487/RFC8032
[RFC5869]
H. Krawczyk and P. Eronen "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)" RFC 5869 DOI 10.17487/RFC5869
[RFC3394]
J. Schaad and R. Housley "Advanced Encryption Standard (AES) Key Wrap Algorithm" RFC 3394 DOI 10.17487/RFC3394
[draft-hallambaker-mesh-architecture]
Phillip Hallam-Baker "Mathematical Mesh: Architecture" Internet-Draft draft-hallambaker-mesh-architecture-04 <http://www.ietf.org/internet-drafts/draft-hallambaker-mesh-architecture-04.txt>

Informative References

[X3DH]
Moxie Marlinspike and Trevor Perrin "The X3DH Key Agreement Protocol " <https://signal.org/docs/specifications/x3dh/>
[RFC7748]
A. Langley and M. Hamburg and S. Turner "Elliptic Curves for Security" RFC 7748 DOI 10.17487/RFC7748
[draft-hallambaker-mesh-developer]
Phillip Hallam-Baker "Mathematical Mesh: Reference Implementation" Internet-Draft draft-hallambaker-mesh-developer-06 <http://www.ietf.org/internet-drafts/draft-hallambaker-mesh-developer-06.txt>

Author's Address


Phillip Hallam-Baker
Comodo Group Inc.
Email:
Prepared: Rendered: