idnits 2.17.1 draft-harkins-pkex-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 == 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 (September 12, 2016) is 2754 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 September 12, 2016 5 Expires: March 16, 2017 7 PKEX 8 draft-harkins-pkex-00 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 March 16, 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Properties . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 4 56 4.1. Exchange Phase . . . . . . . . . . . . . . . . . . . . . 5 57 4.2. Commit Phase . . . . . . . . . . . . . . . . . . . . . . 5 58 4.3. Reveal Phase . . . . . . . . . . . . . . . . . . . . . . 6 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 63 7.2. Informative References . . . . . . . . . . . . . . . . . 8 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, for example TLS 71 ([RFC7250]), or IKEv2 ([RFC7670]) Usually these specifications state 72 that "establishing trust in raw public keys is outside the scope of 73 this standard." The Public Key Exchange (PKEX) is designed to fill 74 that gap and enable the establishment of trust in public keys that 75 can subsequently be used to faccilitate authentication in other 76 authentication and key exchange protocols. 78 1.1. Requirements Language 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in RFC 2119 [RFC2119]. 84 1.2. Notation 86 This memo describes a cryptographic exchange using sets of elements 87 called groups. Groups can be either traditional finite field or can 88 be based on elliptic curves. The public keys exchanged by PKEX are 89 elements in a group. Elements in groups are denoted in upper-case 90 and scalar values are denoted with lower-case. The generator of the 91 group is G. 93 When both the initator and responder use a similar, but unique, datum 94 it is denoted by appending an "i" for initiator or "r" for responder, 95 e.g. if each side needs an element C then the initiator's is Ci and 96 the responder's is Cr. 98 During the exchange, one side will generate data and the other side 99 will attempt to reconstruct it. The reconstructed data is "primed". 100 That is, if the initiator generates C then when responder tries to 101 reconstruct it, the responder will refer to it as C'. Data that is 102 directly sent and received is not primed. 104 The following notation is used in this memo: 106 C = A + B 107 The "group operation" on two elements, A and B, that produces a 108 third element, C. For finite field cryptography this is the 109 modular multiplication, for elliptic curve cryptography this is 110 point addition. 112 C = a * B 113 This denotes repeated application of the group operation to B-- 114 i.e. B + B-- (a - 1) times. 116 a = H(b) 117 A cryptographic hash function that takes data b of indeterminate 118 length and returns a fixed sized digest a. 120 a = F(B) 121 A mapping function that takes an element and returns a scalar. 122 For elliptic curve cryptography, F() returns the x-coordinate of 123 the point B. For finite field cryptography, F() is the identity 124 function. 126 a = KDF(b, c) 127 A key derivation function that derives an output key a from an 128 input key b and context c. 130 c = a | b 131 Concatentation of data a with data b producing c. 133 2. Properties 135 Subversion of PKEX involves an adversary being able to insert its own 136 public key into the exchange resulting in one of the parties to the 137 exchange believing the adversary's public key actually belongs to the 138 protocol peer. 140 PKEX has the following properties: 142 o An adversary is unable to subvert the exchange without knowing the 143 password. 145 o An adversary is unable to discover the password through passive 146 attack. 148 o The only information exposed by an active attack is whether a 149 single guess of the password is correct or not. 151 o Proof-of-possession of the private key is provided. 153 o At the end of the protocol, either trust is established in the 154 peer's public key or the exchange fails. 156 3. Assumptions 158 Due to the nature of the exchange, only DSA ([DSS]) and ECDSA 159 ([X9.62]) keys can be exchanged with PKEX. 161 PKEX requires fixed elements that are unique to the particular role 162 in the protocol, an initiator-specific element and a responder- 163 specific element. They need not be secret. It is assumed that both 164 parties know the role-specific elements for the particular group in 165 which their key pairs were derived. This memo does not proscribe any 166 way to generate these role-specific elements but the "Hunting and 167 Pecking" technique of [RFC7664] could be used with a slight 168 variation. Instead of inputting a password and generating a secret 169 element, a common string such as "PKEX Initiator Element" can be used 170 to generate a public element. For elliptic curve cryptography, the 171 technique of "hashing into an elliptic curve" from [hash2ec] could be 172 used, again with a common string, to produce role-specific elements. 174 The following assumptions are made on PKEX: 176 o Only the peers involved in the exchange know the password. 178 o The peers' public keys are from the same group. 180 o The discrete logarithms of the public role-specific elements are 181 unknown, and determining them is computationally infeasible. 183 4. Protocol Definition 185 PKEX is a balanced PAKE. The identical version of the password is 186 used by both parties. 188 PKEX consists of three phases: exchange, commit, and reveal. It is 189 described using the popular protocol participants, Alice (an 190 initiator of PKEX), and Bob (a responder of PKEX). 192 We denote Alice's role-specific element a Pi and Bob's as Pr. The 193 password is pw. For simplicity, Alice's identity is "Alice" and 194 Bob's identity is "Bob". Alice's public key she wants to share with 195 Bob is A and her private key is a, while Bob's public key he wants to 196 share with Alice is B and his private key is b. 198 4.1. Exchange Phase 200 The Exchange phase is essentially the SPAKE key exchange. The peers 201 derive ephemeral public keys, encrypt, and exchange them. Each party 202 hashes a concatentation of his or her identity and the password and 203 operates on the role-specific element to obtain a secret encrypting 204 element. The group operation is then performed with the ephemeral 205 key and the secret encrypting element to produce an encrypted 206 ephmeral key. 208 Alice: Bob: 209 ------ ---- 210 x, X = x*G y, Y = y*G 211 Qi = H(Alice|pw)*Pi Qr = H(Bob|pw)*Pr 212 M = X + Qa 213 M ------> 214 Qi = H(Alice|pw)*Pi 215 X' = M - Qi 216 N = Y + Qr 217 <------ N 218 Qr = H(Bob|pw)*Pr 219 Y' = N - Qr 221 At this point in time the peers have exchanged ephemeral elements 222 that will be unknown except by someone with knowledge of the 223 password. Given our assumptions that means only Alice and Bob can 224 know the elements X and Y. 226 The secret encrypting elements are irretrievably deleted at this 227 point. 229 4.2. Commit Phase 231 In the Commit phase the peers commit to the particular public key 232 they wish to exchange. 234 Alice: Bob: 235 ------ ---- 236 sa = F(a*Y') 237 ka = KDF(sa, F(M) | F(N) | 238 F(A) | F(Y') | pw) 239 u = HMAC(ka, F(X) | F(Y') | 240 F(A) | Alice | 0) 241 u ------> 242 sb = F(b*X') 243 kb = KDF(sb, F(N) | F(M) | 244 F(B) | F(X') | pw) 245 v = HMAC(kb, F(Y) | F(X') | 246 F(B) | Bob | 1) 247 <------ v 249 where 0 and 1 are single octets of the value zero and one, 250 respectively. 252 At this point the parties have committed to their public/private key 253 pairs but have net yet exchanged their public keys. There is no 254 proof that either side possesses the private key or whether the 255 public key is really the analog to the private key but they have made 256 irrevocable committments to those statements. 258 4.3. Reveal Phase 260 In the Reveal phase the peers encrypt their public keys using a 261 secret element derived from the exchange in the Commit phase. This 262 allows each side to determine the other's public key and verify that 263 the peer holds the private key. 265 Alice: Bob: 266 ------ ---- 267 Z = x*Y' 268 R = A + Z 269 R ------> 270 Z = y*X' 271 A' = R - Z 272 sa' = F(y*A') 273 ka' = KDF(sa', F(M) | F(N) | 274 F(A') | F(Y) | pw) 275 u' = HMAC(ka', F(X') | F(Y) | 276 F(A') | Alice | 0) 277 if (u' != u) fail 278 T = B + Z 279 <------ T 280 B' = T - Z 281 sb' = F(x*B') 282 kb' = KDF(sb', F(N) | F(M) | 283 F(B') | F(X) | pw) 284 v' = HMAC(kb', F(Y') | F(X) | 285 F(B') | Bob | 1) 286 if (v'!= v) fail 288 where 0 and 1 are single octets of the value zero and one, 289 respectively. 291 At this point, if the parties didn't fail they have each other's 292 public key and trust that it belongs to the peer's stated identlty. 293 They can use the public key in another protocol to authenticate that 294 identity. They provided proof of possession by binding their private 295 key to the peer's ephemeral share made during the Exchange phase, 296 they signed their public key with the resulting secret. The ability 297 of the peer to compute this secret and verify the data exchanged 298 during the Commit phase demonstrates the public key is the analog to 299 the private key. 301 5. IANA Considerations 303 This memo could create a registry of the fixed public elements for a 304 nice cross section of popular groups. Or not. If it ends up doing 305 so there will be IANA Considerations here, otherwise there won't be. 307 6. Security Considerations 309 The encrypted shares exchanged in the Exchange phase MUST be 310 ephemeral. Reuse of these keys, even with a different password, 311 voids the security of the exchange. 313 The discrete logaritm of the fixed public elements MUST not be known. 314 Knowledge of either of these values voids the security of the 315 exchange. 317 For PKEX to be useful, a public key is going to be exchanged with a 318 multitude of people and once exchanged the public key is, well, 319 public. This means that an adversary will know the public key that a 320 particular peer wants to exchange in a future run of PKEX. With this 321 knowledge an adversary can attack the Reveal exchange and, knowing A 322 (or B), determine Z for the PKEX exchange and insert her public key. 323 This will fail, though, because A (or B) was committed to in the 324 Commit phase. The adversary is unable to subvert the Commit phase 325 because, while knowing A (or B) she does not know the corresponding 326 private key and does not know the ephemeral share that the peer 327 provided since she does not know the password. 329 There is no proof of security of PKEX at this time. 331 7. References 333 7.1. Normative References 335 [DSS] U.S. Department of Commerce/National Institute of 336 Standards and Technology, "Digital Signature Standard 337 (DSS)", Federal Information Processing Standards FIPS PUB 338 186-4, July 2013. 340 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 341 Requirement Levels", BCP 14, RFC 2119, March 1997. 343 [X9.62] American National Standards Institute, "X9.62-2005", 344 Public Key Cryptography for the Financial Services 345 Industry (ECDSA), 2005. 347 7.2. Informative References 349 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 350 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 351 Transport Layer Security (TLS) and Datagram Transport 352 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 353 June 2014, . 355 [RFC7664] Harkins, D., Ed., "Dragonfly Key Exchange", RFC 7664, DOI 356 10.17487/RFC7664, November 2015, 357 . 359 [RFC7670] Kivinen, T., Wouters, P., and H. Tschofenig, "Generic Raw 360 Public-Key Support for IKEv2", RFC 7670, DOI 10.17487/ 361 RFC7670, January 2016, 362 . 364 [hash2ec] Coron, J-S. and T. Icart, "An indifferentiable hash 365 function into elliptic curves", Cryptology ePrint Archive 366 Report 2009/340, 2009. 368 Appendix A. Appendix 370 Maybe show a sample PKEX exchange 372 Author's Address 374 Dan Harkins 375 HP Enterprise 376 1322 Crossman avenue 377 Sunnyvale, California 94089 378 USA 380 Phone: +1 415 997 9834 381 Email: dharkins@lounge.org