idnits 2.17.1 draft-budronimccusker-milagrotls-03.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 9, 2016) is 2878 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5246 (ref. '1') (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5226 (ref. '4') (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Budroni, K. McCusker 3 Internet-Draft MIRACL Ltd. 4 Intended Status: Informational June 9, 2016 5 Expires: December 11, 2016 7 Milagro TLS: Pairing-Based Cryptography for Transport Layer Security 8 draft-budronimccusker-milagrotls-03 10 Abstract 12 This document introduces two key exchange algorithms based on 13 Pairing-Based Cryptography (PBC) for the Transport Layer Security 14 (TLS) protocol. In particular, it specifies the use of two identity- 15 based key exchange algorithms for the TLS handshake. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute working 24 documents as Internet-Drafts. The list of current Internet-Drafts is 25 at http://datatracker.ietf.org/drafts/current. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on December 11, 2016. 34 Copyright Notice 36 Copyright (c) 2016 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . . 3 53 2.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.2 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.3 Conventions . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Key Exchange Algorithms . . . . . . . . . . . . . . . . . . . . 4 57 3.1 MILAGRO_CS . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.2 MILAGRO_P2P . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Data Structures and Computations . . . . . . . . . . . . . . . 6 60 4.1 ClientHello Extension . . . . . . . . . . . . . . . . . . . 7 61 4.2 Server Key Exchange . . . . . . . . . . . . . . . . . . . . 8 62 4.3 Client Key Exchange . . . . . . . . . . . . . . . . . . . . 8 63 5. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 10 65 6.1 MILAGRO_CS . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 6.1 MILAGRO_P2P . . . . . . . . . . . . . . . . . . . . . . . . 10 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 70 8.2 Informative References . . . . . . . . . . . . . . . . . . . 11 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 73 1. Introduction 75 Pairing-Based Crypto (PBC) is emerging as a solution to complex 76 problems that proved intractable to the standard mathematics of 77 Public-Key Cryptography. An example of such a problem would be 78 Identity-Based Encryption, whereby the identity of a client can be 79 used as their public key [11]. 81 PBC is based on the use of a bi-linear map defined on an elliptic 82 curve E 84 e: G1 X G2 -> GT 86 where G1 is defined as a group of points on E, G2 is defined as a 87 group of points on a twist of E over an extension field. Both groups 88 are of prime order q. GT is a finite extension. 90 Milagro TLS proposes the use of PBC for mutually authenticated key 91 agreement. There are two new key exchange algorithms in this draft: 92 Peer-to-Peer (P2P) and Client-Server. The P2P solution uses the Chow- 93 Choo protocol and the Client-Server solution uses the MPIN Protocol 94 [9,10]. 96 Milagro TLS uses a curve that has security at the AES-128 level. 98 This document describes an addition to TLS 1.2 [1] to support PBC. In 99 particular, it defines 101 o Milagro_CS: a key exchange algorithm based on MPIN-FULL protocol 102 [9]. This is a Client-to-Server protocol that allows mutually 103 authenticated key agreement. In this protocol the client secrets 104 are in G1 and the server secret is in G2. For a Type-3 pairing 105 there is assumed to be no computable isomorphism between these 106 groups, even though both are of the same order. 108 o Milagro_P2P: a key exchange algorithm based on the Chow-Choo 109 protocol 110 [10]. It can operate in P2P or client/server mode. Users of this 111 protocol are issued sender keys in G1 and receiver keys in G2. The 112 server, which sends the ServerKeyExchange message, is considered 113 the sender in this protocol. 115 2. Requirements Notation 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [2]. 121 2.1 Definitions 123 Digital Identity: Digital Identity is the data that uniquely 124 describes a person or a thing, and typically contains some 125 information about that entity's relationships. 127 2.2 Abbreviations 129 ECC Elliptic Curve Cryptography 131 PBC Pairing-Based Cryptography 133 AES Advanced Encryption Standard 135 TA Trusted Authority 137 P2P Peer-to-Peer 139 Milagro_CS Milagro Client-to-Server 141 Milagro_P2P Milagro Peer-to-Peer 143 ECDH Elliptic Curve Diffie Hellman 144 E is an ordinary pairing-friendly elliptic curve over a finite field 145 F, defined by a fixed prime modulus p 147 2.3 Conventions 149 IdC: Digital identity of the client 151 IdS: Digital identity of the server 153 H1: Maps string value to a point on the curve in G1. 155 H2: Maps string value to a point on the curve in G2 157 Hq: Hashes inputs to an integer modulo the curve order q. 159 Hg: Generate AES key 161 SHA-256: Performs the SHA256 function. 163 3. Key Exchange Algorithms 165 3.1 MILAGRO_CS 167 Here we briefly resume the main steps of the MPIN-FULL key exchange 168 algorithm, see [8] and [9] for details. 170 Let A = H1(IdC) be a point on G1, where IdC is the client's identity, 171 and let Q be a generator of the group G2. The TA provides the client 172 key s.A, in G1 and the server key s.Q, in G2. 174 MPIN Full was envisaged as a two factor authentication solution but 175 in this context, as this is a machine to machine protocol, there is 176 no requirement for a second factor and therefore the PIN is set to 177 zero in the code. 179 The ClientHello message MUST have an extension which contains three 180 public parameters: 182 - IdC, the identity of the client. This can be the identity in clear 183 or the hash of identity. In the latter case the IdC is encrypted 184 after the session key is established and sent to the server to 185 complete client authentication. 187 - U = x.(H1(IdC)) where x is a random number modulo the curve order. 189 - t, the epoch time at which authentication occurred. 191 - V = -(x+y)(s.A), where y = Hq(t|U) and A = H1(IdC). 193 The server itself calculates A by applying the same hash function H1 194 to the claimed digital identity i.e. A is H1(IdC). Then the Server 195 MUST check that e(V,Q).e(U+yA,s.Q) = 1. If this tests fails then the 196 connection is terminated by the server with a proper alert message 197 and the attempted Client connection is rejected. 199 Through the ServerKeyExchange message, the server sends an ECDH 200 public key W=w.A, where w is a random number modulo the curve order 201 and A is H1(IdC). 203 Through the ClientKeyExchange message, the client send its ECDH 204 public key R=r.A, where r is a random number modulo the curve order. 206 At this point, both the client and the server are able to compute a 207 16-bytes shared premaster secret: 209 - The client first computes the parameter h = Hq(A,U,y,V,R,W), then 210 computes the premaster secret as K = Hg(e(s.A,Q)^(r+h)|x.W). 212 - The server first computes the parameter h = Hq(A,U,y,V,R,W), then 213 computes the premaster secret as K = Hg(e(R+h.A,s.Q)|w.U). 215 See [9] for more details. 217 3.2 MILAGRO_P2P 219 Here we briefly resume the main steps of the Chow-Choo key exchange 220 Algorithm [10]. 222 Choo-Chow key exchange algorithm is designed for communications peer- 223 to-peer. The TA provides the server with a sender key in G1 i.e. 224 SKeyG1 and client with receiver key in G2 I.e. CKeyG2 based on their 225 respective identities. 227 The main steps of the algorithm are: 229 - The server computes a random integer x modulo the curve order, 230 computes a point on the group G1 as PsG1 = x.H1(IdS) which is its 231 public parameter and sends the pair (IdS,PsG1) to the client. 233 - The client receives the pair of parameter from the server, computes 234 two random integers Y and W modulo the curve order, compute the 235 following; PcG2 = Y.H2(IdC), PgG1 = W.H1(IdS), pic = 236 Hq(PcG2||PsG1||PgG1||IdS), pis = Hq(PsG1||PcG2||PgG1||IdC) and the 237 value k = e(pis.H(IdS)+PsG1,(y+pic).CKeyG2). 239 - client computes the premaster secret as K = Hg(k,w.PsG1). 241 - client sends the triple (IdC,PsG1,PgG1) to server. 243 - server receives the parameters from the client and computes the 244 following pis = Hq(PsG1||PcG2||PgG1), pic = Hq(PcG2||PsG1||PgG1) 245 and the value k = e((x+pis).SKeyG1,pic.B+PcG2). 247 - server compute the premaster secret as K = Hg(k,x.PsG1). 249 4. Data Structures and Computations 251 This document introduces two new key exchange algorithms for TLS that 252 use PBC to compute the TLS premaster secret. The derivation of the 253 TLS master secret from the premaster secret and the subsequent 254 generation of bulk encryption/MAC keys and initialization vectors is 255 independent of the key exchange algorithm and not impacted by the 256 introduction of PBC and ECC. 258 enum { 259 Milagro_CS, 260 Milagro_P2P, 261 } KeyExchangeAlgorithm; 263 The first key exchange algorithm is Milagro_CS and it is designed for 264 client-to-server communications. It is based on the MPIN-FULL key 265 exchange protocol [9], which is an extension of the M-Pin 266 Authentication Protocol [8]. 268 The second key exchange algorithm is Milagro_P2P and it is designed 269 for peer-to-peer communications. It is based on the CHOW-CHOO 270 protocol [10]. 272 Here we summarize the steps of TLS-Handshake used by those two key 273 exchange algorithms. 275 Client Server 276 ------ ------ 278 ClientHello ---------> 279 ServerHello 280 ServerKeyExchange 281 <--------- ServerHelloDone 282 ClientKeyExchange 283 (ChangeCipherSpec) 284 Finished ---------> 285 (ChangeCipherSpec) 286 <--------- Finished 288 Application Data <--------> Application Data 290 The following messages of TLS-Handshake MUST NOT be sent for those 291 two key exchange algorithms: (Server)Certificate, CertificateRequest, 292 (Client)Certificate and CertificateVerify. 294 4.1 ClientHello Extension 296 This section specifies a TLS extension that can be included with the 297 ClientHello message as described in [3], the Milagro_CS Extension. 299 When this extension are sent: 301 The extension MUST be sent along with any ClientHello message that 302 proposes Milagro_CS key exchange algorithms and it MUST NOT be sent 303 with any other ClientHello message that doesn't proposes this 304 cipher. 306 Meaning of this extension: 308 This extension allow the Client to authenticate itself with the 309 Server and to exchange part of the parameters that will be used to 310 compute the premaster secret. 312 Structure of these extensions: 314 As described in [3], two octets of are used to indicate the 315 extension type. In case of Milagro_CS extension the octets are 316 0x0025. The general structure of TLS extensions is described in 317 [3], and this specification adds a new type to ExtensionType. 319 enum { Milagro_CS_ext } ExtensionType; 321 struct { 322 uint16 length_hash_IdC, 323 uint16 length_U, 324 uint16 length_V, 325 opaque hash_IdC[length_hash_IdC], 326 opaque U[length_U], 327 opaque V[length_V], 328 uint32 time_value, 329 (255) 330 } Milagro_CS_ext; 332 length_hash_IdC, length_U, length_V: length of the parameters. 334 hash_IdC: hash of the client's identity. 336 U: first parameter sent by the client. 338 V: second parameter sent by the client. 340 time_value: current epoch time in seconds. 342 Actions of the Server: 344 If Milagro_CS is between the key exchange algorithms available of 345 the server, then he MUST check if the time_value received from the 346 client differs too much from the current time. If the difference is 347 more than a fixed value then he has to refuse the client. If this 348 check has a successful ending it is RECOMMENDED, regardless of the 349 chosen cipher suite, that he tries to authenticate the Client as 350 explained in 3.1, and, in case of failing, he has to refuse the 351 client. 353 See [8] for details about the authentication. 355 4.2 Server Key Exchange 357 This document introduces two new ServerKeyExchange messages, one for 358 each key exchange algorithm. 360 If the cipher suite chosen by the server has Milagro_CS as key 361 exchange algorithm, then the server MUST compute the parameter W, as 362 explained in 3.1 and send it. 364 If the cipher suite chosen by the server has Milagro_P2P as key 365 exchange algorithm, then the server MUST compute the the public 366 parameter PsG1 as explained in 3.2 and send it with its digital 367 identity IdS. 369 The ServerKeyExchange message is extended as follows. 371 select (KeyExchangeAlgorithm) { 372 case Milagro_CS: 373 uint16 length_W; 374 opaque W[length_W]; 375 case Milagro_P2P: 376 uint16 length_IdS; 377 uint16 length_PsG1; 378 opaque IdS[length_IdS]; 379 opaque PsG1[length_PsG1]; 380 } ServerKeyExchange; 382 4.3 Client Key Exchange 384 If the cipher suite chosen by the server has Milagro_CS as key 385 exchange algorithm, then the client MUST compute the parameter R, as 386 explained in 3.1 and send it. 388 If the cipher suite chosen by the server has Milagro_P2P as key 389 exchange algorithm, then the client MUST compute the parameters PgG1 390 and PcG2 as explained in 3.2 and send them with its digital identity 391 IdC. 393 The ClientKeyExchange message is extended as follows. 395 select (KeyExchangeAlgorithm) { 396 case Milagro_CS: 397 uint16 length_R; 398 opaque R[length_R]; 399 case Milagro_P2P: 400 uint16 length_IdC; 401 uint16 length_PgG1; 402 uint16 length_PcG2; 403 opaque IdC[length_IdC]; 404 opaque PgG1[length_PgG1]; 405 opaque PcG2[length_PcG2]; 406 } ClientKeyExchange; 408 5. Cipher Suites 410 The table below defines new cipher suites that use the key exchange 411 algorithms specified in Section 3. 413 CipherSuite TLS_MILAGRO_CS_WITH_AES_128_GCM_SHA256 = {0xC0,0xB1} 414 CipherSuite TLS_MILAGRO_CS_WITH_AES_128_GCM_SHA512 = {0xC0,0xB2} 415 CipherSuite TLS_MILAGRO_CS_WITH_CAMELLIA_128_GCM_SHA256 = {0xC0,0xB3} 416 CipherSuite TLS_MILAGRO_CS_WITH_CAMELLIA_128_GCM_SHA512 = {0xC0,0xB4} 417 CipherSuite TLS_MILAGRO_CS_WITH_3DES_EDE_CBC_SHA256 = {0xC0,0xB5} 418 CipherSuite TLS_MILAGRO_CS_WITH_3DES_EDE_CBC_SHA512 = {0xC0,0xB6} 420 CipherSuite TLS_MILAGRO_P2P_WITH_AES_128_GCM_SHA256 = {0xC0,0xB7} 421 CipherSuite TLS_MILAGRO_P2P_WITH_AES_128_GCM_SHA512 = {0xC0,0xB8} 422 CipherSuite TLS_MILAGRO_P2P_WITH_CAMELLIA_128_GCM_SHA256 = {0xC0,0xB9} 423 CipherSuite TLS_MILAGRO_P2P_WITH_CAMELLIA_128_GCM_SHA512 = {0xC0,0xC0} 424 CipherSuite TLS_MILAGRO_P2P_WITH_3DES_EDE_CBC_SHA256 = {0xC0,0xC1} 425 CipherSuite TLS_MILAGRO_P2P_WITH_3DES_EDE_CBC_SHA512 = {0xC0,0xC2} 427 The key exchange method, cipher, and hash algorithm for each of these 428 cipher suites are easily determined by examining the name. Ciphers 429 (other than AES ciphers) and hash algorithms are defined in [1]. AES 430 cipher is defined in [5], GCM in [6] and the hash algorithm is 431 defined in [7]. 433 The cipher suite name space is maintained by IANA. See Section 7 for 434 information on how new value assignments are added. 436 6. Security Considerations 438 For TLS handshakes using PBC cipher suites, the security 439 considerations in appendices D, E and F of [1] apply accordingly. 441 Security discussion specific to PBC can be also found in [11]. 443 Implementers and users must also consider whether they need forward 444 secrecy. Forward secrecy refers to the property that session keys 445 are not compromised if the static, certified keys belonging to the 446 server and client are compromised. The MILAGRO_CS and MILAGRO_P2P 447 key exchange algorithms provide forward secrecy protection in the 448 event of server and/or client's secret compromise. 450 6.1 MILAGRO_CS 452 A replay-attack might be mounted by re-sending the parameters sent 453 with the extension of ClientHello from a previous conversation. This 454 will not be successful if the difference between the current time on 455 the server and time parameter in the ClientHello message is too 456 large. 458 An active attacker might allow the server to complete the first part 459 of the protocol and then attempt to hijack the link before the 460 calculation of the key. But observe how the value of x is re-used for 461 the calculation of the Diffie-Hellman component of the key. This 462 binds both parts of the protocol together and effectively blocks any 463 hijacking attempt. 465 A Key Compromise Impersonation (KCI) attack, whereby an attacker 466 steals the client credentials and poses as a valid server, is 467 impossible to mount due to fact that random integer r is used in the 468 key agreement protocol. 470 6.1 MILAGRO_P2P 472 This key exchange algorithm has been proved secure under the 473 Bilinear-Diffie-Hellman (BDH) assumption in the Canetti-Krawczyk 474 [10]. 476 Other security discussions about MILAGRO_P2P key exchange algorithm 477 can be found in [10]. 479 7. IANA Considerations 480 This document introduces in section 4.1 and 5 some additions to 481 Transport Layer Security (TLS) Parameters. 483 Any assignments in this document require IETF Consensus action [4]. 485 8. References 487 8.1 Normative References 489 [1] T. Dierks, E. Rescorla, "The Transport Layer Security (TLS) 490 Protocol Version 1.2", RFC 5246, August 2008 492 [2] Bradner S., "Key words for use in RFCs to Indicate Requirement 493 Levels", RFC 2119, March 1997 495 [3] D. Eastlake, "Transport Layer Security (TLS) Extensions: 496 Extension Definitions", RFC 6066, January 2011. 498 [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 499 Considerations Section in RFCs", RFC 5226, May 2008. 501 8.2 Informative References 503 [5] National Institute of Standards and Technology, 504 "Specification for the Advanced Encryption Standard (AES)", 505 FIPS 197, November 2001. 507 [6] National Institute of Standards and Technology, 508 "Recommendation 509 for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) 510 for Confidentiality and Authentication", SP 800-38D, November 511 2007. 513 [7] National Institute of Standards and Technology, "Secure Hash 514 Standard", FIPS PUB 180-4, August 2015. 516 [8] Scott, M. "M-Pin: A Multi-Factor Zero Knowledge Authentication 517 Protocol", Miracl Labs. 519 [9] Scott, M. "M-Pin Full Technology (Version 3.0)", Miracl Labs. 521 [10] Sherman S.M. Chow and Kim-Kwang Raymond Choo, "Strongly-Secure 522 Identity-based Key Agreement and Anonymous Extension", 523 Cryptology ePrint Archive, Report 2007/018,2007. 525 [11] D. Boneh and M. Franklin. Identity-based encryption from the 526 Weil pairing. SIAM Journal of Computing, 32(3):586-615, 2003. 528 Authors' Addresses 530 Alessandro Budroni 531 MIRACL 532 Email: alessandro.budroni@miracl.com 534 Kealan McCusker 535 MIRACL 536 Email: kealan.mccusker@miracl.com