idnits 2.17.1 draft-cragie-tls-ecjpake-01.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 (June 22, 2016) is 2836 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ChangeCipherSpec' is mentioned on line 344, but not defined -- Looks like a reference, but probably isn't: '2' on line 440 == 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: December 24, 2016 Newcastle University (UK) 6 June 22, 2016 8 Elliptic Curve J-PAKE Cipher Suites for Transport Layer Security (TLS) 9 draft-cragie-tls-ecjpake-01 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 December 24, 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 . . . . . . . . . . . . . . . . . . 4 54 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. ECJ-PAKE Based AES-CCM Cipher Suites . . . . . . . . . . . . 4 56 3. Specific Fixed Implementation Parameters . . . . . . . . . . 5 57 4. Notations . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4.1. Elliptic Curve Points . . . . . . . . . . . . . . . . . . 5 59 4.2. Integers . . . . . . . . . . . . . . . . . . . . . . . . 6 60 4.3. Octet Strings . . . . . . . . . . . . . . . . . . . . . . 7 61 4.4. Integer to Octet String Conversion . . . . . . . . . . . 7 62 4.5. Octet String to Integer Conversion . . . . . . . . . . . 7 63 5. Handshake . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 6. Failure processing . . . . . . . . . . . . . . . . . . . . . 8 65 7. ECJ-PAKE TLS Extensions and Modification . . . . . . . . . . 8 66 7.1. New Structure Definitions . . . . . . . . . . . . . . . . 8 67 7.1.1. Public Key and Schnorr ZKP Pair . . . . . . . . . . . 8 68 7.1.2. Schnorr ZKP . . . . . . . . . . . . . . . . . . . . . 9 69 7.2. ClientHello and ServerHello TLS Extensions . . . . . . . 9 70 7.2.1. Existing Extensions . . . . . . . . . . . . . . . . . 9 71 7.2.2. Additional Extensions . . . . . . . . . . . . . . . . 10 72 7.3. ServerKeyExchange . . . . . . . . . . . . . . . . . . . . 10 73 7.4. ClientKeyExchange . . . . . . . . . . . . . . . . . . . . 11 74 8. Calculations . . . . . . . . . . . . . . . . . . . . . . . . 11 75 8.1. User Identity Selection . . . . . . . . . . . . . . . . . 12 76 8.2. Schnorr ZKP Hash Calculation . . . . . . . . . . . . . . 12 77 8.3. Shared Secret . . . . . . . . . . . . . . . . . . . . . . 13 78 8.3.1. Example . . . . . . . . . . . . . . . . . . . . . . . 13 79 8.4. ClientHello and ServerHello Calculations . . . . . . . . 14 80 8.4.1. Public Key Generation . . . . . . . . . . . . . . . . 14 81 8.4.2. Schnorr ZKP Generation . . . . . . . . . . . . . . . 14 82 8.4.3. Schnorr ZKP Verification . . . . . . . . . . . . . . 15 83 8.5. ServerKeyExchange Calculations . . . . . . . . . . . . . 16 84 8.5.1. Public Key Generation . . . . . . . . . . . . . . . . 16 85 8.5.2. Schnorr ZKP Generation . . . . . . . . . . . . . . . 17 86 8.5.3. Schnorr ZKP Verification . . . . . . . . . . . . . . 17 87 8.6. ClientKeyExchange Calculations . . . . . . . . . . . . . 18 88 8.6.1. Public Key Generation . . . . . . . . . . . . . . . . 18 89 8.6.2. Schnorr ZKP Generation . . . . . . . . . . . . . . . 19 90 8.6.3. Schnorr ZKP Verification . . . . . . . . . . . . . . 20 91 8.7. Premaster Secret Generation . . . . . . . . . . . . . . . 20 92 8.7.1. Server Premaster Secret Generation . . . . . . . . . 20 93 8.7.2. Client Premaster Secret Generation . . . . . . . . . 21 94 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 95 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 96 10.1. Transport Layer Security (TLS) Parameters . . . . . . . 22 97 10.1.1. TLS Cipher Suite Registry . . . . . . . . . . . . . 22 99 10.2. Transport Layer Security (TLS) Extensions . . . . . . . 22 100 10.2.1. ExtensionType Values . . . . . . . . . . . . . . . . 22 101 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 102 11.1. Security Proof . . . . . . . . . . . . . . . . . . . . . 22 103 11.2. Counter Reuse . . . . . . . . . . . . . . . . . . . . . 22 104 11.3. Password . . . . . . . . . . . . . . . . . . . . . . . . 22 105 11.4. Rate Limiting . . . . . . . . . . . . . . . . . . . . . 23 106 11.5. Usage Restrictions . . . . . . . . . . . . . . . . . . . 23 107 11.6. Fixed Implementation Parameters . . . . . . . . . . . . 23 108 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 109 12.1. Normative References . . . . . . . . . . . . . . . . . . 23 110 12.2. Informative References . . . . . . . . . . . . . . . . . 25 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 113 1. Introduction 115 This document defines new cipher suites based on an Elliptic Curve 116 Cryptography (ECC) variant of Password Authenticated Key Exchange by 117 Juggling (J-PAKE) for version 1.2 of Transport Layer Security (TLS) 118 protocol [RFC5246] as well as version 1.2 of the Datagram Transport 119 Layer Security (DTLS) protocol [RFC6347]. The cipher suites are AEAD 120 cipher suites using AES-CCM [CCM] based on the cipher suites defined 121 in [RFC7251], using ECJ-PAKE as an alternative key establishment 122 mechanism. 124 The existing set of TLS cipher suites are typically aimed at more 125 traditional client-server interactions, for example, a web browser to 126 web server. However, TLS and DTLS are increasingly being specified 127 for use in Internet-of-Things (IoT) standards for peer-to-peer 128 application layer interaction. For example, DTLS is specified as a 129 binding to provide security for the CoAP protocol [RFC7252], which is 130 widely used in IoT applications. 132 J-PAKE is a balanced password-authenticated key exchange (PAKE) 133 protocol resistant to off-line dictionary attack designed by Feng Hao 134 and Peter Ryan in 2008 [HR08]. The use of a PAKE for IoT devices is 135 highly appropriate as it allows a simple method of commissioning IoT 136 devices onto a network without requiring certificates to be issued 137 and maintained for each device. An ECC variant of J-PAKE [J-PAKE] is 138 particularly suited to IoT devices, which are often constrained with 139 regard to memory and processing power. The cipher suite 140 TLS_ECJPAKE_WITH_AES_128_CCM_8 as defined in this document is 141 currently being used in the Thread protocol [THREAD]. 143 1.1. Requirements Language 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119]. 149 1.2. Terminology 151 AEAD 153 Authenticated Encryption with Associated Data. 155 ECJ-PAKE 157 Elliptic Curve Cryptography (ECC) variant of Password 158 Authenticated Key Exchange by Juggling (J-PAKE). 160 ZKP 162 Zero-knowledge proof. 164 2. ECJ-PAKE Based AES-CCM Cipher Suites 166 The cipher suites defined in this document are based on the AES-CCM 167 Authenticated Encryption with Associated Data (AEAD) algorithms 168 AEAD_AES_128_CCM and AEAD_AES_256_CCM described in [RFC5116]. The 169 following cipher suites are defined: 171 TLS_ECJPAKE_WITH_AES_128_CCM = {0xTBD, 0xTBD} 172 TLS_ECJPAKE_WITH_AES_256_CCM = {0xTBD, 0xTBD} 173 TLS_ECJPAKE_WITH_AES_128_CCM_8 = {0xTBD, 0xTBD} 174 TLS_ECJPAKE_WITH_AES_256_CCM_8 = {0xTBD, 0xTBD} 176 These cipher suites make use of the AEAD capability in TLS 1.2 177 [RFC5246]. Cipher suites ending with "8" use eight-octet 178 authentication tags; the other cipher suites have 16-octet 179 authentication tags. The HMAC truncation option described in 180 Section 7 of [RFC6066] (which negotiates the "truncated_hmac" TLS 181 extension) does not have an effect on the cipher suites defined in 182 this document, because they do not use HMAC to protect TLS records. 184 The "nonce" input to the AEAD algorithm is as defined in [RFC6655]. 186 These cipher suites make use of the default TLS 1.2 Pseudorandom 187 Function (PRF), which uses HMAC with the SHA-256 hash function. 189 The following stipulations apply to the use of elliptic curves: 191 o Curves with a cofactor equal to one SHOULD be used; this 192 simplifies their use. 194 o The uncompressed point format MUST be supported. Other point 195 formats MAY be used. 197 o Fundamental ECC algorithms [RFC6090] MAY be used as an 198 implementation method. 200 o A particular implementation MUST use only a single curve (see 201 Section 3) 203 3. Specific Fixed Implementation Parameters 205 It is expected that TLS-ECJ-PAKE is used in applications where 206 parameters applying to the particular TLS-ECJ-PAKE implementation are 207 fixed and known to the application a priori. For this reason, 208 certain capability negotiations usually associated with TLS are not 209 present in TLS-ECJ-PAKE. This restricts its use to applications 210 where such parameters can be applied a priori, for example as is the 211 case in Thread [THREAD]. 213 Parameters which MUST be fixed prior to implementation are: 215 +---------------------------------+ 216 | Parameter | 217 +---------------------------------+ 218 | Choice of single elliptic curve | 219 | Presence or absence of identity | 220 +---------------------------------+ 222 Table 1: Fixed implementation parameters 224 4. Notations 226 This section describes the notations used in this document. 228 4.1. Elliptic Curve Points 230 The generator (base point) of an elliptic curve is represented by the 231 letter 'G': 233 G 235 A modified generator is represented by the letter 'G' concatenated 236 with a single uppercase character: 238 GB 240 Elliptic curve points are represented using a single uppercase 241 character or a single uppercase character concatenated with a single 242 lowercase character or decimal digit, for example: 244 X 246 Xc 248 X2 250 Conversion to and from elliptic curve points to octet strings is as 251 specified in Sections 2.3.3 and 2.3.4 of [SEC1]. 253 Point multiplication is shown as an elliptic curve point multiplied 254 by a scalar integer using the '*' operator, for example: 256 G*x 258 Point addition or subtraction is shown as the addition or subtraction 259 of elliptic curve points or scalar multiplied elliptic curve points 260 using the '+' and '-' operators respectively, for example: 262 X1 + X3 + X4 264 X*h + G*r 266 Xs - X4*x2*s 268 4.2. Integers 270 Integers are represented using a single lowercase character or a 271 single lowercase character followed by a single lowercase character 272 or decimal digit, for example: 274 x 276 xc 278 x2 280 Where expressed, integers are shown in hexadecimal and/or decimal 281 form. Hexadecimal numbers have an '0x' prefix. For example: 283 0x12ab34cd 285 3132110061 287 Integer multiplication is shown as two integers multiplied together 288 using the '*' operator: 290 x*s 292 Integer addition or subtraction is shown as the addition or 293 subtraction of integers or multiplied integers using the '+' and '-' 294 operators respectively: 296 v - x*h 298 4.3. Octet Strings 300 Octet strings are expressed in a hexadecimal form, with no '0x' 301 prefix and with a space separator, first octet leftmost, for example: 303 12 ab 34 cd 305 4.4. Integer to Octet String Conversion 307 Integer to octet string conversion SHALL be performed as stated in 308 Section 2.3.7 of [SEC1]. It is represented as follows: 310 M = str(mlen, x) 312 where x, mlen, and M are the parameters as stated in Section 2.3.7 of 313 [SEC1]. 315 4.5. Octet String to Integer Conversion 317 Octet string to integer conversion SHALL be as stated in section 318 2.3.8 of [SEC1]. It is represented as follows: 320 x = int(mlen, M) 322 where x, mlen, and M are the parameters as stated in Section 2.3.8 of 323 [SEC1]. 325 5. Handshake 327 The TLS-ECJ-PAKE handshake is as follows, augmented with parameters 328 in braces to show the ECJ-PAKE material conveyed in each case: 330 Client Server 331 ------ ------ 332 ClientHello --------> 333 {(X1,ZKP(X1)), 334 (X2,ZKP(X2))} ServerHello 335 {(X3, ZKP(X3)), 336 (X4, ZKP(X4))} 337 ServerKeyExchange 338 {Xs, ZKP(Xs)} 339 <-------- ServerHelloDone 340 ClientKeyExchange 341 {Xc, ZKP(Xc)} 342 [ChangeCipherSpec] 343 Finished --------> 344 [ChangeCipherSpec] 345 <-------- Finished 346 Application Data <-------> Application Data 348 Figure 1: Message flow in a TLS-ECJ-PAKE handshake 350 6. Failure processing 352 If there are failures for any reason on client or server side, for 353 example, Schnorr ZKP verification or missing extensions, the 354 handshake SHALL abort immediately and send a TLS Error Alert message 355 to the peer, using code 40 (handshake_failure) (see Section 7.2 of 356 [RFC5246]). 358 7. ECJ-PAKE TLS Extensions and Modification 360 This section describes existing and newly-defined extensions required 361 for ECJ-PAKE-TLS. The guiding principle for extension use is to 362 adhere as closely as possible to [RFC4492]. 364 7.1. New Structure Definitions 366 TLS-ECJ-PAKE requires new structure definitions for: 368 o Public key and Schnorr ZKP pair 370 o Schnorr ZKP 372 7.1.1. Public Key and Schnorr ZKP Pair 374 The TLS structure is as follows: 376 struct { 377 ECPoint X; 378 ECSchnorrZKP zkp; 379 } ECJPAKEKeyKP; 381 X 383 Public key represented as an elliptic curve point. ECPoint is 384 defined in [RFC4492]. 386 zkp 388 ECSchnorrZKP is defined in Section 7.1.2. 390 7.1.2. Schnorr ZKP 392 The TLS structure is as follows: 394 struct { 395 ECPoint V; 396 opaque r<1..2^8-1>; 397 } ECSchnorrZKP; 399 V 401 Ephemeral public key represented as an elliptic curve point. 402 ECPoint is defined in [RFC4492]. 404 r 406 Schnorr signature. 408 7.2. ClientHello and ServerHello TLS Extensions 410 7.2.1. Existing Extensions 412 The following TLS extensions defined in Section 4 of [RFC4492] SHALL 413 be present in ClientHello: 415 o Supported Elliptic Curves Extension (NamedCurve, 416 EllipticCurveList) 418 o Supported Point Formats Extension (ECPointFormat, 419 ECPointFormatList) 421 and the following TLS extension defined in Section 4 of [RFC4492] 422 SHALL be present in ServerHello: 424 o Supported Point Formats Extension (ECPointFormat, 425 ECPointFormatList) 427 EllipticCurveList in ClientHello SHALL contain only one entry 428 corresponding to the fixed elliptic curve chosen for the 429 implementation (see Section 3). 431 7.2.2. Additional Extensions 433 The following extension SHALL additionally be present in both 434 ClientHello and ServerHello: 436 enum { ecjpake_key_kp_pair(TBC) } ExtensionType; 438 struct { 439 opaque identity<0..2^16-1>; 440 ECJPAKEKeyKP ecjpake_key_kp_pair_list[2]; 441 } ECJPAKEKeyKPPairList; 443 identity 445 Included if the Client or Server needs to uniquely identify 446 themselves to the other party. An identity is used in the Schnorr 447 ZKP hash calculation (see Section 8.2). The identity field SHALL 448 be elided where an implementation has chosen absence of identity 449 (see Section 3). 451 ecjpake_key_kp_pair_list 453 The list is precisely two elements long. The list in a 454 ClientHello extension conveys public keys X1 and X2 and the list 455 in a ServerHello extension conveys public keys X3 and X4, with 456 associated Schnorr ZKPs. 458 Note: When used in conjunction with DTLS and denial-of-service 459 countermeasures as described in Section 4.2.1 of [RFC6347], the 460 ECJPAKEKeyKPPairList in the subsequent ClientHello message SHALL be 461 the same as the ECJPAKEKeyKPPairList in initial ClientHello message, 462 i.e. the public keys X1 and X2 and associated Schnorr ZKPs SHALL be 463 the same. 465 7.3. ServerKeyExchange 467 ServerKeyExchange is extended as follows: 469 enum { ecjpake } KeyExchangeAlgorithm; 471 ecjpake 472 Indicates the ServerKeyExchange message contains 473 ServerECJPAKEParams. 475 ServerKeyExchange for ecjpake SHALL be formatted as follows: 477 struct { 478 ECParameters curve_params; 479 ECJPAKEKeyKP ecjpake_key_kp; 480 } ServerECJPAKEParams; 482 select (KeyExchangeAlgorithm) { 483 case ecjpake: 484 ServerECJPAKEParams params; 485 } ServerKeyExchange; 487 7.4. ClientKeyExchange 489 ClientKeyExchange is extended as follows: 491 enum { ecjpake } KeyExchangeAlgorithm; 493 ecjpake 495 Indicates the ClientKeyExchange message contains 496 ClientECJPAKEParams. 498 ClientKeyExchange for ecjpake SHALL be formatted as follows: 500 struct { 501 ECJPAKEKeyKP ecjpake_key_kp; 502 } ClientECJPAKEParams; 504 select (KeyExchangeAlgorithm) { 505 case ecjpake: 506 ClientECJPAKEParams params; 507 } ClientKeyExchange; 509 8. Calculations 511 This section describes the calculations required to populate the data 512 conveyed between Client and Server and also calculations required to 513 verify knowledge proofs. 515 The following notation is used throughout this section: 517 Order of the base point: n 519 8.1. User Identity Selection 521 The Schnorr ZKP hash calculation requires non-confidential user 522 identities. These identities need to be unique in the context of a 523 transaction and be different for each party. In a peer-to-peer 524 transaction where there is no ambiguity of identity, the identities 525 can be a simple string representing the Client and Server 526 respectively: 528 +------------+----------+-------------------+--------------------+ 529 | Originator | Name | Identity | Length of identity | 530 +------------+----------+-------------------+--------------------+ 531 | Client | "client" | 63 6c 69 65 6e 74 | 6 | 532 | Server | "server" | 73 65 72 76 65 72 | 6 | 533 +------------+----------+-------------------+--------------------+ 535 Table 2: Simple Client and Server identities 537 In a multi-party transaction, each party SHOULD additionally provide 538 an identity in the ClientHello and/or ServerHello to uniquely 539 distinguish their user identity. 541 8.2. Schnorr ZKP Hash Calculation 543 The hash calculation is defined as follows: 545 +-------------------+-----------------------------------+ 546 | Public Key | Calculation | 547 +-------------------+-----------------------------------+ 548 | X1, X2, X3 and X4 | h = SHA-256(G, V, X, ID) mod n | 549 | Xs | h = SHA-256(GB, V, Xs, IDs) mod n | 550 | Xc | h = SHA-256(GA, V, Xc, IDc) mod n | 551 +-------------------+-----------------------------------+ 553 Table 3: Schnorr ZKP Hash Calculation 555 Each item in the hash calculation is prepended with its length in 556 octets represented an octet (length 4), formed by applying integer to 557 octet string conversion as defined in Section 4.4. For example, the 558 length of an uncompressed octet string representation of a public key 559 is 65 (decimal) therefore the octet string (length 4) representation 560 of 65 in hexadecimal is: 562 o 00 00 00 41 564 Each public key (elliptic curve point) is first converted to an octet 565 string according to Section 2.3.3 of [SEC1]. 567 The concatentation order of the hash is as follows: 569 1. G (or GA, GB): Generator 571 2. V: ZKP ephemeral public key 573 3. X (or Xs, Xc): Public key to be verified 575 4. ID (or IDc, IDs): User ID (see Section 8.1) 577 The hash is therefore performed on the concatenation as follows: 579 o H = SHA-256(lenG || G || lenV || V || lenX || X || lenID || ID) 581 An integer representation of the hash (see Section 4.5) is produced: 583 o h = int(H) 585 8.3. Shared Secret 587 The shared secret for the ServerKeyExchange and ClientKeyExchange 588 calculations is required to be an integer in the range 1 to n-1. 589 This section shows an example of how this could be practically 590 accomplished using an initial password. The initial password is 591 usually represented visually as a variable length character string 592 using a subset of internationally recognized characters from the 593 UTF-8 character set, which prevents the possibility of the resulting 594 shared secret having the value 0. The initial password is then be 595 converted into an octet string using UTF-8 conversion. 596 The integer shared secret calculation is thus defined as follows, 597 using the function defined in Section 4.5: 599 s = int() mod n 601 8.3.1. Example 603 Password: 605 "d45yj8e" 607 Equivalent octet string M using UTF-8 conversion (no null 608 termination): 610 64 34 35 79 6a 38 65 612 Length mlen: 614 7 616 Shared secret: 618 0x643435796a3865 620 28204901945981028 (decimal) 622 8.4. ClientHello and ServerHello Calculations 624 The structure ECJPAKEKeyKPPairList conveys the public key and 625 associated Schnorr ZKP for ClientHello (X1 and X2) and ServerHello 626 (X3 and X4). 628 8.4.1. Public Key Generation 630 For X1, X2, X3 and X4, the value for the public key part X of the 631 ECJPAKEKeyKP structure is generated as follows: 633 The inputs are: 635 o Base point: G 637 o Order of the base point: n 639 The public key of the key pair is calculated as follows: 641 1. A random integer in the range 1 to n-1 is assigned to private key 642 x. 644 2. A public key associated with x is generated and assigned to X: 646 X = G*x 648 3. X is assigned to the public key part X of the ECJPAKEKeyKP 649 structure. 651 8.4.2. Schnorr ZKP Generation 653 For X1, X2, X3 and X4, the values for the ZKP part zkp.V and zkp.r of 654 the ECJPAKEKeyKP structure are generated as follows: 656 The inputs are: 658 o Base point: G 660 o Order of the base point: n 662 o Identity of originator: ID (IDc or IDs depending on context) 663 o Key pair to provide a ZKP of: (X,x) (public key: X, private key: 664 x), where X is X1, X2, X3, or X4 and x is x1, x2, x3, or x4, 665 depending on context 667 The ZKP is generated as follows: 669 1. A random integer in the range 1 to n-1 is assigned to ephemeral 670 private key v. 672 2. An ephemeral public key associated with v is generated and 673 assigned to V: 675 V = G*v 677 3. An integer representation of a hash (see Section 8.2) is 678 generated and assigned to h: 680 h = int(SHA-256(G, V, X, ID)) mod n 682 4. A signature is generated and assigned to r: 684 r = v - x*h mod n 686 5. V and r are assigned to the ZKP part zkp.V and zkp.r of the 687 ECJPAKEKeyKP structure respectively. 689 8.4.3. Schnorr ZKP Verification 691 For X1, X2, X3 and X4, the ECJPAKEKeyKP structure is verified as 692 follows: 694 The inputs are: 696 o Base point: G 698 o Order of the base point: n 700 o Identity of originator: ID (IDc or IDs depending on context) 702 o Public key to be verified: X (X1, X2, X3, or X4 depending on 703 context) 705 o ZKP ephemeral public key: V 707 o ZKP signature: r 709 The ZKP is verified as follows: 711 1. An integer representation of a hash (see Section 8.2) is 712 generated and assigned to h: 714 h = int(SHA-256(G, V, X, ID)) mod n 716 2. A check point is generated and assigned to V': 718 V'= X*h + G*r 720 3. The points V' and V are compared. If equal then the ZKP 721 verifies, otherwise it does not verify. 723 8.5. ServerKeyExchange Calculations 725 The structure ECJPAKEKeyKP conveys the public key and associated 726 Schnorr ZKP for Xs. 728 8.5.1. Public Key Generation 730 For Xs, the value for the public key part X of the ECJPAKEKeyKP 731 structure is generated as follows: 733 The inputs are: 735 o Public keys: X1, X2 and X3 737 o Private key: x4 739 o Shared secret: s (integer format, see Section 8.3) 741 o Order of the base point: n 743 The public key of the key pair is calculated as follows: 745 1. A new generator is generated and assigned to GB: 747 GB = X1 + X2 + X3 749 2. A private key is generated and assigned to xs: 751 xs = x4*s mod n 753 3. A public key associated with xs is generated and assigned to Xs: 755 Xs = GB*xs 757 4. Xs is assigned to the public key part X of the ECJPAKEKeyKP 758 structure. 760 8.5.2. Schnorr ZKP Generation 762 For Xs, the values for the ZKP part zkp.V and zkp.r of the 763 ECJPAKEKeyKP structure are generated as follows: 765 The inputs are: 767 o New generator: GB 769 o Order of the base point: n 771 o Identity of originator: IDs 773 o Key pair to provide a ZKP of: (Xs,xs) (public key: Xs, private 774 key: xs) 776 The ZKP is generated as follows: 778 1. A random integer in the range 1 to n-1 is assigned to ephemeral 779 private key v. 781 2. An ephemeral public key associated with v is generated and 782 assigned to V: 784 V = GB*v 786 3. An integer representation of a hash (see Section 8.2) is 787 generated and assigned to h: 789 h = int(SHA-256(GB, V, Xs, IDs)) mod n 791 4. A signature is generated and assigned to r: 793 r = v - xs*h mod n 795 5. V and r are assigned to the ZKP part zkp.V and zkp.r of the 796 ECJPAKEKeyKP structure respectively. 798 8.5.3. Schnorr ZKP Verification 800 For Xs, the ECJPAKEKeyKP structure is verified as follows: 802 The inputs are: 804 o New generator: GB 806 o Order of the base point: n 807 o Identity of originator: IDs 809 o Public key to be verified: Xs 811 o ZKP ephemeral public key: V 813 o ZKP signature: r 815 The ZKP is verified as follows: 817 1. An integer representation of a hash (see Section 8.2) is 818 generated and assigned to h: 820 h = int(SHA-256(GB, V, Xs, IDs)) mod n 822 2. A check point is generated and assigned to V': 824 V'= X*h + GB*r 826 3. The points V' and V are compared. If equal then the ZKP 827 verifies, otherwise it does not verify. 829 8.6. ClientKeyExchange Calculations 831 The structure ECJPAKEKeyKP conveys the public key and associated 832 Schnorr ZKP for Xc. 834 8.6.1. Public Key Generation 836 For Xc, the value for the public key part X of the ECJPAKEKeyKP 837 structure is generated as follows: 839 The inputs are: 841 o Public keys: X1, X3 and X4 843 o Private key: x2 845 o Shared secret: s (integer format, see Section 8.3) 847 o Order of the base point: n 849 The public key of the key pair is calculated as follows: 851 1. A new generator is generated and assigned to GA: 853 GA = X1 + X3 + X4 855 2. A private key is generated and assigned to xc: 857 xc = x2*s mod n 859 3. A public key associated with xs is generated and assigned to Xc: 861 Xc = GA*xc 863 4. Xc is assigned to the public key part X of the ECJPAKEKeyKP 864 structure. 866 8.6.2. Schnorr ZKP Generation 868 For Xc, the values for the ZKP part zkp.V and zkp.r of the 869 ECJPAKEKeyKP structure are generated as follows: 871 The inputs are: 873 o New generator: GA 875 o Order of the base point: n 877 o Identity of originator: IDc 879 o Key pair to provide a ZKP of: (Xc,xc) (public key: Xc, private 880 key: xc) 882 The ZKP is generated as follows: 884 1. A random integer in the range 1 to n-1 is assigned to ephemeral 885 private key v. 887 2. An ephemeral public key associated with v is generated and 888 assigned to V: 890 V = GA*v 892 3. An integer representation of a hash (see Section 8.2) is 893 generated and assigned to h: 895 h = int(SHA-256(GA, V, Xc, IDc)) mod n 897 4. A signature is generated and assigned to r: 899 r = v - xc*h mod n 901 5. V and r are assigned to the ZKP part zkp.V and zkp.r of the 902 ECJPAKEKeyKP structure respectively. 904 8.6.3. Schnorr ZKP Verification 906 For Xc, the ECJPAKEKeyKP structure is verified as follows: 908 The inputs are: 910 o New generator: GA 912 o Order of the base point: n 914 o Identity of originator: IDc 916 o Public key to be verified: Xc 918 o ZKP ephemeral public key: V 920 o ZKP signature: r 922 The ZKP is verified as follows: 924 1. An integer representation of a hash (see Section 8.2) is 925 generated and assigned to h: 927 h = int(SHA-256(GA, V, Xc, IDc)) mod n 929 2. A check point is generated and assigned to V': 931 V'= X*h + GA*r 933 3. The points V' and V are compared. If equal then the ZKP 934 verifies, otherwise it does not verify. 936 8.7. Premaster Secret Generation 938 The TLS-ECJ-PAKE handshake relies on the generation of identical 939 premaster secrets at the client and server to verify the key 940 establishment. The use of the protected Finished messages is 941 therefore used for key confirmation purposes and to verify the 942 handshake. 944 8.7.1. Server Premaster Secret Generation 946 The inputs are: 948 o Public key of the client: Xc 950 o Public key: X2 951 o Private key: x4 953 o Shared secret: s (integer format, see Section 8.3) 955 The premaster secret is generated as follows: 957 1. Compute PMSK: 959 PMSK = (Xc - X2*x4*s)*x4 961 2. Compute PMS: 963 PMS = SHA-256(str(32, X coordinate of PMSK)) 965 3. The master secret and key expansion is generated according to 966 Section 8.1 and Section 6.3 of [RFC5246]. 968 8.7.2. Client Premaster Secret Generation 970 The inputs are: 972 o Public key of the server: Xs 974 o Public key: X4 976 o Private key: x2 978 o Shared secret: s (integer format, see Section 8.3) 980 The premaster secret is generated as follows: 982 1. Compute PMSK: 984 PMSK = (Xs - X4*x2*s)*x2 986 2. Compute PMS: 988 PMS = SHA-256(str(32, X coordinate of PMSK)) 990 3. The master secret and key expansion is generated according to 991 Section 8.1 and Section 6.3 of [RFC5246]. 993 9. Acknowledgements 995 The authors would like to thank Sorin Aliciuc, Richard Kelsey, 996 Maurizio Nanni, Manuel Pegourie-Gonnard and Martin Turon for their 997 helpful comments and assistance. 999 10. IANA Considerations 1001 10.1. Transport Layer Security (TLS) Parameters 1003 10.1.1. TLS Cipher Suite Registry 1005 IANA is requested to add the following entries in the TLS Cipher 1006 Suite Registry: 1008 TLS_ECJPAKE_WITH_AES_128_CCM = {0xTBD, 0xTBD} 1009 TLS_ECJPAKE_WITH_AES_256_CCM = {0xTBD, 0xTBD} 1010 TLS_ECJPAKE_WITH_AES_128_CCM_8 = {0xTBD, 0xTBD} 1011 TLS_ECJPAKE_WITH_AES_256_CCM_8 = {0xTBD, 0xTBD} 1013 10.2. Transport Layer Security (TLS) Extensions 1015 10.2.1. ExtensionType Values 1017 IANA is requested to add the following entries in the ExtensionType 1018 Values: 1020 ecjpake_key_kp_pair = TBD 1022 11. Security Considerations 1024 11.1. Security Proof 1026 An independent study that proves security of J-PAKE in a model with 1027 algebraic adversaries and random oracles can be found in [ABM15]. 1029 11.2. Counter Reuse 1031 The cipher suites described in this document are AES-CCM-based AEAD 1032 cipher suites, therefore the security considerations for counter 1033 reuse described in [RFC6655] also apply to these cipher suites. 1035 11.3. Password 1037 The password forming the basis of the shared secret SHOULD be 1038 distributed in a secure out-of-band channel. In the specific case of 1039 [THREAD], this is achieved by the user enabling the use of the 1040 password only through a commissioning session where the user is in 1041 control of adding details of devices they wish to add to the Thread 1042 network. 1044 11.4. Rate Limiting 1046 An attacker could attempt to engage repeatedly with a ECJ-PAKE server 1047 in an attempt to guess the password. Servers SHOULD take steps to 1048 ensure the opportunity for repeated contact is limited. 1050 11.5. Usage Restrictions 1052 The cipher suites described in this document have primarily been 1053 developed to enable authentication and authorization for network 1054 access for IoT devices, as described in [THREAD]. It is therefore 1055 RECOMMENDED that the use of these cipher suite is restricted to 1056 similar uses and SHOULD NOT be used in conjunction with web servers 1057 and web browsers unless consideration is given to secure entry of 1058 passwords in a browser. 1060 11.6. Fixed Implementation Parameters 1062 The requirement to specify fixed parameters in a specific 1063 implementation limits the amount of negotiation that takes place 1064 between Client and Server. This effectively makes capability 1065 negotiation binary, i.e. if the implementation is incompatible, the 1066 handshake will simply fail. This is usually an important 1067 consideration in the applications TLS-ECJ-PAKE is recommended for, 1068 where complex negotiation is neither desirable nor recommended. 1070 12. References 1072 12.1. Normative References 1074 [CCM] National Institute of Standards and Technology, 1075 "Recommendation for Block Cipher Modes of Operation: The 1076 CCM Mode for Authentication and Confidentiality", SP 1077 800-38C, May 2004, . 1080 [SEC1] Standards for Efficient Cryptography Group, "Standards for 1081 Efficient Cryptography: SEC 1: Elliptic Curve 1082 Cryptography", SECG SEC1-v2, May 2004, 1083 . 1085 [THREAD] Thread Group, "Thread Commissioning", July 2015, 1086 . 1089 [HR08] Hao, F. and P. Ryan, "Password Authenticated Key Exchange 1090 by Juggling", 16th Workshop on Security Protocols 1091 (SPW'08), May 2008, 1092 . 1095 [ABM15] Abdalla, M., Benhamouda, F., and P. MacKenzie, "Security 1096 of the J-PAKE Password-Authenticated Key Exchange 1097 Protocol", IEEE Symposium on Security and Privacy, May 1098 2015, 1099 . 1102 [J-PAKE] Hao, F., "J-PAKE: Password Authenticated Key Exchange by 1103 Juggling", draft-hao-jpake-03 (work in progress), February 1104 2016, . 1106 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1107 Requirement Levels", BCP 14, RFC 2119, 1108 DOI 10.17487/RFC2119, March 1997, 1109 . 1111 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 1112 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 1113 for Transport Layer Security (TLS)", RFC 4492, 1114 DOI 10.17487/RFC4492, May 2006, 1115 . 1117 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 1118 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 1119 . 1121 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1122 (TLS) Protocol Version 1.2", RFC 5246, 1123 DOI 10.17487/RFC5246, August 2008, 1124 . 1126 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1127 Extensions: Extension Definitions", RFC 6066, 1128 DOI 10.17487/RFC6066, January 2011, 1129 . 1131 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 1132 Transport Layer Security (TLS)", RFC 6655, 1133 DOI 10.17487/RFC6655, July 2012, 1134 . 1136 [RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- 1137 CCM Elliptic Curve Cryptography (ECC) Cipher Suites for 1138 TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014, 1139 . 1141 12.2. Informative References 1143 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 1144 Curve Cryptography Algorithms", RFC 6090, 1145 DOI 10.17487/RFC6090, February 2011, 1146 . 1148 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1149 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1150 January 2012, . 1152 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1153 Application Protocol (CoAP)", RFC 7252, 1154 DOI 10.17487/RFC7252, June 2014, 1155 . 1157 Authors' Addresses 1159 Robert Cragie 1160 ARM Ltd. 1161 110 Fulbourn Road 1162 Cambridge CB1 9NJ 1163 UK 1165 Email: robert.cragie@arm.com 1167 Feng Hao 1168 Newcastle University (UK) 1169 Claremont Tower, School of Computing Science, Newcastle University 1170 Newcastle upon Tyne NE1 7RU 1171 UK 1173 Email: feng.hao@ncl.ac.uk