JSON Key Exchange
draft-hallambaker-json-key-exchange-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Phillip Hallam-Baker | ||
| Last updated | 2017-10-07 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-hallambaker-json-key-exchange-00
Network Working Group P. Hallam-Baker
Internet-Draft Comodo Group Inc.
Intended status: Informational October 8, 2017
Expires: April 11, 2018
JSON Key Exchange
draft-hallambaker-json-key-exchange-00
Abstract
The JSON Key Exchange
This document is also available online at
http://prismproof.org/Documents/draft-hallambaker-json-key-
exchange.html [1] .
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 https://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 11, 2018.
Copyright Notice
Copyright (c) 2017 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.
Hallam-Baker Expires April 11, 2018 [Page 1]
Internet-Draft JSON Web Service Binding v1.0 October 2017
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Related Specifications . . . . . . . . . . . . . . . . . 4
2.4. Implementation Status . . . . . . . . . . . . . . . . . . 4
3. Key Exchange Protocol . . . . . . . . . . . . . . . . . . . . 4
3.1. Parameters . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.5. Derived Keys . . . . . . . . . . . . . . . . . . . . . . 5
3.6. Initial Keying Request . . . . . . . . . . . . . . . . . 6
3.6.1. Initial Request Message . . . . . . . . . . . . . . . 6
3.6.2. Initial Response Message . . . . . . . . . . . . . . 6
3.7. Rekeying. . . . . . . . . . . . . . . . . . . . . . . . . 6
3.7.1. Rekeying Request Message . . . . . . . . . . . . . . 7
3.7.2. Rekeying Response Message . . . . . . . . . . . . . . 7
3.8. Initial Key Exchange Example . . . . . . . . . . . . . . 7
3.9. Rekey Example . . . . . . . . . . . . . . . . . . . . . . 10
4. Key Exchange Service . . . . . . . . . . . . . . . . . . . . 10
4.1. Shared classes . . . . . . . . . . . . . . . . . . . . . 10
4.1.1. Structure: Algorithms . . . . . . . . . . . . . . . . 10
4.2. Utility Transactions . . . . . . . . . . . . . . . . . . 10
4.3. Transaction: Exchange . . . . . . . . . . . . . . . . . . 10
4.3.1. Message: ExchangeRequest . . . . . . . . . . . . . . 10
4.3.2. Message: ExchangeResponse . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . 12
7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
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.
Hallam-Baker Expires April 11, 2018 [Page 2]
Internet-Draft JSON Web Service Binding v1.0 October 2017
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.
[[This figure is not viewable in this format. The figure is
available at http://prismproof.org/Documents/draft-hallambaker-json-
key-exchange.html [2].]]
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].
Hallam-Baker Expires April 11, 2018 [Page 3]
Internet-Draft JSON Web Service Binding v1.0 October 2017
2.2. Defined Terms
No terms of art are defined.
2.3. Related Specifications
JSON Key Exchange is used extensively in the Mathematical Mesh and
related protocols [draft-hallambaker-mesh-architecture] .
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.
Hallam-Baker Expires April 11, 2018 [Page 4]
Internet-Draft JSON Web Service Binding v1.0 October 2017
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
C IK 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.
S IK 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.
C EK The ephemeral key of the client.
S EK 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)
Hallam-Baker Expires April 11, 2018 [Page 5]
Internet-Draft JSON Web Service Binding v1.0 October 2017
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. {
CIK, CEK }
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 (CIK + CEK, SIK + SEK)
PRK = Extract (IKM, 0)
The service returns the values { SIK, SEK, 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
Hallam-Baker Expires April 11, 2018 [Page 6]
Internet-Draft JSON Web Service Binding v1.0 October 2017
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 (CEK, SEK)
The service returns the values { SEK, 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:
Hallam-Baker Expires April 11, 2018 [Page 7]
Internet-Draft JSON Web Service Binding v1.0 October 2017
POST /.well-known/jwcexchange/HTTP/1.1
Host: example.com
Content-Length: 1070
{
"ExchangeRequest": {
"ClientCredential": {
"PublicKeyDH": {
"kid": "MD7EM-WBGNU-5T6Z3-CEA2D-3KVGD-ZGAZZ",
"Domain": "
YE6bnq1MlX5ojaJto6PLP_PEwA",
"Public": "
hP3Gro3-_fo3b2uqJq5mR3PIWG1vUvWJfxheK6FrUchjj-1oxsDxtUXaJqgoNltP
cy3-29Rvxcr6KfizZ09jd_uYVDJ_htJXZlJtGBxDun8MoLZMlHPY29f5-A8yYinA
UFo1Ix9kldRP_falEdoYkSRK-U-kQGUK9lmzUj1ezz6I4065obTsP4akX4jNo8Ta
Rys-NAf_b8uCxrjl3AtTuJVx3_hWyhBWGG1JOzcqLEC7M61DrqIqB5Y5jl0CVlcq
PVjhlpPLJBKMqhCWKvQNST7bboaW1plX5XUuJFafsxOeiw8q7L0GGT3h6uYNde7u
kl9VbK0osjpP2EzkeXh0mgA"}},
"ClientNonce": {
"PublicKeyDH": {
"kid": "MCE2I-ZU3DX-NCTD6-2MIC6-JKCCJ-QUBMO",
"Domain": "
YE6bnq1MlX5ojaJto6PLP_PEwA",
"Public": "
HnHbyXONeFSjenA13sgt-pTRkn3i_7soHhydHDonH_OCRHs0ExBPvVdbDxwDFZDW
IF_Ytqpx-U2dEVonQ_XUwCxvqdtpdT8J928QsK16FuxR5G471fhVidonzOEt1fgA
HgAX4a5RNHsPSQh7HR7rHNZD9zjZhkHVp-MGa96_azJxxNOe0oHMeRyMysnUJ82v
_dwFypKYMwDdHi3t15lMMH_8HZAlbZeMDo-35_5YCklmhZNmgbgXeTW9JloVMmz7
dpGJ4uevGApBeGxXGffsSQACh56o1J_JJWSwnbpeXPwb2PMZ-1lCq_OigDuSN7NL
z9eDshoVIN831GYtXjgr5AA"}}}}
Figure 1
The Keyu Exchange response is
Hallam-Baker Expires April 11, 2018 [Page 8]
Internet-Draft JSON Web Service Binding v1.0 October 2017
HTTP/1.1 200 OK
Date: Sun 08 Oct 2017 04:50:25
Content-Length: 1360
{
"ExchangeResponse": {
"Status": 201,
"StatusDescription": "Operation completed successfully",
"Ticket": "
T3BhcXVlIHZhbHVlIG91dHNpZGUgc2NvcGUgb2Ygc3BlY2lmaWNhdGlvbg",
"Witness": "
CDwW-sZukuq0xhXtj22U-I8DOVhHM-v33RKd01MxzQY",
"ServerCredential": {
"PublicKeyDH": {
"kid": "MAI47-2ZH5L-AV3GQ-TCOBK-3FGUC-LUJSM",
"Domain": "
YE6bnq1MlX5ojaJto6PLP_PEwA",
"Public": "
ytxJytQzyoJbQMJyjDybvuPzZzW7h6TCJ3wTnO9wOnEkVLiA4prGwAGEHA4Uj9Oz
wcEnB67ARMcaKS8NQopD8otgNlJH2Nw71VyqWha-x2zdAhlsMjlkUw2oHEcNBA62
tGyyv73AQ7by9hzQe7BVbAtljJrRBCozld9KV7UVvsyKejIwZBV1Xet2w-Qyh2Ev
of-JtSSBUW1GvcwKIq5KvQRcIgP-vtueuESMjlXol-vbRaBly_Zb_F22zgZFY4V1
P-Zz2_ZEsXHbgXXvO9Xs5AG9RSaufEtXjrdAFtOpq0ByVQovWbYS8CKfnOUP-Vyc
djxlpm9FCEC3h1SWwUWfiAA"}},
"ServerNonce": {
"PublicKeyDH": {
"kid": "MBD6M-5NEAJ-DZOWY-FIWMK-2H25I-NB73V",
"Domain": "
YE6bnq1MlX5ojaJto6PLP_PEwA",
"Public": "
aNJ4EVQda4tfhEMHngvDUqhyrm4K5acl-T0NneZAorNZz9-xI30nlZT49EF8RE4o
7qIEuGDTynBzFSTlmtKJCbXAEaNi5FoHHM-1dmx8nzLoKPSqaLSYeLXx48u6n_21
zZ7aejAyvlctJ5nl7CL0SXlngvqrl5sf1cy1vZ5pgej4qscpZjSjwoqb03g3NUo5
qmkFPkPlMyyAT_BOuG4hhizoPIfCnEH_099JMIN9JEUMZXwuhGI0dC1Iav46TEPb
ZgjdsgWRYdcphelUIdYKxjCk959gitAo_JBFsTLP2woGX1I6uOAL04Xbc1XPaNzk
ri-Rao91-iDxxMX5pkNYdg"}},
"Encryption": ["A256CBC-HS512"],
"Authentication": ["HS512"]}}
Figure 2
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??
Hallam-Baker Expires April 11, 2018 [Page 9]
Internet-Draft JSON Web Service Binding v1.0 October 2017
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
SRV Prefix: _jwcexchange._tcp
SRV Prefix: _jwcexchange._tcp
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
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
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
Hallam-Baker Expires April 11, 2018 [Page 10]
Internet-Draft JSON Web Service Binding v1.0 October 2017
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]
7. References
7.1. Normative References
[draft-hallambaker-mesh-architecture]
Hallam-Baker, P., "Mathematical Mesh: Architecture",
draft-hallambaker-mesh-architecture-04 (work in progress),
September 2017.
[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard
(AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394,
September 2002.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010.
Hallam-Baker Expires April 11, 2018 [Page 11]
Internet-Draft JSON Web Service Binding v1.0 October 2017
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017.
7.2. Informative References
[draft-hallambaker-mesh-developer]
Hallam-Baker, P., "Mathematical Mesh: Reference
Implementation", draft-hallambaker-mesh-developer-05 (work
in progress), September 2017.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016.
[X3DH] Marlinspike, M. and T. Perrin, "The X3DH Key Agreement
Protocol", November 2011.
7.3. URIs
[1] http://prismproof.org/Documents/draft-hallambaker-json-key-
exchange.html
[2] http://prismproof.org/Documents/draft-hallambaker-json-key-
exchange.html
Author's Address
Phillip Hallam-Baker
Comodo Group Inc.
Email: philliph@comodo.com
Hallam-Baker Expires April 11, 2018 [Page 12]