tls R. Cragie Internet-Draft ARM Ltd. Intended status: Informational F. Hao Expires: December 24, 2016 Newcastle University (UK) June 22, 2016 Elliptic Curve J-PAKE Cipher Suites for Transport Layer Security (TLS) draft-cragie-tls-ecjpake-01 Abstract This document defines new cipher suites based on an Elliptic Curve Cryptography (ECC) variant of Password Authenticated Key Exchange by Juggling (J-PAKE) for the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols. 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 December 24, 2016. Copyright Notice Copyright (c) 2016 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. Cragie & Hao Expires December 24, 2016 [Page 1] Internet-Draft ECJPAKE June 2016 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. ECJ-PAKE Based AES-CCM Cipher Suites . . . . . . . . . . . . 4 3. Specific Fixed Implementation Parameters . . . . . . . . . . 5 4. Notations . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Elliptic Curve Points . . . . . . . . . . . . . . . . . . 5 4.2. Integers . . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Octet Strings . . . . . . . . . . . . . . . . . . . . . . 7 4.4. Integer to Octet String Conversion . . . . . . . . . . . 7 4.5. Octet String to Integer Conversion . . . . . . . . . . . 7 5. Handshake . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Failure processing . . . . . . . . . . . . . . . . . . . . . 8 7. ECJ-PAKE TLS Extensions and Modification . . . . . . . . . . 8 7.1. New Structure Definitions . . . . . . . . . . . . . . . . 8 7.1.1. Public Key and Schnorr ZKP Pair . . . . . . . . . . . 8 7.1.2. Schnorr ZKP . . . . . . . . . . . . . . . . . . . . . 9 7.2. ClientHello and ServerHello TLS Extensions . . . . . . . 9 7.2.1. Existing Extensions . . . . . . . . . . . . . . . . . 9 7.2.2. Additional Extensions . . . . . . . . . . . . . . . . 10 7.3. ServerKeyExchange . . . . . . . . . . . . . . . . . . . . 10 7.4. ClientKeyExchange . . . . . . . . . . . . . . . . . . . . 11 8. Calculations . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. User Identity Selection . . . . . . . . . . . . . . . . . 12 8.2. Schnorr ZKP Hash Calculation . . . . . . . . . . . . . . 12 8.3. Shared Secret . . . . . . . . . . . . . . . . . . . . . . 13 8.3.1. Example . . . . . . . . . . . . . . . . . . . . . . . 13 8.4. ClientHello and ServerHello Calculations . . . . . . . . 14 8.4.1. Public Key Generation . . . . . . . . . . . . . . . . 14 8.4.2. Schnorr ZKP Generation . . . . . . . . . . . . . . . 14 8.4.3. Schnorr ZKP Verification . . . . . . . . . . . . . . 15 8.5. ServerKeyExchange Calculations . . . . . . . . . . . . . 16 8.5.1. Public Key Generation . . . . . . . . . . . . . . . . 16 8.5.2. Schnorr ZKP Generation . . . . . . . . . . . . . . . 17 8.5.3. Schnorr ZKP Verification . . . . . . . . . . . . . . 17 8.6. ClientKeyExchange Calculations . . . . . . . . . . . . . 18 8.6.1. Public Key Generation . . . . . . . . . . . . . . . . 18 8.6.2. Schnorr ZKP Generation . . . . . . . . . . . . . . . 19 8.6.3. Schnorr ZKP Verification . . . . . . . . . . . . . . 20 8.7. Premaster Secret Generation . . . . . . . . . . . . . . . 20 8.7.1. Server Premaster Secret Generation . . . . . . . . . 20 8.7.2. Client Premaster Secret Generation . . . . . . . . . 21 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 10.1. Transport Layer Security (TLS) Parameters . . . . . . . 22 10.1.1. TLS Cipher Suite Registry . . . . . . . . . . . . . 22 Cragie & Hao Expires December 24, 2016 [Page 2] Internet-Draft ECJPAKE June 2016 10.2. Transport Layer Security (TLS) Extensions . . . . . . . 22 10.2.1. ExtensionType Values . . . . . . . . . . . . . . . . 22 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 11.1. Security Proof . . . . . . . . . . . . . . . . . . . . . 22 11.2. Counter Reuse . . . . . . . . . . . . . . . . . . . . . 22 11.3. Password . . . . . . . . . . . . . . . . . . . . . . . . 22 11.4. Rate Limiting . . . . . . . . . . . . . . . . . . . . . 23 11.5. Usage Restrictions . . . . . . . . . . . . . . . . . . . 23 11.6. Fixed Implementation Parameters . . . . . . . . . . . . 23 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 12.1. Normative References . . . . . . . . . . . . . . . . . . 23 12.2. Informative References . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction This document defines new cipher suites based on an Elliptic Curve Cryptography (ECC) variant of Password Authenticated Key Exchange by Juggling (J-PAKE) for version 1.2 of Transport Layer Security (TLS) protocol [RFC5246] as well as version 1.2 of the Datagram Transport Layer Security (DTLS) protocol [RFC6347]. The cipher suites are AEAD cipher suites using AES-CCM [CCM] based on the cipher suites defined in [RFC7251], using ECJ-PAKE as an alternative key establishment mechanism. The existing set of TLS cipher suites are typically aimed at more traditional client-server interactions, for example, a web browser to web server. However, TLS and DTLS are increasingly being specified for use in Internet-of-Things (IoT) standards for peer-to-peer application layer interaction. For example, DTLS is specified as a binding to provide security for the CoAP protocol [RFC7252], which is widely used in IoT applications. J-PAKE is a balanced password-authenticated key exchange (PAKE) protocol resistant to off-line dictionary attack designed by Feng Hao and Peter Ryan in 2008 [HR08]. The use of a PAKE for IoT devices is highly appropriate as it allows a simple method of commissioning IoT devices onto a network without requiring certificates to be issued and maintained for each device. An ECC variant of J-PAKE [J-PAKE] is particularly suited to IoT devices, which are often constrained with regard to memory and processing power. The cipher suite TLS_ECJPAKE_WITH_AES_128_CCM_8 as defined in this document is currently being used in the Thread protocol [THREAD]. Cragie & Hao Expires December 24, 2016 [Page 3] Internet-Draft ECJPAKE June 2016 1.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]. 1.2. Terminology AEAD Authenticated Encryption with Associated Data. ECJ-PAKE Elliptic Curve Cryptography (ECC) variant of Password Authenticated Key Exchange by Juggling (J-PAKE). ZKP Zero-knowledge proof. 2. ECJ-PAKE Based AES-CCM Cipher Suites The cipher suites defined in this document are based on the AES-CCM Authenticated Encryption with Associated Data (AEAD) algorithms AEAD_AES_128_CCM and AEAD_AES_256_CCM described in [RFC5116]. The following cipher suites are defined: TLS_ECJPAKE_WITH_AES_128_CCM = {0xTBD, 0xTBD} TLS_ECJPAKE_WITH_AES_256_CCM = {0xTBD, 0xTBD} TLS_ECJPAKE_WITH_AES_128_CCM_8 = {0xTBD, 0xTBD} TLS_ECJPAKE_WITH_AES_256_CCM_8 = {0xTBD, 0xTBD} These cipher suites make use of the AEAD capability in TLS 1.2 [RFC5246]. Cipher suites ending with "8" use eight-octet authentication tags; the other cipher suites have 16-octet authentication tags. The HMAC truncation option described in Section 7 of [RFC6066] (which negotiates the "truncated_hmac" TLS extension) does not have an effect on the cipher suites defined in this document, because they do not use HMAC to protect TLS records. The "nonce" input to the AEAD algorithm is as defined in [RFC6655]. These cipher suites make use of the default TLS 1.2 Pseudorandom Function (PRF), which uses HMAC with the SHA-256 hash function. The following stipulations apply to the use of elliptic curves: Cragie & Hao Expires December 24, 2016 [Page 4] Internet-Draft ECJPAKE June 2016 o Curves with a cofactor equal to one SHOULD be used; this simplifies their use. o The uncompressed point format MUST be supported. Other point formats MAY be used. o Fundamental ECC algorithms [RFC6090] MAY be used as an implementation method. o A particular implementation MUST use only a single curve (see Section 3) 3. Specific Fixed Implementation Parameters It is expected that TLS-ECJ-PAKE is used in applications where parameters applying to the particular TLS-ECJ-PAKE implementation are fixed and known to the application a priori. For this reason, certain capability negotiations usually associated with TLS are not present in TLS-ECJ-PAKE. This restricts its use to applications where such parameters can be applied a priori, for example as is the case in Thread [THREAD]. Parameters which MUST be fixed prior to implementation are: +---------------------------------+ | Parameter | +---------------------------------+ | Choice of single elliptic curve | | Presence or absence of identity | +---------------------------------+ Table 1: Fixed implementation parameters 4. Notations This section describes the notations used in this document. 4.1. Elliptic Curve Points The generator (base point) of an elliptic curve is represented by the letter 'G': G A modified generator is represented by the letter 'G' concatenated with a single uppercase character: GB Cragie & Hao Expires December 24, 2016 [Page 5] Internet-Draft ECJPAKE June 2016 Elliptic curve points are represented using a single uppercase character or a single uppercase character concatenated with a single lowercase character or decimal digit, for example: X Xc X2 Conversion to and from elliptic curve points to octet strings is as specified in Sections 2.3.3 and 2.3.4 of [SEC1]. Point multiplication is shown as an elliptic curve point multiplied by a scalar integer using the '*' operator, for example: G*x Point addition or subtraction is shown as the addition or subtraction of elliptic curve points or scalar multiplied elliptic curve points using the '+' and '-' operators respectively, for example: X1 + X3 + X4 X*h + G*r Xs - X4*x2*s 4.2. Integers Integers are represented using a single lowercase character or a single lowercase character followed by a single lowercase character or decimal digit, for example: x xc x2 Where expressed, integers are shown in hexadecimal and/or decimal form. Hexadecimal numbers have an '0x' prefix. For example: 0x12ab34cd 3132110061 Cragie & Hao Expires December 24, 2016 [Page 6] Internet-Draft ECJPAKE June 2016 Integer multiplication is shown as two integers multiplied together using the '*' operator: x*s Integer addition or subtraction is shown as the addition or subtraction of integers or multiplied integers using the '+' and '-' operators respectively: v - x*h 4.3. Octet Strings Octet strings are expressed in a hexadecimal form, with no '0x' prefix and with a space separator, first octet leftmost, for example: 12 ab 34 cd 4.4. Integer to Octet String Conversion Integer to octet string conversion SHALL be performed as stated in Section 2.3.7 of [SEC1]. It is represented as follows: M = str(mlen, x) where x, mlen, and M are the parameters as stated in Section 2.3.7 of [SEC1]. 4.5. Octet String to Integer Conversion Octet string to integer conversion SHALL be as stated in section 2.3.8 of [SEC1]. It is represented as follows: x = int(mlen, M) where x, mlen, and M are the parameters as stated in Section 2.3.8 of [SEC1]. 5. Handshake The TLS-ECJ-PAKE handshake is as follows, augmented with parameters in braces to show the ECJ-PAKE material conveyed in each case: Cragie & Hao Expires December 24, 2016 [Page 7] Internet-Draft ECJPAKE June 2016 Client Server ------ ------ ClientHello --------> {(X1,ZKP(X1)), (X2,ZKP(X2))} ServerHello {(X3, ZKP(X3)), (X4, ZKP(X4))} ServerKeyExchange {Xs, ZKP(Xs)} <-------- ServerHelloDone ClientKeyExchange {Xc, ZKP(Xc)} [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data Figure 1: Message flow in a TLS-ECJ-PAKE handshake 6. Failure processing If there are failures for any reason on client or server side, for example, Schnorr ZKP verification or missing extensions, the handshake SHALL abort immediately and send a TLS Error Alert message to the peer, using code 40 (handshake_failure) (see Section 7.2 of [RFC5246]). 7. ECJ-PAKE TLS Extensions and Modification This section describes existing and newly-defined extensions required for ECJ-PAKE-TLS. The guiding principle for extension use is to adhere as closely as possible to [RFC4492]. 7.1. New Structure Definitions TLS-ECJ-PAKE requires new structure definitions for: o Public key and Schnorr ZKP pair o Schnorr ZKP 7.1.1. Public Key and Schnorr ZKP Pair The TLS structure is as follows: Cragie & Hao Expires December 24, 2016 [Page 8] Internet-Draft ECJPAKE June 2016 struct { ECPoint X; ECSchnorrZKP zkp; } ECJPAKEKeyKP; X Public key represented as an elliptic curve point. ECPoint is defined in [RFC4492]. zkp ECSchnorrZKP is defined in Section 7.1.2. 7.1.2. Schnorr ZKP The TLS structure is as follows: struct { ECPoint V; opaque r<1..2^8-1>; } ECSchnorrZKP; V Ephemeral public key represented as an elliptic curve point. ECPoint is defined in [RFC4492]. r Schnorr signature. 7.2. ClientHello and ServerHello TLS Extensions 7.2.1. Existing Extensions The following TLS extensions defined in Section 4 of [RFC4492] SHALL be present in ClientHello: o Supported Elliptic Curves Extension (NamedCurve, EllipticCurveList) o Supported Point Formats Extension (ECPointFormat, ECPointFormatList) and the following TLS extension defined in Section 4 of [RFC4492] SHALL be present in ServerHello: Cragie & Hao Expires December 24, 2016 [Page 9] Internet-Draft ECJPAKE June 2016 o Supported Point Formats Extension (ECPointFormat, ECPointFormatList) EllipticCurveList in ClientHello SHALL contain only one entry corresponding to the fixed elliptic curve chosen for the implementation (see Section 3). 7.2.2. Additional Extensions The following extension SHALL additionally be present in both ClientHello and ServerHello: enum { ecjpake_key_kp_pair(TBC) } ExtensionType; struct { opaque identity<0..2^16-1>; ECJPAKEKeyKP ecjpake_key_kp_pair_list[2]; } ECJPAKEKeyKPPairList; identity Included if the Client or Server needs to uniquely identify themselves to the other party. An identity is used in the Schnorr ZKP hash calculation (see Section 8.2). The identity field SHALL be elided where an implementation has chosen absence of identity (see Section 3). ecjpake_key_kp_pair_list The list is precisely two elements long. The list in a ClientHello extension conveys public keys X1 and X2 and the list in a ServerHello extension conveys public keys X3 and X4, with associated Schnorr ZKPs. Note: When used in conjunction with DTLS and denial-of-service countermeasures as described in Section 4.2.1 of [RFC6347], the ECJPAKEKeyKPPairList in the subsequent ClientHello message SHALL be the same as the ECJPAKEKeyKPPairList in initial ClientHello message, i.e. the public keys X1 and X2 and associated Schnorr ZKPs SHALL be the same. 7.3. ServerKeyExchange ServerKeyExchange is extended as follows: enum { ecjpake } KeyExchangeAlgorithm; ecjpake Cragie & Hao Expires December 24, 2016 [Page 10] Internet-Draft ECJPAKE June 2016 Indicates the ServerKeyExchange message contains ServerECJPAKEParams. ServerKeyExchange for ecjpake SHALL be formatted as follows: struct { ECParameters curve_params; ECJPAKEKeyKP ecjpake_key_kp; } ServerECJPAKEParams; select (KeyExchangeAlgorithm) { case ecjpake: ServerECJPAKEParams params; } ServerKeyExchange; 7.4. ClientKeyExchange ClientKeyExchange is extended as follows: enum { ecjpake } KeyExchangeAlgorithm; ecjpake Indicates the ClientKeyExchange message contains ClientECJPAKEParams. ClientKeyExchange for ecjpake SHALL be formatted as follows: struct { ECJPAKEKeyKP ecjpake_key_kp; } ClientECJPAKEParams; select (KeyExchangeAlgorithm) { case ecjpake: ClientECJPAKEParams params; } ClientKeyExchange; 8. Calculations This section describes the calculations required to populate the data conveyed between Client and Server and also calculations required to verify knowledge proofs. The following notation is used throughout this section: Order of the base point: n Cragie & Hao Expires December 24, 2016 [Page 11] Internet-Draft ECJPAKE June 2016 8.1. User Identity Selection The Schnorr ZKP hash calculation requires non-confidential user identities. These identities need to be unique in the context of a transaction and be different for each party. In a peer-to-peer transaction where there is no ambiguity of identity, the identities can be a simple string representing the Client and Server respectively: +------------+----------+-------------------+--------------------+ | Originator | Name | Identity | Length of identity | +------------+----------+-------------------+--------------------+ | Client | "client" | 63 6c 69 65 6e 74 | 6 | | Server | "server" | 73 65 72 76 65 72 | 6 | +------------+----------+-------------------+--------------------+ Table 2: Simple Client and Server identities In a multi-party transaction, each party SHOULD additionally provide an identity in the ClientHello and/or ServerHello to uniquely distinguish their user identity. 8.2. Schnorr ZKP Hash Calculation The hash calculation is defined as follows: +-------------------+-----------------------------------+ | Public Key | Calculation | +-------------------+-----------------------------------+ | X1, X2, X3 and X4 | h = SHA-256(G, V, X, ID) mod n | | Xs | h = SHA-256(GB, V, Xs, IDs) mod n | | Xc | h = SHA-256(GA, V, Xc, IDc) mod n | +-------------------+-----------------------------------+ Table 3: Schnorr ZKP Hash Calculation Each item in the hash calculation is prepended with its length in octets represented an octet (length 4), formed by applying integer to octet string conversion as defined in Section 4.4. For example, the length of an uncompressed octet string representation of a public key is 65 (decimal) therefore the octet string (length 4) representation of 65 in hexadecimal is: o 00 00 00 41 Each public key (elliptic curve point) is first converted to an octet string according to Section 2.3.3 of [SEC1]. Cragie & Hao Expires December 24, 2016 [Page 12] Internet-Draft ECJPAKE June 2016 The concatentation order of the hash is as follows: 1. G (or GA, GB): Generator 2. V: ZKP ephemeral public key 3. X (or Xs, Xc): Public key to be verified 4. ID (or IDc, IDs): User ID (see Section 8.1) The hash is therefore performed on the concatenation as follows: o H = SHA-256(lenG || G || lenV || V || lenX || X || lenID || ID) An integer representation of the hash (see Section 4.5) is produced: o h = int(H) 8.3. Shared Secret The shared secret for the ServerKeyExchange and ClientKeyExchange calculations is required to be an integer in the range 1 to n-1. This section shows an example of how this could be practically accomplished using an initial password. The initial password is usually represented visually as a variable length character string using a subset of internationally recognized characters from the UTF-8 character set, which prevents the possibility of the resulting shared secret having the value 0. The initial password is then be converted into an octet string using UTF-8 conversion. The integer shared secret calculation is thus defined as follows, using the function defined in Section 4.5: s = int() mod n 8.3.1. Example Password: "d45yj8e" Equivalent octet string M using UTF-8 conversion (no null termination): 64 34 35 79 6a 38 65 Length mlen: 7 Cragie & Hao Expires December 24, 2016 [Page 13] Internet-Draft ECJPAKE June 2016 Shared secret: 0x643435796a3865 28204901945981028 (decimal) 8.4. ClientHello and ServerHello Calculations The structure ECJPAKEKeyKPPairList conveys the public key and associated Schnorr ZKP for ClientHello (X1 and X2) and ServerHello (X3 and X4). 8.4.1. Public Key Generation For X1, X2, X3 and X4, the value for the public key part X of the ECJPAKEKeyKP structure is generated as follows: The inputs are: o Base point: G o Order of the base point: n The public key of the key pair is calculated as follows: 1. A random integer in the range 1 to n-1 is assigned to private key x. 2. A public key associated with x is generated and assigned to X: X = G*x 3. X is assigned to the public key part X of the ECJPAKEKeyKP structure. 8.4.2. Schnorr ZKP Generation For X1, X2, X3 and X4, the values for the ZKP part zkp.V and zkp.r of the ECJPAKEKeyKP structure are generated as follows: The inputs are: o Base point: G o Order of the base point: n o Identity of originator: ID (IDc or IDs depending on context) Cragie & Hao Expires December 24, 2016 [Page 14] Internet-Draft ECJPAKE June 2016 o Key pair to provide a ZKP of: (X,x) (public key: X, private key: x), where X is X1, X2, X3, or X4 and x is x1, x2, x3, or x4, depending on context The ZKP is generated as follows: 1. A random integer in the range 1 to n-1 is assigned to ephemeral private key v. 2. An ephemeral public key associated with v is generated and assigned to V: V = G*v 3. An integer representation of a hash (see Section 8.2) is generated and assigned to h: h = int(SHA-256(G, V, X, ID)) mod n 4. A signature is generated and assigned to r: r = v - x*h mod n 5. V and r are assigned to the ZKP part zkp.V and zkp.r of the ECJPAKEKeyKP structure respectively. 8.4.3. Schnorr ZKP Verification For X1, X2, X3 and X4, the ECJPAKEKeyKP structure is verified as follows: The inputs are: o Base point: G o Order of the base point: n o Identity of originator: ID (IDc or IDs depending on context) o Public key to be verified: X (X1, X2, X3, or X4 depending on context) o ZKP ephemeral public key: V o ZKP signature: r The ZKP is verified as follows: Cragie & Hao Expires December 24, 2016 [Page 15] Internet-Draft ECJPAKE June 2016 1. An integer representation of a hash (see Section 8.2) is generated and assigned to h: h = int(SHA-256(G, V, X, ID)) mod n 2. A check point is generated and assigned to V': V'= X*h + G*r 3. The points V' and V are compared. If equal then the ZKP verifies, otherwise it does not verify. 8.5. ServerKeyExchange Calculations The structure ECJPAKEKeyKP conveys the public key and associated Schnorr ZKP for Xs. 8.5.1. Public Key Generation For Xs, the value for the public key part X of the ECJPAKEKeyKP structure is generated as follows: The inputs are: o Public keys: X1, X2 and X3 o Private key: x4 o Shared secret: s (integer format, see Section 8.3) o Order of the base point: n The public key of the key pair is calculated as follows: 1. A new generator is generated and assigned to GB: GB = X1 + X2 + X3 2. A private key is generated and assigned to xs: xs = x4*s mod n 3. A public key associated with xs is generated and assigned to Xs: Xs = GB*xs 4. Xs is assigned to the public key part X of the ECJPAKEKeyKP structure. Cragie & Hao Expires December 24, 2016 [Page 16] Internet-Draft ECJPAKE June 2016 8.5.2. Schnorr ZKP Generation For Xs, the values for the ZKP part zkp.V and zkp.r of the ECJPAKEKeyKP structure are generated as follows: The inputs are: o New generator: GB o Order of the base point: n o Identity of originator: IDs o Key pair to provide a ZKP of: (Xs,xs) (public key: Xs, private key: xs) The ZKP is generated as follows: 1. A random integer in the range 1 to n-1 is assigned to ephemeral private key v. 2. An ephemeral public key associated with v is generated and assigned to V: V = GB*v 3. An integer representation of a hash (see Section 8.2) is generated and assigned to h: h = int(SHA-256(GB, V, Xs, IDs)) mod n 4. A signature is generated and assigned to r: r = v - xs*h mod n 5. V and r are assigned to the ZKP part zkp.V and zkp.r of the ECJPAKEKeyKP structure respectively. 8.5.3. Schnorr ZKP Verification For Xs, the ECJPAKEKeyKP structure is verified as follows: The inputs are: o New generator: GB o Order of the base point: n Cragie & Hao Expires December 24, 2016 [Page 17] Internet-Draft ECJPAKE June 2016 o Identity of originator: IDs o Public key to be verified: Xs o ZKP ephemeral public key: V o ZKP signature: r The ZKP is verified as follows: 1. An integer representation of a hash (see Section 8.2) is generated and assigned to h: h = int(SHA-256(GB, V, Xs, IDs)) mod n 2. A check point is generated and assigned to V': V'= X*h + GB*r 3. The points V' and V are compared. If equal then the ZKP verifies, otherwise it does not verify. 8.6. ClientKeyExchange Calculations The structure ECJPAKEKeyKP conveys the public key and associated Schnorr ZKP for Xc. 8.6.1. Public Key Generation For Xc, the value for the public key part X of the ECJPAKEKeyKP structure is generated as follows: The inputs are: o Public keys: X1, X3 and X4 o Private key: x2 o Shared secret: s (integer format, see Section 8.3) o Order of the base point: n The public key of the key pair is calculated as follows: 1. A new generator is generated and assigned to GA: GA = X1 + X3 + X4 Cragie & Hao Expires December 24, 2016 [Page 18] Internet-Draft ECJPAKE June 2016 2. A private key is generated and assigned to xc: xc = x2*s mod n 3. A public key associated with xs is generated and assigned to Xc: Xc = GA*xc 4. Xc is assigned to the public key part X of the ECJPAKEKeyKP structure. 8.6.2. Schnorr ZKP Generation For Xc, the values for the ZKP part zkp.V and zkp.r of the ECJPAKEKeyKP structure are generated as follows: The inputs are: o New generator: GA o Order of the base point: n o Identity of originator: IDc o Key pair to provide a ZKP of: (Xc,xc) (public key: Xc, private key: xc) The ZKP is generated as follows: 1. A random integer in the range 1 to n-1 is assigned to ephemeral private key v. 2. An ephemeral public key associated with v is generated and assigned to V: V = GA*v 3. An integer representation of a hash (see Section 8.2) is generated and assigned to h: h = int(SHA-256(GA, V, Xc, IDc)) mod n 4. A signature is generated and assigned to r: r = v - xc*h mod n 5. V and r are assigned to the ZKP part zkp.V and zkp.r of the ECJPAKEKeyKP structure respectively. Cragie & Hao Expires December 24, 2016 [Page 19] Internet-Draft ECJPAKE June 2016 8.6.3. Schnorr ZKP Verification For Xc, the ECJPAKEKeyKP structure is verified as follows: The inputs are: o New generator: GA o Order of the base point: n o Identity of originator: IDc o Public key to be verified: Xc o ZKP ephemeral public key: V o ZKP signature: r The ZKP is verified as follows: 1. An integer representation of a hash (see Section 8.2) is generated and assigned to h: h = int(SHA-256(GA, V, Xc, IDc)) mod n 2. A check point is generated and assigned to V': V'= X*h + GA*r 3. The points V' and V are compared. If equal then the ZKP verifies, otherwise it does not verify. 8.7. Premaster Secret Generation The TLS-ECJ-PAKE handshake relies on the generation of identical premaster secrets at the client and server to verify the key establishment. The use of the protected Finished messages is therefore used for key confirmation purposes and to verify the handshake. 8.7.1. Server Premaster Secret Generation The inputs are: o Public key of the client: Xc o Public key: X2 Cragie & Hao Expires December 24, 2016 [Page 20] Internet-Draft ECJPAKE June 2016 o Private key: x4 o Shared secret: s (integer format, see Section 8.3) The premaster secret is generated as follows: 1. Compute PMSK: PMSK = (Xc - X2*x4*s)*x4 2. Compute PMS: PMS = SHA-256(str(32, X coordinate of PMSK)) 3. The master secret and key expansion is generated according to Section 8.1 and Section 6.3 of [RFC5246]. 8.7.2. Client Premaster Secret Generation The inputs are: o Public key of the server: Xs o Public key: X4 o Private key: x2 o Shared secret: s (integer format, see Section 8.3) The premaster secret is generated as follows: 1. Compute PMSK: PMSK = (Xs - X4*x2*s)*x2 2. Compute PMS: PMS = SHA-256(str(32, X coordinate of PMSK)) 3. The master secret and key expansion is generated according to Section 8.1 and Section 6.3 of [RFC5246]. 9. Acknowledgements The authors would like to thank Sorin Aliciuc, Richard Kelsey, Maurizio Nanni, Manuel Pegourie-Gonnard and Martin Turon for their helpful comments and assistance. Cragie & Hao Expires December 24, 2016 [Page 21] Internet-Draft ECJPAKE June 2016 10. IANA Considerations 10.1. Transport Layer Security (TLS) Parameters 10.1.1. TLS Cipher Suite Registry IANA is requested to add the following entries in the TLS Cipher Suite Registry: TLS_ECJPAKE_WITH_AES_128_CCM = {0xTBD, 0xTBD} TLS_ECJPAKE_WITH_AES_256_CCM = {0xTBD, 0xTBD} TLS_ECJPAKE_WITH_AES_128_CCM_8 = {0xTBD, 0xTBD} TLS_ECJPAKE_WITH_AES_256_CCM_8 = {0xTBD, 0xTBD} 10.2. Transport Layer Security (TLS) Extensions 10.2.1. ExtensionType Values IANA is requested to add the following entries in the ExtensionType Values: ecjpake_key_kp_pair = TBD 11. Security Considerations 11.1. Security Proof An independent study that proves security of J-PAKE in a model with algebraic adversaries and random oracles can be found in [ABM15]. 11.2. Counter Reuse The cipher suites described in this document are AES-CCM-based AEAD cipher suites, therefore the security considerations for counter reuse described in [RFC6655] also apply to these cipher suites. 11.3. Password The password forming the basis of the shared secret SHOULD be distributed in a secure out-of-band channel. In the specific case of [THREAD], this is achieved by the user enabling the use of the password only through a commissioning session where the user is in control of adding details of devices they wish to add to the Thread network. Cragie & Hao Expires December 24, 2016 [Page 22] Internet-Draft ECJPAKE June 2016 11.4. Rate Limiting An attacker could attempt to engage repeatedly with a ECJ-PAKE server in an attempt to guess the password. Servers SHOULD take steps to ensure the opportunity for repeated contact is limited. 11.5. Usage Restrictions The cipher suites described in this document have primarily been developed to enable authentication and authorization for network access for IoT devices, as described in [THREAD]. It is therefore RECOMMENDED that the use of these cipher suite is restricted to similar uses and SHOULD NOT be used in conjunction with web servers and web browsers unless consideration is given to secure entry of passwords in a browser. 11.6. Fixed Implementation Parameters The requirement to specify fixed parameters in a specific implementation limits the amount of negotiation that takes place between Client and Server. This effectively makes capability negotiation binary, i.e. if the implementation is incompatible, the handshake will simply fail. This is usually an important consideration in the applications TLS-ECJ-PAKE is recommended for, where complex negotiation is neither desirable nor recommended. 12. References 12.1. Normative References [CCM] National Institute of Standards and Technology, "Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality", SP 800-38C, May 2004, . [SEC1] Standards for Efficient Cryptography Group, "Standards for Efficient Cryptography: SEC 1: Elliptic Curve Cryptography", SECG SEC1-v2, May 2004, . [THREAD] Thread Group, "Thread Commissioning", July 2015, . Cragie & Hao Expires December 24, 2016 [Page 23] Internet-Draft ECJPAKE June 2016 [HR08] Hao, F. and P. Ryan, "Password Authenticated Key Exchange by Juggling", 16th Workshop on Security Protocols (SPW'08), May 2008, . [ABM15] Abdalla, M., Benhamouda, F., and P. MacKenzie, "Security of the J-PAKE Password-Authenticated Key Exchange Protocol", IEEE Symposium on Security and Privacy, May 2015, . [J-PAKE] Hao, F., "J-PAKE: Password Authenticated Key Exchange by Juggling", draft-hao-jpake-03 (work in progress), February 2016, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, DOI 10.17487/RFC4492, May 2006, . [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, . [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for Transport Layer Security (TLS)", RFC 6655, DOI 10.17487/RFC6655, July 2012, . Cragie & Hao Expires December 24, 2016 [Page 24] Internet-Draft ECJPAKE June 2016 [RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014, . 12.2. Informative References [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, DOI 10.17487/RFC6090, February 2011, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . Authors' Addresses Robert Cragie ARM Ltd. 110 Fulbourn Road Cambridge CB1 9NJ UK Email: robert.cragie@arm.com Feng Hao Newcastle University (UK) Claremont Tower, School of Computing Science, Newcastle University Newcastle upon Tyne NE1 7RU UK Email: feng.hao@ncl.ac.uk Cragie & Hao Expires December 24, 2016 [Page 25]