idnits 2.17.1 draft-harkins-pkex-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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The discrete logaritm of the fixed public elements MUST not be known. Knowledge of either of these values voids the security of the exchange. -- The document date (October 31, 2016) is 2733 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Research Task Force Harkins 3 Internet-Draft HP Enterprise 4 Intended status: Informational October 31, 2016 5 Expires: May 4, 2017 7 PKEX 8 draft-harkins-pkex-01 10 Abstract 12 This memo describes a password-authenticated protocol to allow two 13 devices to exchange "raw" (uncertified) public keys and establish 14 trust that the keys belong to their respective identities. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on May 4, 2017. 33 Copyright Notice 35 Copyright (c) 2016 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 52 1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Properties . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. Cryptographic Primitives . . . . . . . . . . . . . . . . . . 5 56 5. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 5 57 5.1. Exchange Phase . . . . . . . . . . . . . . . . . . . . . 6 58 5.2. Commit/Reveal Phase . . . . . . . . . . . . . . . . . . . 6 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 63 8.2. Informative References . . . . . . . . . . . . . . . . . 9 64 Appendix A. Appendix . . . . . . . . . . . . . . . . . . . . . . 9 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 67 1. Introduction 69 Many authenticated key exchange protocols allow for authentication 70 using uncertified, or "raw", public keys. Usually these 71 specifications-- e.g. [RFC7250] for TLS and [RFC7670] for IKEv2-- 72 assume keys are exchanged in some out-of-band mechanism. 74 [RFC7250] further states that "the main security challenge [to using 75 'raw' public keys] is how to associate the public key with a specific 76 entity. Without a secure binding between identifier and key, the 77 protocol will be vulnerable to man-in-the- middle attacks." 79 The Public Key Exchange (PKEX) is designed to fill that gap: it 80 establishs a secure binding between exchanged public keys and 81 identifiers, it provides proof-of-possession of the exchanged public 82 keys to each peer, and it enables the establishment of trust in 83 public keys that can subsequently be used to faccilitate 84 authentication in other authentication and key exchange protocols. 86 1.1. Requirements Language 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 [RFC2119]. 92 1.2. Notation 94 This memo describes a cryptographic exchange using sets of elements 95 called groups. Groups can be either traditional finite field or can 96 be based on elliptic curves. The public keys exchanged by PKEX are 97 elements in a group. Elements in groups are denoted in upper-case 98 and scalar values are denoted with lower-case. The generator of the 99 group is G. 101 When both the initator and responder use a similar, but unique, datum 102 it is denoted by appending an "i" for initiator or "r" for responder, 103 e.g. if each side needs an element C then the initiator's is Ci and 104 the responder's is Cr. 106 During the exchange, one side will generate data and the other side 107 will attempt to reconstruct it. The reconstructed data is "primed". 108 That is, if the initiator generates C then when responder tries to 109 reconstruct it, the responder will refer to it as C'. Data that is 110 directly sent and received is not primed. 112 The following notation is used in this memo: 114 C = A + B 115 The "group operation" on two elements, A and B, that produces a 116 third element, C. For finite field cryptography this is the 117 modular multiplication, for elliptic curve cryptography this is 118 point addition. 120 C = a * B 121 This denotes repeated application of the group operation to B-- 122 i.e. B + B-- (a - 1) times. 124 a = H(b) 125 A cryptographic hash function that takes data b of indeterminate 126 length and returns a fixed sized digest a. 128 a = F(B) 129 A mapping function that takes an element and returns a scalar. 130 For elliptic curve cryptography, F() returns the x-coordinate of 131 the point B. For finite field cryptography, F() is the identity 132 function. 134 a = KDF-b(c, d) 135 A key derivation function that derives an output key a of length 136 b from an input key c and context d. 138 c = a | b 139 Concatentation of data a with data b producing c. 141 {a}b 142 Authenticated-encryption of data a with key b. 144 2. Properties 146 Subversion of PKEX involves an adversary being able to insert its own 147 public key into the exchange without the exchange failing, resulting 148 in one of the parties to the exchange believing the adversary's 149 public key actually belongs to the protocol peer. 151 PKEX has the following properties: 153 o An adversary is unable to subvert the exchange without knowing the 154 password. 156 o An adversary is unable to discover the password through passive 157 attack. 159 o The only information exposed by an active attack is whether a 160 single guess of the password is correct or not. 162 o Proof-of-possession of the private key is provided. 164 o At the end of the protocol, either trust is established in the 165 peer's public key and the public key is bound to the peer's 166 identity, or the exchange fails. 168 3. Assumptions 170 Due to the nature of the exchange, only DSA ([DSS]) and ECDSA 171 ([X9.62]) keys can be exchanged with PKEX. 173 PKEX requires fixed elements that are unique to the particular role 174 in the protocol, an initiator-specific element and a responder- 175 specific element. They need not be secret. It is assumed that both 176 parties know the role-specific elements for the particular group in 177 which their key pairs were derived. This memo does not proscribe any 178 way to generate these role-specific elements but the "Hunting and 179 Pecking" technique of [RFC7664] could be used with a slight 180 variation. Instead of inputting a password and generating a secret 181 element, a common string such as "PKEX Initiator Element" can be used 182 to generate a public element. For elliptic curve cryptography, the 183 technique of "hashing into an elliptic curve" from [hash2ec] could be 184 used, again with a common string, to produce role-specific elements. 186 The authenticated-encryption algorithm provides deterministic "key 187 wrapping". To achieve this the AE scheme used in PKEX is [RFC5297]. 189 The KDF provides for the generation of a cryptographically strong 190 secret key from an "imperfect" source of randomness. To achieve this 191 the KDF used in PKEX is the unsalted version of [RFC5869]. 193 The following assumptions are made on PKEX: 195 o Only the peers involved in the exchange know the password. 197 o The peers' public keys are from the same group. 199 o The discrete logarithms of the public role-specific elements are 200 unknown, and determining them is computationally infeasible. 202 4. Cryptographic Primitives 204 HKDF requires an underlying hash function and AES-SIV requires a key 205 length. To provide for consistent security the hash algorithm and 206 key length depend on the group chosen to use with PKEX. 208 For ECC, the hash algorithm and key length depends on the size of the 209 prime defining the curve, p: 211 o SHA-256 and 256 bits: when len(p) <= 256 213 o SHA-384 and 384 bits: when 256 < len(p) <= 384 215 o SHA-512 and 512 bits: when 384 < len(p) 217 For FFC, the hash algorithm depends on the prime, p, defining the 218 finite field: 220 o SHA-256 and 256 bits: when len(p) <= 2048 222 o SHA-384 and 384 bits: when 2048 < len(p) <= 3072 224 o SHA-512 and 512 bits: when 3072 < len(p) 226 5. Protocol Definition 228 PKEX is a balanced PAKE. The identical version of the password is 229 used by both parties. 231 PKEX consists of two phases: exchange and commit/reveal. It is 232 described using the popular protocol participants, Alice (an 233 initiator of PKEX), and Bob (a responder of PKEX). 235 We denote Alice's role-specific element a Pi and Bob's as Pr. The 236 password is pw. For simplicity, Alice's identity is "Alice" and 237 Bob's identity is "Bob". Alice's public key she wants to share with 238 Bob is A and her private key is a, while Bob's public key he wants to 239 share with Alice is B and his private key is b. 241 5.1. Exchange Phase 243 The Exchange phase is essentially the SPAKE2 key exchange. The peers 244 derive ephemeral public keys, encrypt, and exchange them. Each party 245 hashes a concatentation of his or her identity and the password and 246 operates on the role-specific element to obtain a secret encrypting 247 element. The group operation is then performed with the ephemeral 248 key and the secret encrypting element to produce an encrypted 249 ephmeral key. 251 Alice: Bob: 252 ------ ---- 253 x, X = x*G y, Y = y*G 254 Qi = H(Alice|pw)*Pi Qr = H(Bob|pw)*Pr 255 M = X + Qa 256 M ------> 257 Qi = H(Alice|pw)*Pi 258 X' = M - Qi 259 N = Y + Qr 260 <------ N 261 Qr = H(Bob|pw)*Pr 262 Y' = N - Qr 264 Both M and N MUST be verified to be valid elements in the selected 265 group. If either one is not valid the protocol fails. 267 At this point in time the peers have exchanged ephemeral elements 268 that will be unknown except by someone with knowledge of the 269 password. Given our assumptions that means only Alice and Bob can 270 know the elements X and Y. 272 The secret encrypting elements are irretrievably deleted at this 273 point. 275 5.2. Commit/Reveal Phase 277 In the Commit/Reveal phase the peers commit to the particular public 278 key they wish to exchange and then reveal it to the peer. 280 Alice: Bob: 281 ------ ---- 282 ka = KDF-n(F(a*Y'), F(M) | F(N) | 283 F(A) | F(Y') | pw) 284 u = HMAC(ka, F(X) | F(Y') | 285 F(A) | Alice | 0) 286 z = KDF-n(F(x*Y'), F(M) | F(N) | 287 F(X) | F(Y') | pw) 289 {A, u}z ------> 291 z = KDF-n(F(y*X'), F(M) | F(N) | 292 F(X') | F(Y) | pw) 293 if (SIV-decrypt returns fail) fail 294 if (A not valid element) fail 295 ka' = KDF-n(F(y*A), F(M) | F(N) | 296 F(A) | F(Y) | pw) 297 u' = HMAC(ka', F(X') | F(Y) | 298 F(A) | Alice | 0) 299 if (u' != u) fail 300 kb = KDF-n(F(b*X'), F(N) | F(M) | 301 F(B) | F(X') | pw) 302 v = HMAC(kb, F(Y) | F(X') | 303 F(B) | Bob | 1) 305 <------ {B, v}z 307 if (SIV-decrypt returns fail) fail 308 if (B not valid element) fail 309 kb' = KDF-n(F(x*B'), F(N) | F(M) | 310 F(B') | F(X) | pw) 311 v' = HMAC(kb', F(Y') | F(X) | 312 F(B') | Bob | 1) 313 if (v'!= v) fail 315 where 0 and 1 are single octets of the value zero and one, 316 respectively, n is the key length from Section 4, and both the KDF 317 and HMAC use the hash algorithm from Section 4. 319 If the parties didn't fail they have each other's public key, 320 knowledge that the peer possesses the corresponding private key, and 321 trust that the public key belongs to the peer's stated identity. 323 6. IANA Considerations 325 This memo could create a registry of the fixed public elements for a 326 nice cross section of popular groups. Or not. If it ends up doing 327 so there will be IANA Considerations here, otherwise there won't be. 329 7. Security Considerations 331 The encrypted shares exchanged in the Exchange phase MUST be 332 ephemeral. Reuse of these keys, even with a different password, 333 voids the security of the exchange. 335 The discrete logaritm of the fixed public elements MUST not be known. 336 Knowledge of either of these values voids the security of the 337 exchange. 339 The public keys exchanged in PKEX are never disclosed to an attacker, 340 either passive or active. While they are, as the name implies, 341 public, PKEX provides for secrecy of the exchanged keys for any 342 protocol that might need such a capability. 344 PKEX has forward secrecy in the sense that exposure of the password 345 used in a previous run of the protocol will not affect the security 346 of that run. 348 There is no proof of security of PKEX at this time but the Exchange 349 phase is SPAKE2 and the security proof for that protocol can be used 350 to help prove the security of PKEX. 352 8. References 354 8.1. Normative References 356 [DSS] U.S. Department of Commerce/National Institute of 357 Standards and Technology, "Digital Signature Standard 358 (DSS)", Federal Information Processing Standards FIPS PUB 359 186-4, July 2013. 361 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 362 Requirement Levels", BCP 14, RFC 2119, March 1997. 364 [RFC5297] Harkins, D., "Synthetic Initialization Vector (SIV) 365 Authenticated Encryption Using the Advanced Encryption 366 Standard (AES)", RFC 5297, DOI 10.17487/RFC5297, October 367 2008, . 369 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 370 Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/ 371 RFC5869, May 2010, 372 . 374 [X9.62] American National Standards Institute, "X9.62-2005", 375 Public Key Cryptography for the Financial Services 376 Industry (ECDSA), 2005. 378 8.2. Informative References 380 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 381 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 382 Transport Layer Security (TLS) and Datagram Transport 383 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 384 June 2014, . 386 [RFC7664] Harkins, D., Ed., "Dragonfly Key Exchange", RFC 7664, DOI 387 10.17487/RFC7664, November 2015, 388 . 390 [RFC7670] Kivinen, T., Wouters, P., and H. Tschofenig, "Generic Raw 391 Public-Key Support for IKEv2", RFC 7670, DOI 10.17487/ 392 RFC7670, January 2016, 393 . 395 [hash2ec] Coron, J-S. and T. Icart, "An indifferentiable hash 396 function into elliptic curves", Cryptology ePrint Archive 397 Report 2009/340, 2009. 399 Appendix A. Appendix 401 Maybe show a sample PKEX exchange 403 Author's Address 405 Dan Harkins 406 HP Enterprise 407 1322 Crossman avenue 408 Sunnyvale, California 94089 409 USA 411 Phone: +1 415 997 9834 412 Email: dharkins@lounge.org