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-01 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 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) 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. { 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 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 (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: 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": "MD7G3-C6CVW-3MYGU-RDYB6-KRY2G-HICUW", "Domain": " YE6bnq1MlX5ojaJto6PLP_PEwA", "Public": " UD7EVJT3HpjWllq9FMvHLQlMKEswExC8sCzlsni1bWvhnlEpcDE6dPgMYTOuyNkA sD-RriPxQiPHcJfZkfK54GGTcJphlIgGiieXOiYLCRla-nvQix3_p8-KNk5wM550 o-SclM0LI1zDi2nV3lgO9vhEFoPAlTm216gkO08yxJqyV_HZL6Wv87h0Ga90nTuZ 3v0dmCUUSz4QH4ZfQd_DLJlkYv8CULO-nO7sTvSmSloYUaKBv5T3bjq-awNGGotY c-lLgJv3nhMOxeLoIFsAClZm1-hpQe6Z19Tr9vL4jm6yNw8dC2xJ5ShoBV4XC9Qs sm-3tFUkkyfzkGlavslbnwA"}}, "ClientNonce": { "PublicKeyDH": { "kid": "MCED2-DY6HD-LMU26-NZDNF-PMSFA-JHIUV", "Domain": " YE6bnq1MlX5ojaJto6PLP_PEwA", "Public": " ttYQUqze31h83KXoMolNnK-AkJPLabht0nEC9RTy52xvVJeKYN8yxZTTNteiFvhq 6ke2PfXaadNeYEL3ISnCTeT9wmD6ZQwnZAwIb4416zS42oATMZVs0L_pKisudUHD DK2FIviQnt1OTUKlfJemEvaMVNIc064mANasXFPU-yL4yv2DrkGMfCSGnH1Pt1bw mHF2LndhqbLmbPafZfL8edXWrbPQT3482EY2EDW81MalqNpbA5yJKx9sUUuRnHj8 R6F7Au7fTqC3DxFVywehy5pBtpodyZfzmbSaUO0dlpP1Tfe8xILRaMeG3nlt0WQw xEM3pn--MMcEx7mtdZfDpAA"}}}} 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 10:11:41 Content-Length: 1360 { "ExchangeResponse": { "Status": 201, "StatusDescription": "Operation completed successfully", "Ticket": " T3BhcXVlIHZhbHVlIG91dHNpZGUgc2NvcGUgb2Ygc3BlY2lmaWNhdGlvbg", "Witness": " lqWXkx3zj1Ex3nBp6GTKJO0GUD9qfRsUI3759S7V5y4", "ServerCredential": { "PublicKeyDH": { "kid": "MCDJ2-ERISF-HEU5V-2CYDI-3AXUR-BNJX6", "Domain": " YE6bnq1MlX5ojaJto6PLP_PEwA", "Public": " uSDWcnHImlmwDKTOZDhQaxd5_idjtqSOn4Nr_ZY-MWeC1qcAC9o7p1cNDiax9mVK 2R8twZx7_KT_u2jiVyyFcGA5qJ8-NPxi0VvrG3bQ_jdgpCfFVuoinTj3tIO8cQTX L8ujxG7o8Zy9iR3fG27Sg2VhHIePbm87-xWBaW03ZcsAdS2ewrYLx7Lp1G3LHNXh aWntO-97yMgd_j9vMz8AaocC9b-Xog-O6lInc1zIow5p5qHTIzUiLN8RnV6-hyh8 R_vu4aAWBhmD27uxuXXb9YUzgL7cE4ZgjVrK_W2Ti3hzF25ZDnIy9f8okJM7HhDz kmIc46zUjh9RdSH-gmbJdQ"}}, "ServerNonce": { "PublicKeyDH": { "kid": "MDBE6-M6VZZ-KNZFX-V3OQC-IBWEH-YIWFS", "Domain": " YE6bnq1MlX5ojaJto6PLP_PEwA", "Public": " JKe6QgcTxCvVAHST4f7vK1u8Yr1DXxXSs-56T6Cc9LzauZ4n0bTzrC9bbPFQrtBO 7GVmHNItzbN8gls-ACKr09ZQTztYF2z0mIpZ6PRLLWCJqrIB1UR84wOk8G9e3gvf hIiqTbVT4VMUX_nY2rrljx7-XO2sWI9iZYoY7HeWAdYzJGzAQUJlg2bPvba-rvV2 Hs-bcLVwl3-NcSfivKiT69ecQz4AWCdhP5y_DrnR20FRvtBJDJIjeqhzTbYwrEjk 3RkPxtDURq0SeLXkCsYUGeNUtSNKq6-K8MPveHDZhRYUssDSguDz0_gBeNhbJc3H _exF7zeujFUdWKVU0uWbtQA"}}, "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]