idnits 2.17.1 draft-cragie-tls-ecjpake-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 11, 2016) is 2906 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ChangeCipherSpec' is mentioned on line 317, but not defined -- Looks like a reference, but probably isn't: '2' on line 408 == Outdated reference: A later version (-06) exists of draft-hao-jpake-03 ** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 tls R. Cragie 3 Internet-Draft ARM Ltd. 4 Intended status: Informational F. Hao 5 Expires: November 12, 2016 Newcastle University (UK) 6 May 11, 2016 8 Elliptic Curve J-PAKE Cipher Suites for Transport Layer Security (TLS) 9 draft-cragie-tls-ecjpake-00 11 Abstract 13 This document defines new cipher suites based on an Elliptic Curve 14 Cryptography (ECC) variant of Password Authenticated Key Exchange by 15 Juggling (J-PAKE) for the Transport Layer Security (TLS) and Datagram 16 Transport Layer Security (DTLS) protocols. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on November 12, 2016. 35 Copyright Notice 37 Copyright (c) 2016 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 54 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. ECJ-PAKE Based AES-CCM Cipher Suites . . . . . . . . . . . . 4 56 3. Notations . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3.1. Elliptic Curve Points . . . . . . . . . . . . . . . . . . 5 58 3.2. Integers . . . . . . . . . . . . . . . . . . . . . . . . 6 59 3.3. Octet Strings . . . . . . . . . . . . . . . . . . . . . . 6 60 3.4. Integer to Octet String Conversion . . . . . . . . . . . 6 61 3.5. Octet String to Integer Conversion . . . . . . . . . . . 7 62 4. Handshake . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 5. Failure processing . . . . . . . . . . . . . . . . . . . . . 7 64 6. ECJ-PAKE TLS Extensions and Modification . . . . . . . . . . 7 65 6.1. New Structure Definitions . . . . . . . . . . . . . . . . 8 66 6.1.1. Public Key and Schnorr ZKP Pair . . . . . . . . . . . 8 67 6.1.2. Schnorr ZKP . . . . . . . . . . . . . . . . . . . . . 8 68 6.2. ClientHello and ServerHello TLS Extensions . . . . . . . 9 69 6.2.1. Existing Extensions . . . . . . . . . . . . . . . . . 9 70 6.2.2. Additional Extensions . . . . . . . . . . . . . . . . 9 71 6.3. ServerKeyExchange . . . . . . . . . . . . . . . . . . . . 10 72 6.4. ClientKeyExchange . . . . . . . . . . . . . . . . . . . . 10 73 7. Calculations . . . . . . . . . . . . . . . . . . . . . . . . 11 74 7.1. User Identity Selection . . . . . . . . . . . . . . . . . 11 75 7.2. Schnorr ZKP Hash Calculation . . . . . . . . . . . . . . 11 76 7.3. Shared Secret . . . . . . . . . . . . . . . . . . . . . . 12 77 7.3.1. Example . . . . . . . . . . . . . . . . . . . . . . . 13 78 7.4. ClientHello and ServerHello Calculations . . . . . . . . 13 79 7.4.1. Public Key Generation . . . . . . . . . . . . . . . . 13 80 7.4.2. Schnorr ZKP Generation . . . . . . . . . . . . . . . 14 81 7.4.3. Schnorr ZKP Verification . . . . . . . . . . . . . . 14 82 7.5. ServerKeyExchange Calculations . . . . . . . . . . . . . 15 83 7.5.1. Public Key Generation . . . . . . . . . . . . . . . . 15 84 7.5.2. Schnorr ZKP Generation . . . . . . . . . . . . . . . 16 85 7.5.3. Schnorr ZKP Verification . . . . . . . . . . . . . . 17 86 7.6. ClientKeyExchange Calculations . . . . . . . . . . . . . 17 87 7.6.1. Public Key Generation . . . . . . . . . . . . . . . . 17 88 7.6.2. Schnorr ZKP Generation . . . . . . . . . . . . . . . 18 89 7.6.3. Schnorr ZKP Verification . . . . . . . . . . . . . . 19 90 7.7. Premaster Secret Generation . . . . . . . . . . . . . . . 20 91 7.7.1. Server Premaster Secret Generation . . . . . . . . . 20 92 7.7.2. Client Premaster Secret Generation . . . . . . . . . 20 93 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 94 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 95 9.1. Transport Layer Security (TLS) Parameters . . . . . . . . 21 96 9.1.1. TLS Cipher Suite Registry . . . . . . . . . . . . . . 21 97 9.2. Transport Layer Security (TLS) Extensions . . . . . . . . 21 98 9.2.1. ExtensionType Values . . . . . . . . . . . . . . . . 21 99 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 100 10.1. Security Proof . . . . . . . . . . . . . . . . . . . . . 21 101 10.2. Counter Reuse . . . . . . . . . . . . . . . . . . . . . 22 102 10.3. Password . . . . . . . . . . . . . . . . . . . . . . . . 22 103 10.4. Rate Limiting . . . . . . . . . . . . . . . . . . . . . 22 104 10.5. Usage Restrictions . . . . . . . . . . . . . . . . . . . 22 105 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 106 11.1. Normative References . . . . . . . . . . . . . . . . . . 22 107 11.2. Informative References . . . . . . . . . . . . . . . . . 24 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 110 1. Introduction 112 This document defines new cipher suites based on an Elliptic Curve 113 Cryptography (ECC) variant of Password Authenticated Key Exchange by 114 Juggling (J-PAKE) for version 1.2 of Transport Layer Security (TLS) 115 protocol [RFC5246] as well as version 1.2 of the Datagram Transport 116 Layer Security (DTLS) protocol [RFC6347]. The cipher suites are AEAD 117 cipher suites using AES-CCM [CCM] based on the cipher suites defined 118 in [RFC7251], using ECJ-PAKE as an alternative key establishment 119 mechanism. 121 The existing set of TLS cipher suites are typically aimed at more 122 traditional client-server interactions, for example, a web browser to 123 web server. However, TLS and DTLS are increasingly being specified 124 for use in Internet-of-Things (IoT) standards for peer-to-peer 125 application layer interaction. For example, DTLS is specified as a 126 binding to provide security for the CoAP protocol [RFC7252], which is 127 widely used in IoT applications. 129 J-PAKE is a balanced password-authenticated key exchange (PAKE) 130 protocol resistant to off-line dictionary attack designed by Feng Hao 131 and Peter Ryan in 2008 [HR08]. The use of a PAKE for IoT devices is 132 highly appropriate as it allows a simple method of commissioning IoT 133 devices onto a network without requiring certificates to be issued 134 and maintained for each device. An ECC variant of J-PAKE [J-PAKE] is 135 particularly suited to IoT devices, which are often constrained with 136 regard to memory and processing power. The cipher suite 137 TLS_ECJPAKE_WITH_AES_128_CCM_8 as defined in this document is 138 currently being used in the Thread protocol [THREAD]. 140 1.1. Requirements Language 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in [RFC2119]. 146 1.2. Terminology 148 AEAD 150 Authenticated Encryption with Associated Data. 152 ECJ-PAKE 154 Elliptic Curve Cryptography (ECC) variant of Password 155 Authenticated Key Exchange by Juggling (J-PAKE). 157 ZKP 159 Zero-knowledge proof. 161 2. ECJ-PAKE Based AES-CCM Cipher Suites 163 The cipher suites defined in this document are based on the AES-CCM 164 Authenticated Encryption with Associated Data (AEAD) algorithms 165 AEAD_AES_128_CCM and AEAD_AES_256_CCM described in [RFC5116]. The 166 following cipher suites are defined: 168 TLS_ECJPAKE_WITH_AES_128_CCM = {0xTBD, 0xTBD} 169 TLS_ECJPAKE_WITH_AES_256_CCM = {0xTBD, 0xTBD} 170 TLS_ECJPAKE_WITH_AES_128_CCM_8 = {0xTBD, 0xTBD} 171 TLS_ECJPAKE_WITH_AES_256_CCM_8 = {0xTBD, 0xTBD} 173 These cipher suites make use of the AEAD capability in TLS 1.2 174 [RFC5246]. Cipher suites ending with "8" use eight-octet 175 authentication tags; the other cipher suites have 16-octet 176 authentication tags. The HMAC truncation option described in 177 Section 7 of [RFC6066] (which negotiates the "truncated_hmac" TLS 178 extension) does not have an effect on the cipher suites defined in 179 this document, because they do not use HMAC to protect TLS records. 181 The "nonce" input to the AEAD algorithm is as defined in [RFC6655]. 183 These cipher suites make use of the default TLS 1.2 Pseudorandom 184 Function (PRF), which uses HMAC with the SHA-256 hash function. 186 The following stipulations apply to the use of elliptic curves: 188 o Curves with a cofactor equal to one SHOULD be used; this 189 simplifies their use. 191 o The uncompressed point format MUST be supported. Other point 192 formats MAY be used. 194 o Fundamental ECC algorithms [RFC6090] MAY be used as an 195 implementation method. 197 3. Notations 199 This section describes the notations used in this document. 201 3.1. Elliptic Curve Points 203 The generator (base point) of an elliptic curve is represented by the 204 letter 'G': 206 G 208 A modified generator is represented by the letter 'G' concatenated 209 with a single uppercase character: 211 GB 213 Elliptic curve points are represented using a single uppercase 214 character or a single uppercase character concatenated with a single 215 lowercase character or decimal digit, for example: 217 X 219 Xc 221 X2 223 Conversion to and from elliptic curve points to octet strings is as 224 specified in Sections 2.3.3 and 2.3.4 of [SEC1]. 226 Point multiplication is shown as an elliptic curve point multiplied 227 by a scalar integer using the '*' operator, for example: 229 G*x 231 Point addition or subtraction is shown as the addition or subtraction 232 of elliptic curve points or scalar multiplied elliptic curve points 233 using the '+' and '-' operators respectively, for example: 235 X1 + X3 + X4 237 X*h + G*r 239 Xs - X4*x2*s 241 3.2. Integers 243 Integers are represented using a single lowercase character or a 244 single lowercase character followed by a single lowercase character 245 or decimal digit, for example: 247 x 249 xc 251 x2 253 Where expressed, integers are shown in hexadecimal and/or decimal 254 form. Hexadecimal numbers have an '0x' prefix. For example: 256 0x12ab34cd 258 3132110061 260 Integer multiplication is shown as two integers multiplied together 261 using the '*' operator: 263 x*s 265 Integer addition or subtraction is shown as the addition or 266 subtraction of integers or multiplied integers using the '+' and '-' 267 operators respectively: 269 v - x*h 271 3.3. Octet Strings 273 Octet strings are expressed in a hexadecimal form, with no '0x' 274 prefix and with a space separator, first octet leftmost, for example: 276 12 ab 34 cd 278 3.4. Integer to Octet String Conversion 280 Integer to octet string conversion SHALL be performed as stated in 281 Section 2.3.7 of [SEC1]. It is represented as follows: 283 M = str(mlen, x) 285 where x, mlen, and M are the parameters as stated in Section 2.3.7 of 286 [SEC1]. 288 3.5. Octet String to Integer Conversion 290 Octet string to integer conversion SHALL be as stated in section 291 2.3.8 of [SEC1]. It is represented as follows: 293 x = int(mlen, M) 295 where x, mlen, and M are the parameters as stated in Section 2.3.8 of 296 [SEC1]. 298 4. Handshake 300 The TLS-ECJ-PAKE handshake is as follows, augmented with parameters 301 in braces to show the ECJ-PAKE material conveyed in each case: 303 Client Server 304 ------ ------ 305 ClientHello --------> 306 {(X1,ZKP(X1)), 307 (X2,ZKP(X2))} ServerHello 308 {(X3, ZKP(X3)), 309 (X4, ZKP(X4))} 310 ServerKeyExchange 311 {Xs, ZKP(Xs)} 312 <-------- ServerHelloDone 313 ClientKeyExchange 314 {Xc, ZKP(Xc)} 315 [ChangeCipherSpec] 316 Finished --------> 317 [ChangeCipherSpec] 318 <-------- Finished 319 Application Data <-------> Application Data 321 Figure 1: Message flow in a TLS-ECJ-PAKE handshake 323 5. Failure processing 325 If there are failures for any reason on client or server side, for 326 example, Schnorr ZKP verification or missing extensions, the 327 handshake SHALL abort immediately and send a TLS Error Alert message 328 to the peer, using code 40 (handshake_failure) (see Section 7.2 of 329 [RFC5246]). 331 6. ECJ-PAKE TLS Extensions and Modification 333 This section describes existing and newly-defined extensions required 334 for ECJ-PAKE-TLS. 336 6.1. New Structure Definitions 338 TLS-ECJ-PAKE requires new structure definitions for: 340 o Public key and Schnorr ZKP pair 342 o Schnorr ZKP 344 6.1.1. Public Key and Schnorr ZKP Pair 346 The TLS structure is as follows: 348 struct { 349 ECPoint X; 350 ECSchnorrZKP zkp; 351 } ECJPAKEKeyKP; 353 X 355 Public key represented as an elliptic curve point. ECPoint is 356 defined in [RFC4492]. 358 zkp 360 ECSchnorrZKP is defined in Section 6.1.2. 362 6.1.2. Schnorr ZKP 364 The TLS structure is as follows: 366 struct { 367 ECPoint V; 368 opaque r<1..2^8-1>; 369 } ECSchnorrZKP; 371 V 373 Ephemeral public key represented as an elliptic curve point. 374 ECPoint is defined in [RFC4492]. 376 r 378 Schnorr signature. 380 6.2. ClientHello and ServerHello TLS Extensions 382 6.2.1. Existing Extensions 384 The following TLS extensions defined in Section 4 of [RFC4492] SHALL 385 be present in ClientHello: 387 o Supported Elliptic Curves Extension (NamedCurve, 388 EllipticCurveList) 390 o Supported Point Formats Extension (ECPointFormat, 391 ECPointFormatList) 393 and the following TLS extension defined in Section 4 of [RFC4492] 394 SHALL be present in ServerHello: 396 o Supported Point Formats Extension (ECPointFormat, 397 ECPointFormatList) 399 6.2.2. Additional Extensions 401 The following extension SHALL additionally be present in both 402 ClientHello and ServerHello: 404 enum { ecjpake_key_kp_pair(TBC) } ExtensionType; 406 struct { 407 opaque identity<0..2^16-1>; 408 ECJPAKEKeyKP ecjpake_key_kp_pair_list[2]; 409 } ECJPAKEKeyKPPairList; 411 identity 413 MAY be included if the Client or Server needs to uniquely identify 414 themselves to the other party. An identity is used in the Schnorr 415 ZKP hash calculation (see Section 7.2). 417 ecjpake_key_kp_pair_list 419 The list is precisely two elements long. The list in a 420 ClientHello extension conveys public keys X1 and X2 and the list 421 in a ServerHello extension conveys public keys X3 and X4, with 422 associated Schnorr ZKPs. 424 Note: When used in conjunction with DTLS and denial-of-service 425 countermeasures as described in Section 4.2.1 of [RFC6347], the 426 ECJPAKEKeyKPPairList in the subsequent ClientHello message SHALL be 427 the same as the ECJPAKEKeyKPPairList in initial ClientHello message, 428 i.e. the public keys X1 and X2 and associated Schnorr ZKPs SHALL be 429 the same. 431 6.3. ServerKeyExchange 433 ServerKeyExchange is extended as follows: 435 enum { ecjpake } KeyExchangeAlgorithm; 437 ecjpake 439 Indicates the ServerKeyExchange message contains 440 ServerECJPAKEParams. 442 ServerKeyExchange for ecjpake SHALL be formatted as follows: 444 struct { 445 ECParameters curve_params; 446 ECJPAKEKeyKP ecjpake_key_kp; 447 } ServerECJPAKEParams; 449 select (KeyExchangeAlgorithm) { 450 case ecjpake: 451 ServerECJPAKEParams params; 452 } ServerKeyExchange; 454 6.4. ClientKeyExchange 456 ClientKeyExchange is extended as follows: 458 enum { ecjpake } KeyExchangeAlgorithm; 460 ecjpake 462 Indicates the ClientKeyExchange message contains 463 ClientECJPAKEParams. 465 ClientKeyExchange for ecjpake SHALL be formatted as follows: 467 struct { 468 ECJPAKEKeyKP ecjpake_key_kp; 469 } ClientECJPAKEParams; 471 select (KeyExchangeAlgorithm) { 472 case ecjpake: 473 ClientECJPAKEParams params; 474 } ClientKeyExchange; 476 7. Calculations 478 This section describes the calculations required to populate the data 479 conveyed between Client and Server and also calculations required to 480 verify knowledge proofs. 482 The following notation is used throughout this section: 484 Order of the base point: n 486 7.1. User Identity Selection 488 The Schnorr ZKP hash calculation requires non-confidential user 489 identities. These identities need to be unique in the context of a 490 transaction and be different for each party. In a peer-to-peer 491 transaction where there is no ambiguity of identity, the identities 492 can be a simple string representing the Client and Server 493 respectively: 495 +------------+----------+-------------------+--------------------+ 496 | Originator | Name | Identity | Length of identity | 497 +------------+----------+-------------------+--------------------+ 498 | Client | "client" | 63 6c 69 65 6e 74 | 6 | 499 | Server | "server" | 73 65 72 76 65 72 | 6 | 500 +------------+----------+-------------------+--------------------+ 502 Table 1: Simple Client and Server identities 504 In a multi-party transaction, each party SHOULD additionally provide 505 an identity in the ClientHello and/or ServerHello to uniquely 506 distinguish their user identity. 508 7.2. Schnorr ZKP Hash Calculation 510 The hash calculation is defined as follows: 512 +-------------------+-----------------------------------+ 513 | Public Key | Calculation | 514 +-------------------+-----------------------------------+ 515 | X1, X2, X3 and X4 | h = SHA-256(G, V, X, ID) mod n | 516 | Xs | h = SHA-256(GB, V, Xs, IDs) mod n | 517 | Xc | h = SHA-256(GA, V, Xc, IDc) mod n | 518 +-------------------+-----------------------------------+ 520 Table 2: Schnorr ZKP Hash Calculation 522 Each item in the hash calculation is prepended with its length in 523 octets represented an octet (length 4), formed by applying integer to 524 octet string conversion as defined in Section 3.4. For example, the 525 length of an uncompressed octet string representation of a public key 526 is 65 (decimal) therefore the octet string (length 4) representation 527 of 65 in hexadecimal is: 529 o 00 00 00 41 531 Each public key (elliptic curve point) is first converted to an octet 532 string according to Section 2.3.3 of [SEC1]. 534 The concatentation order of the hash is as follows: 536 1. G (or GA, GB): Generator 538 2. V: ZKP ephemeral public key 540 3. X (or Xs, Xc): Public key to be verified 542 4. ID (or IDc, IDs): User ID (see Section 7.1) 544 The hash is therefore performed on the concatenation as follows: 546 o H = SHA-256(lenG || G || lenV || V || lenX || X || lenID || ID) 548 An integer representation of the hash (see Section 3.5) is produced: 550 o h = int(H) 552 7.3. Shared Secret 554 The shared secret for the ServerKeyExchange and ClientKeyExchange 555 calculations is required to be an integer in the range 1 to n-1. 556 This section shows an example of how this could be practically 557 accomplished using an initial password. The initial password is 558 usually represented visually as a variable length character string 559 using a subset of internationally recognized characters from the 560 UTF-8 character set, which prevents the possibility of the resulting 561 shared secret having the value 0. The initial password is then be 562 converted into an octet string using UTF-8 conversion. 563 The integer shared secret calculation is thus defined as follows, 564 using the function defined in Section 3.5: 566 s = int() mod n 568 7.3.1. Example 570 Password: 572 "d45yj8e" 574 Equivalent octet string M using UTF-8 conversion (no null 575 termination): 577 64 34 35 79 6a 38 65 579 Length mlen: 581 7 583 Shared secret: 585 0x643435796a3865 587 28204901945981028 (decimal) 589 7.4. ClientHello and ServerHello Calculations 591 The structure ECJPAKEKeyKPPairList conveys the public key and 592 associated Schnorr ZKP for ClientHello (X1 and X2) and ServerHello 593 (X3 and X4). 595 7.4.1. Public Key Generation 597 For X1, X2, X3 and X4, the value for the public key part X of the 598 ECJPAKEKeyKP structure is generated as follows: 600 The inputs are: 602 o Base point: G 604 o Order of the base point: n 606 The public key of the key pair is calculated as follows: 608 1. A random integer in the range 1 to n-1 is assigned to private key 609 x. 611 2. A public key associated with x is generated and assigned to X: 613 X = G*x 615 3. X is assigned to the public key part X of the ECJPAKEKeyKP 616 structure. 618 7.4.2. Schnorr ZKP Generation 620 For X1, X2, X3 and X4, the values for the ZKP part zkp.V and zkp.r of 621 the ECJPAKEKeyKP structure are generated as follows: 623 The inputs are: 625 o Base point: G 627 o Order of the base point: n 629 o Identity of originator: ID (IDc or IDs depending on context) 631 o Key pair to provide a ZKP of: (X,x) (public key: X, private key: 632 x), where X is X1, X2, X3, or X4 and x is x1, x2, x3, or x4, 633 depending on context 635 The ZKP is generated as follows: 637 1. A random integer in the range 1 to n-1 is assigned to ephemeral 638 private key v. 640 2. An ephemeral public key associated with v is generated and 641 assigned to V: 643 V = G*v 645 3. An integer representation of a hash (see Section 7.2) is 646 generated and assigned to h: 648 h = int(SHA-256(G, V, X, ID)) mod n 650 4. A signature is generated and assigned to r: 652 r = v - x*h mod n 654 5. V and r are assigned to the ZKP part zkp.V and zkp.r of the 655 ECJPAKEKeyKP structure respectively. 657 7.4.3. Schnorr ZKP Verification 659 For X1, X2, X3 and X4, the ECJPAKEKeyKP structure is verified as 660 follows: 662 The inputs are: 664 o Base point: G 666 o Order of the base point: n 668 o Identity of originator: ID (IDc or IDs depending on context) 670 o Public key to be verified: X (X1, X2, X3, or X4 depending on 671 context) 673 o ZKP ephemeral public key: V 675 o ZKP signature: r 677 The ZKP is verified as follows: 679 1. An integer representation of a hash (see Section 7.2) is 680 generated and assigned to h: 682 h = int(SHA-256(G, V, X, ID)) mod n 684 2. A check point is generated and assigned to V': 686 V'= X*h + G*r 688 3. The points V' and V are compared. If equal then the ZKP 689 verifies, otherwise it does not verify. 691 7.5. ServerKeyExchange Calculations 693 The structure ECJPAKEKeyKP conveys the public key and associated 694 Schnorr ZKP for Xs. 696 7.5.1. Public Key Generation 698 For Xs, the value for the public key part X of the ECJPAKEKeyKP 699 structure is generated as follows: 701 The inputs are: 703 o Public keys: X1, X2 and X3 705 o Private key: x4 707 o Shared secret: s (integer format, see Section 7.3) 709 o Order of the base point: n 711 The public key of the key pair is calculated as follows: 713 1. A new generator is generated and assigned to GB: 715 GB = X1 + X2 + X3 717 2. A private key is generated and assigned to xs: 719 xs = x4*s mod n 721 3. A public key associated with xs is generated and assigned to Xs: 723 Xs = GB*xs 725 4. Xs is assigned to the public key part X of the ECJPAKEKeyKP 726 structure. 728 7.5.2. Schnorr ZKP Generation 730 For Xs, the values for the ZKP part zkp.V and zkp.r of the 731 ECJPAKEKeyKP structure are generated as follows: 733 The inputs are: 735 o New generator: GB 737 o Order of the base point: n 739 o Identity of originator: IDs 741 o Key pair to provide a ZKP of: (Xs,xs) (public key: Xs, private 742 key: xs) 744 The ZKP is generated as follows: 746 1. A random integer in the range 1 to n-1 is assigned to ephemeral 747 private key v. 749 2. An ephemeral public key associated with v is generated and 750 assigned to V: 752 V = GB*v 754 3. An integer representation of a hash (see Section 7.2) is 755 generated and assigned to h: 757 h = int(SHA-256(GB, V, Xs, IDs)) mod n 759 4. A signature is generated and assigned to r: 761 r = v - xs*h mod n 763 5. V and r are assigned to the ZKP part zkp.V and zkp.r of the 764 ECJPAKEKeyKP structure respectively. 766 7.5.3. Schnorr ZKP Verification 768 For Xs, the ECJPAKEKeyKP structure is verified as follows: 770 The inputs are: 772 o New generator: GB 774 o Order of the base point: n 776 o Identity of originator: IDs 778 o Public key to be verified: Xs 780 o ZKP ephemeral public key: V 782 o ZKP signature: r 784 The ZKP is verified as follows: 786 1. An integer representation of a hash (see Section 7.2) is 787 generated and assigned to h: 789 h = int(SHA-256(GB, V, Xs, IDs)) mod n 791 2. A check point is generated and assigned to V': 793 V'= X*h + GB*r 795 3. The points V' and V are compared. If equal then the ZKP 796 verifies, otherwise it does not verify. 798 7.6. ClientKeyExchange Calculations 800 The structure ECJPAKEKeyKP conveys the public key and associated 801 Schnorr ZKP for Xc. 803 7.6.1. Public Key Generation 805 For Xc, the value for the public key part X of the ECJPAKEKeyKP 806 structure is generated as follows: 808 The inputs are: 810 o Public keys: X1, X3 and X4 812 o Private key: x2 814 o Shared secret: s (integer format, see Section 7.3) 816 o Order of the base point: n 818 The public key of the key pair is calculated as follows: 820 1. A new generator is generated and assigned to GA: 822 GA = X1 + X3 + X4 824 2. A private key is generated and assigned to xc: 826 xc = x2*s mod n 828 3. A public key associated with xs is generated and assigned to Xc: 830 Xc = GA*xc 832 4. Xc is assigned to the public key part X of the ECJPAKEKeyKP 833 structure. 835 7.6.2. Schnorr ZKP Generation 837 For Xc, the values for the ZKP part zkp.V and zkp.r of the 838 ECJPAKEKeyKP structure are generated as follows: 840 The inputs are: 842 o New generator: GA 844 o Order of the base point: n 846 o Identity of originator: IDc 848 o Key pair to provide a ZKP of: (Xc,xc) (public key: Xc, private 849 key: xc) 851 The ZKP is generated as follows: 853 1. A random integer in the range 1 to n-1 is assigned to ephemeral 854 private key v. 856 2. An ephemeral public key associated with v is generated and 857 assigned to V: 859 V = GA*v 861 3. An integer representation of a hash (see Section 7.2) is 862 generated and assigned to h: 864 h = int(SHA-256(GA, V, Xc, IDc)) mod n 866 4. A signature is generated and assigned to r: 868 r = v - xc*h mod n 870 5. V and r are assigned to the ZKP part zkp.V and zkp.r of the 871 ECJPAKEKeyKP structure respectively. 873 7.6.3. Schnorr ZKP Verification 875 For Xc, the ECJPAKEKeyKP structure is verified as follows: 877 The inputs are: 879 o New generator: GA 881 o Order of the base point: n 883 o Identity of originator: IDc 885 o Public key to be verified: Xc 887 o ZKP ephemeral public key: V 889 o ZKP signature: r 891 The ZKP is verified as follows: 893 1. An integer representation of a hash (see Section 7.2) is 894 generated and assigned to h: 896 h = int(SHA-256(GA, V, Xc, IDc)) mod n 898 2. A check point is generated and assigned to V': 900 V'= X*h + GA*r 902 3. The points V' and V are compared. If equal then the ZKP 903 verifies, otherwise it does not verify. 905 7.7. Premaster Secret Generation 907 The TLS-ECJ-PAKE handshake relies on the generation of identical 908 premaster secrets at the client and server to verify the key 909 establishment. The use of the protected Finished messages is 910 therefore used for key confirmation purposes and to verify the 911 handshake. 913 7.7.1. Server Premaster Secret Generation 915 The inputs are: 917 o Public key of the client: Xc 919 o Public key: X2 921 o Private key: x4 923 o Shared secret: s (integer format, see Section 7.3) 925 The premaster secret is generated as follows: 927 1. Compute PMSK: 929 PMSK = (Xc - X2*x4*s)*x4 931 2. Compute PMS: 933 PMS = SHA-256(str(32, X coordinate of PMSK)) 935 3. The master secret and key expansion is generated according to 936 Section 8.1 and Section 6.3 of [RFC5246]. 938 7.7.2. Client Premaster Secret Generation 940 The inputs are: 942 o Public key of the server: Xs 944 o Public key: X4 946 o Private key: x2 948 o Shared secret: s (integer format, see Section 7.3) 950 The premaster secret is generated as follows: 952 1. Compute PMSK: 954 PMSK = (Xs - X4*x2*s)*x2 956 2. Compute PMS: 958 PMS = SHA-256(str(32, X coordinate of PMSK)) 960 3. The master secret and key expansion is generated according to 961 Section 8.1 and Section 6.3 of [RFC5246]. 963 8. Acknowledgements 965 The authors would like to thank Sorin Aliciuc, Richard Kelsey, 966 Maurizio Nanni, Manuel Pegourie-Gonnard and Martin Turon for their 967 helpful comments and assistance. 969 9. IANA Considerations 971 9.1. Transport Layer Security (TLS) Parameters 973 9.1.1. TLS Cipher Suite Registry 975 IANA is requested to add the following entries in the TLS Cipher 976 Suite Registry: 978 TLS_ECJPAKE_WITH_AES_128_CCM = {0xTBD, 0xTBD} 979 TLS_ECJPAKE_WITH_AES_256_CCM = {0xTBD, 0xTBD} 980 TLS_ECJPAKE_WITH_AES_128_CCM_8 = {0xTBD, 0xTBD} 981 TLS_ECJPAKE_WITH_AES_256_CCM_8 = {0xTBD, 0xTBD} 983 9.2. Transport Layer Security (TLS) Extensions 985 9.2.1. ExtensionType Values 987 IANA is requested to add the following entries in the ExtensionType 988 Values: 990 ecjpake_key_kp_pair = TBD 992 10. Security Considerations 994 10.1. Security Proof 996 An independent study that proves security of J-PAKE in a model with 997 algebraic adversaries and random oracles can be found in [ABM15]. 999 10.2. Counter Reuse 1001 The cipher suites described in this document are AES-CCM-based AEAD 1002 cipher suites, therefore the security considerations for counter 1003 reuse described in [RFC6655] also apply to these cipher suites. 1005 10.3. Password 1007 The password forming the basis of the shared secret SHOULD be 1008 distributed in a secure out-of-band channel. In the specific case of 1009 [THREAD], this is achieved by the user enabling the use of the 1010 password only through a commissioning session where the user is in 1011 control of adding details of devices they wish to add to the Thread 1012 network. 1014 10.4. Rate Limiting 1016 An attacker could attempt to engage repeatedly with a ECJ-PAKE server 1017 in an attempt to guess the password. Servers SHOULD take steps to 1018 ensure the opportunity for repeated contact is limited. 1020 10.5. Usage Restrictions 1022 The cipher suites described in this document have primarily been 1023 developed to enable authentication and authorization for network 1024 access for IoT devices, as described in [THREAD]. It is therefore 1025 RECOMMENDED that the use of these cipher suite is restricted to 1026 similar uses and SHOULD NOT be used in conjunction with web servers 1027 and web browsers unless consideration is given to secure entry of 1028 passwords in a browser. 1030 11. References 1032 11.1. Normative References 1034 [CCM] National Institute of Standards and Technology, 1035 "Recommendation for Block Cipher Modes of Operation: The 1036 CCM Mode for Authentication and Confidentiality", SP 1037 800-38C, May 2004, . 1040 [SEC1] Standards for Efficient Cryptography Group, "Standards for 1041 Efficient Cryptography: SEC 1: Elliptic Curve 1042 Cryptography", SECG SEC1-v2, May 2004, 1043 . 1045 [THREAD] Thread Group, "Thread Commissioning", July 2015, 1046 . 1049 [HR08] Hao, F. and P. Ryan, "Password Authenticated Key Exchange 1050 by Juggling", 16th Workshop on Security Protocols 1051 (SPW'08), May 2008, 1052 . 1055 [ABM15] Abdalla, M., Benhamouda, F., and P. MacKenzie, "Security 1056 of the J-PAKE Password-Authenticated Key Exchange 1057 Protocol", IEEE Symposium on Security and Privacy, May 1058 2015, 1059 . 1062 [J-PAKE] Hao, F., "J-PAKE: Password Authenticated Key Exchange by 1063 Juggling", draft-hao-jpake-03 (work in progress), February 1064 2016, . 1066 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1067 Requirement Levels", BCP 14, RFC 2119, 1068 DOI 10.17487/RFC2119, March 1997, 1069 . 1071 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 1072 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 1073 for Transport Layer Security (TLS)", RFC 4492, 1074 DOI 10.17487/RFC4492, May 2006, 1075 . 1077 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 1078 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 1079 . 1081 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1082 (TLS) Protocol Version 1.2", RFC 5246, 1083 DOI 10.17487/RFC5246, August 2008, 1084 . 1086 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1087 Extensions: Extension Definitions", RFC 6066, 1088 DOI 10.17487/RFC6066, January 2011, 1089 . 1091 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 1092 Transport Layer Security (TLS)", RFC 6655, 1093 DOI 10.17487/RFC6655, July 2012, 1094 . 1096 [RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- 1097 CCM Elliptic Curve Cryptography (ECC) Cipher Suites for 1098 TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014, 1099 . 1101 11.2. Informative References 1103 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 1104 Curve Cryptography Algorithms", RFC 6090, 1105 DOI 10.17487/RFC6090, February 2011, 1106 . 1108 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1109 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1110 January 2012, . 1112 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1113 Application Protocol (CoAP)", RFC 7252, 1114 DOI 10.17487/RFC7252, June 2014, 1115 . 1117 Authors' Addresses 1119 Robert Cragie 1120 ARM Ltd. 1121 110 Fulbourn Road 1122 Cambridge CB1 9NJ 1123 UK 1125 Email: robert.cragie@arm.com 1127 Feng Hao 1128 Newcastle University (UK) 1129 Claremont Tower, School of Computing Science, Newcastle University 1130 Newcastle upon Tyne NE1 7RU 1131 UK 1133 Email: feng.hao@ncl.ac.uk