idnits 2.17.1 draft-ietf-dnssd-pairing-info-02.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 == Line 593 has weird spacing: '...mmmmmmm m m ...' == Line 615 has weird spacing: '...mmmmmmm mmm ...' -- The document date (October 23, 2018) is 2005 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-ietf-dnssd-pairing-04 == Outdated reference: A later version (-08) exists of draft-ietf-dnssd-prireq-00 == Outdated reference: A later version (-05) exists of draft-ietf-dnssd-privacy-04 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Kaiser 3 Internet-Draft 4 Intended status: Informational C. Huitema 5 Expires: April 26, 2019 Private Octopus Inc. 6 October 23, 2018 8 Device Pairing Design Issues 9 draft-ietf-dnssd-pairing-info-02 11 Abstract 13 This document discusses issues and problems occuring in the design of 14 device pairing mechanism. It presents experience with existing 15 pairing systems and general user interaction requirements to make the 16 case for "short authentication strings". It then reviews the design 17 of cryptographic algorithms designed to maximise the robustness of 18 the short authentication string mechanisms, as well as implementation 19 considerations such as integration with TLS. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 26, 2019. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Document Organization . . . . . . . . . . . . . . . . . . 3 57 2. Protocol Independent Secure Pairing . . . . . . . . . . . . . 3 58 3. Identity Assurance . . . . . . . . . . . . . . . . . . . . . 4 59 4. Manual Authentication . . . . . . . . . . . . . . . . . . . . 4 60 4.1. Short PIN Proved Inadequate . . . . . . . . . . . . . . . 4 61 4.2. Push Buttons Just Work, But Are Insecure . . . . . . . . 5 62 4.3. Short Range Communication . . . . . . . . . . . . . . . . 6 63 4.4. Short Authentication Strings . . . . . . . . . . . . . . 6 64 4.5. Revisiting the PIN versus SAS discussion . . . . . . . . 7 65 5. Resist Cryptographic Attacks . . . . . . . . . . . . . . . . 8 66 6. Privacy Requirements . . . . . . . . . . . . . . . . . . . . 11 67 7. Using TLS . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 8. QR codes . . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 9. Intra User Pairing and Transitive Pairing . . . . . . . . . . 14 70 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 71 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 72 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 73 13. Informative References . . . . . . . . . . . . . . . . . . . 15 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 76 1. Introduction 78 To engage in secure and privacy preserving communication, hosts need 79 to differentiate between authorized peers, which must both know about 80 the host's presence and be able to decrypt messages sent by the host, 81 and other peers, which must not be able to decrypt the host's 82 messages and ideally should not be aware of the host's presence. The 83 necessary relationship between host and peer can be established by a 84 centralized service, e.g. a certificate authority, by a web of trust, 85 e.g. PGP, or -- without using global identities -- by device 86 pairing. 88 The general pairing requirement is easy to state: establish a trust 89 relation between two entities in a secure manner. But details 90 matter, and in this section we explore the detailed requirements that 91 will guide the design of a pairing protocol. 93 This document does not specify an actual pairing protocol, but it 94 served as the basis for the design of the pairing protocol developed 95 for DNS-SD privacy [I-D.ietf-dnssd-pairing]. The requirement of a 96 pairing system for private discovery are analyzed in part in 97 [I-D.ietf-dnssd-prireq]. 99 1.1. Document Organization 101 NOTE TO RFC EDITOR: remove or rewrite this section before 102 publication. 104 This document results from a split of an earlier pairing draft that 105 contained two parts. The first part, presented the pairing need, and 106 the list of requirements that shall be met. The second part 107 presented the design is the actual specification of the protocol. 109 In his early review, Steve Kent observed that the style of the first 110 part seems inappropriate for a standards track document, and 111 suggested that the two parts should be split into two documents, the 112 first part becoming an informational document, and the second 113 focusing on standard track specification of the protocol, making 114 reference to the informational document as appropriate. 116 The working group approved this split. 118 2. Protocol Independent Secure Pairing 120 Many pairing protocols have already been developed, in particular for 121 the pairing of devices over specific wireless networks. For example, 122 the current Bluetooth specifications include a pairing protocol that 123 has evolved over several revisions towards better security and 124 usability [BTLEPairing]. The Wi-Fi Alliance defined the Wi-Fi 125 Protected Setup process to ease the setup of security-enabled Wi-Fi 126 networks in home and small office environments [WPS]. Other wireless 127 standards have defined or are defining similar protocols, tailored to 128 specific technologies. 130 In this document we provide background and discuss the design of a 131 manually authenticated pairing protocol that is independent of the 132 underlying network protocol stack. We discuss (1) means allowing the 133 two parties engaged in the pairing to discover each other in an 134 existing unsecured network -- e.g. means for learning about the 135 network parameters of the respective other device -- which allows 136 them to establish a connection; (2) agreeing on a shared secret via 137 this connection; and (3) manually authenticating this secret. For 138 our discussion and our secure pairing protocol specification 139 [I-D.ietf-dnssd-pairing], we assume an IP based unsecured network. 140 With little adaption, this pairing mechanism can be used on other 141 protocol stacks as well. 143 We limit the goal of the protocol to the establishment of a shared 144 secret between two parties. Once that secret has been established, 145 it can trivially be used to secure the exchange of other 146 informations, such as for example public keys and certificates. 148 3. Identity Assurance 150 The parties in the pairing must be able to identify each other. To 151 put it simply, if Alice believes that she is establishing a pairing 152 with Bob, she must somehow ensure that the pairing is actually 153 established with Bob, and not with some interloper like Eve or 154 Nessie. Providing this assurance requires designing both the 155 protocol and the user interface (UI) with care. 157 Consider for example an attack in which Eve tricks Alice into 158 engaging in a pairing process while pretending to be Bob. Alice must 159 be able to discover that something is wrong, and refuse to establish 160 the pairing. The parties engaged in the pairing must at least be 161 able to verify their identities, respectively. 163 4. Manual Authentication 165 Because the pairing protocol is executed without prior knowledge, it 166 is typically vulnerable to "Man-in-the-Middle" attacks. While Alice 167 is trying to establish a pairing with Bob, Eve positions herself in 168 the middle. Instead of getting a pairing between Alice and Bob, both 169 Alice and Bob get paired with Eve. Because of this, the protocol 170 requires specific features to detect Man-in-the-Middle attacks, and 171 if possible resist them. 173 This section discusses existing techniques that are used in practice 174 for manually authenticating a Diffie-Hellman key exchange, and 175 Section 5 provides a layman description of the MiTM problem and 176 countermeasures. A more in depth exploration of manually 177 authenticated pairing protocols may be found in [NR11] and [K17]. 179 4.1. Short PIN Proved Inadequate 181 The initial Bluetooth pairing protocol relied on a four digit PIN, 182 displayed by one of the devices to be paired. The user read that PIN 183 and provided it to the other device. The PIN was then used in a 184 Password Authenticated Key Exchange. Wi-Fi Protected Setup [WPS] 185 offered a similar option. There were various attacks against the 186 actual protocol; some of the problems were caused by issues in the 187 protocol, but most were tied to the usage of short PINs. 189 In the reference implementation, the PIN is picked at random by the 190 paired device before the beginning of the exchange. But this 191 requires that the paired device is capable of generating and 192 displaying a four digit number. It turns out that many devices 193 cannot do that. For example, an audio headset does not have any 194 display capability. These limited devices ended up using static 195 PINs, with fixed values like "0000" or "0001". 197 Even when the paired device could display a random PIN, that PIN had 198 to be copied by the user on the pairing device. It turns out that 199 users do not like copying long series of numbers, and the usability 200 thus dictated that the PINs be short -- four digits in practice. But 201 there is only so much assurance as can be derived from a four digit 202 key. 204 The latest revisions of the Bluetooth Pairing protocol [BTLEPairing] 205 do not include the short PIN option anymore. The PIN entry methods 206 have been superseded by the simple "just works" method for devices 207 without displays, and by a procedure based on an SAS (short 208 authentication string) when displays are available. 210 A further problem with these PIN based approaches is that -- in 211 contrast to SASes -- the PIN is a secret instrumental in the security 212 algorithm. To guarantee security, this PIN would have to be 213 transmitted via a secure out-of-band channel. 215 4.2. Push Buttons Just Work, But Are Insecure 217 Some devices are unable to input or display any code. The industry 218 more or less converged on a "push button" solution. When the button 219 is pushed, devices enter a "pairing" mode, during which they will 220 accept a pairing request from whatever other device connects to them. 222 The Bluetooth Pairing protocol [BTLEPairing] denotes that as the 223 "just works" method. It does indeed work, and if the pairing 224 succeeds the devices will later be able to use the pairing keys to 225 authenticate connections. However, the procedure does not provide 226 any protection against MitM attacks during the pairing process. The 227 only protection is that pushing the button will only allow pairing 228 for a limited time, thus limiting the opportunities of attacks. 230 As we set up to define a pairing protocol with a broad set of 231 applications, we cannot limit ourselves to an insecure "push button" 232 method. But we probably need to allow for a mode of operation that 233 works for input-limited and display limited devices. 235 4.3. Short Range Communication 237 Many pairing protocols that use out-of-band channels have been 238 defined. Most of them are based on short range communication 239 systems, where the short range limits the feasibility for attackers 240 to access the channels. Example of such limited systems include for 241 example: 243 o QR codes, displayed on the screen of one device, and read by the 244 camera of the other device. 246 o Near Field Communication (NFC) systems, which provides wireless 247 communication with a very short range. 249 o Sound systems, in which one systems emits a sequence of sounds or 250 ultrasounds that is picked by the microphone of the other system. 252 A common problem with these solutions is that they require special 253 capabilities that may not be present in every device. Another 254 problem is that they are often one-way channels. 256 The pairing protocols should not rely on the secrecy of the out-of- 257 band channels; most of these out-of-band channels do not provide 258 confidentiality. QR codes could be read by third parties. Powerful 259 radio antennas might be able to interfere with NFC. Sensitive 260 microphones might pick the sounds. However, a property that all of 261 these channels share is authenticity, i.e. an assurance that the data 262 obtained over the out-of-band channel actually comes from the other 263 party. This is because these out-of-band channels involve the user 264 transmitting information from one device to the other. We will 265 discuss the specific case of QR codes in Section 8. 267 4.4. Short Authentication Strings 269 The evolving pairing protocols seem to converge towards using Short 270 Authentication Strings and verifying them via the "compare and 271 confirm" method. This is in line with academic studies, such as 272 [KFR09] or [USK11], and, from the users' perspective, results in a 273 very simple interaction: 275 1. Alice and Bob compare displayed strings that represent a 276 fingerprint of the afore exchanged pairing key. 278 2. If the strings match, Alice and Bob accept the pairing. 280 Most existing pairing protocols display the fingerprint of the key as 281 a 6 or 7 digit number. Usability studies show that this method gives 282 good results, with little risk that users mistakenly accept two 283 different numbers as matching. However, the authors of [USK11] found 284 that people had more success comparing computer generated sentences 285 than comparing numbers. This is in line with the argument in 286 [XKCD936] to use sequences of randomly chosen common words as 287 passwords. On the other hand, standardizing strings is more 288 complicated than standardizing numbers. We would need to specify a 289 list of common words, and the process to go from a binary fingerprint 290 to a set of words. We would need to be concerned with 291 internationalization issues, such as using different lists of words 292 in German and in English. This could require the negotiation of word 293 lists or languages inside the pairing protocols. 295 In contrast, numbers are easy to specify, as in "take a 20 bit number 296 and display it as an integer using decimal notation". 298 4.5. Revisiting the PIN versus SAS discussion 300 In section Section 4.1 we presented the drawbacks of using short 301 pins. One could object that many of the technical issues could be 302 overcome by use of better PAKE algorithms, or by supporting longer 303 PIN. And one could also argue that if PIN based pairing algorithms 304 suffer from failure modes such as static PIN configuration, SAS based 305 protocols are vulnerable to SAS bypass. 307 The SAS bypass argument is rooted in the psychology of users. In 308 practice, pairing processes can be stressful. The user has to 309 discover on each device the proper combination of key entries that 310 brings up the required pairing UI, will be anxious and eager to 311 complete the procedure, and may well be predisposed to click "OK" in 312 the final stage of the algorithm without actually verifying the SAS. 313 Some users may bypass the required comparison step, because they just 314 want to be done with the pairing. 316 An advantage of PIN based processes is that they cannot be bypassed. 317 The user must enter the PIN before continuing. Also, once the PIN is 318 entered, everything is automatic. The user does not need to input 319 more data, or press any additional button. PIN based protocols would 320 be a great fit for the QR-code based interaction. One device would 321 display a QR code that contains the PIN. Once the QR code is scanned 322 by the other device, the process is automated. 324 QR based PIN entry may be user friendly, but one of the arguments 325 developed in Section 4.1 still holds. Let's assume that an adversary 326 somehow obtains the PIN, maybe by scanning the QR code at a distance. 327 That adversary could mount MITM or impersonation attacks, and 328 compromise the pairing process. It is thus very important to ensure 329 that the PIN is only readable by the user doing the pairing. 331 We could also argue that the SAS bypass failure mode may be mitigated 332 by specific user designs. For example, instead of just clicking OK, 333 the user could be required to enter the SAS displayed by the other 334 device. This requires about the same interactions as a PIN based 335 process, and it would be slightly safer because the SAS does not have 336 to be kept secret once the keys have been exchanged. 338 If we summarize the debate, we see that both SAS and PIN based 339 solutions have failure modes depending on implementations. In the 340 SAS mode, the failure happens when the UI does not force the user to 341 copy the PIN and relies on a simple "OK to continue" dialog. In the 342 PIN mode, the failure happens when the device fails to generate a 343 random PIN for each session, and comes pre-programmed with a simple 344 static PIN of "0000" or "0001". 346 5. Resist Cryptographic Attacks 348 It is tempting to believe that once two peers are connected, they 349 could create a secret with a few simple steps, such as for example 350 (1) exchange two nonces, (2) hash the concatenation of these nonces 351 with the shared secret that is about to be established, (3) display a 352 short authentication string composed of a short version of that hash 353 on each device, and (4) verify that the two values match. This naive 354 approach might yield the following sequence of messages: 356 Alice Bob 357 g^xA --> 358 <-- g^xB 359 nA --> 360 <-- nB 361 Computes Computes 362 s = g^xAxB s = g^xAxB 363 h = hash(s|nA|nB) h = hash(s|nA|nB) 364 Displays short Displays short 365 version of h version of h 367 If the two short hashes match, Alice and Bob are supposedly assured 368 that they have computed the same secret, but there is a problem. 369 Let's redraw the same message flow, this time involving the attacker 370 Eve: 372 Alice Eve Bob 373 g^xA --> 374 g^xA'--> 375 <-- g^xB 376 <--g^xB' 377 nA --> 378 nA --> 379 <-- nB 380 Picks nB' 381 smartly 382 <--nB' 383 Computes Computes 384 s' = g^xAxB' s" = g^xA'xB 385 h' = hash(s'|nA|nB') h" = hash(s"|nA|nB) 386 Displays short Displays short 387 version of h' version of h" 389 In order to pick a nonce nB' that circumvents this naive security 390 measure, Eve runs the following algorithm: 392 s' = g^xAxB' 393 s" = g^xA'xB 394 repeat 395 pick a new version of nB' 396 h' = hash(s'|nA|nB') 397 h" = hash(s"|nA|nB) 398 until the short version of h' 399 matches the short version of h" 401 Running this algorithm will take O(2^b) iterations on average 402 (assuming a uniform distribution), where b is the bit length of the 403 SAS. Since hash algorithms are fast, it is possible to try millions 404 of values in less than a second. If the short string is made up of 405 fewer than 6 digits, Eve will find a matching nonce quickly, and 406 Alice and Bob will hardly notice the delay. Even if the matching 407 string is as long as 8 letters, Eve will probably find a value where 408 the short versions of h' and h" are close enough, e.g. start and end 409 with the same two or three letters. Alice and Bob may well be 410 fooled. 412 Eve could also utilize the fact that she may freely choose the whole 413 input for the hash function and thus choose g^xA' and g^xB' so that 414 an arbitrary collision (birthday attack) instead of a second preimage 415 is sufficient for fooling Alice and Bob. 417 The classic solution to such problems is to "commit" a possible 418 attacker to a nonce before sending it. This commitment can be 419 realized by a hash. In the modified exchange, Alice sends a secure 420 hash of her nonce before sending the actual value: 422 Alice Bob 423 g^xA --> 424 <-- g^xB 426 Computes Computes 427 s = g^xAxB s = g^xAxB 428 h_a = hash(s|nA) --> 429 <-- nB 430 nA --> 431 verifies h_a == hash(s|nA) 432 Computes Computes 433 h = hash(s|nA|nB) h = hash(s|nA|nB) 434 Displays short Displays short 435 version of h version of h 437 Alice will only disclose nA after having confirmation from Bob that 438 hash(nA) has been received. At that point, Eve has a problem. She 439 can still forge the values of the nonces, but she needs to pick the 440 nonce nA' before the actual value of nA has been disclosed. Eve 441 would still have a random chance of fooling Alice and Bob, but it 442 will be a very small chance: one in a million if the short 443 authentication string is made of 6 digits, even fewer if that string 444 is longer. 446 Nguyen et al. [NR11] survey these protocols and compare them with 447 respect to the amount of necessary user interaction and the 448 computation time needed on the devices. The authors state that such 449 a protocol is optimal with respect to user interaction if it suffices 450 for users to verify a single b-bit SAS while having a one-shot attack 451 success probability of 2^-b. Further, n consecutive attacks on the 452 protocol must not have a better success probability then n one-shot 453 attacks. 455 There is still a theoretical problem, if Eve has somehow managed to 456 "crack" the hash function. We can build "defense in depth" by some 457 simple measures. In the design presented above, the hash "h_a" 458 depends on the shared secret "s", which acts as a "salt" and reduces 459 the effectiveness of potential attacks based on pre-computed 460 catalogs. The simplest design uses a concatenation mechanism, but we 461 could instead use a keyed-hash message authentication code (HMAC 462 [RFC2104], [RFC6151]), using the shared secret as a key, since the 463 HMAC construct has proven very robust over time. Then, we can 464 constrain the size of the random numbers to be exactly the same as 465 the output of the hash function. Hash attacks often require padding 466 the input string with arbitrary data; restraining the size limits the 467 likelyhood of such padding. 469 6. Privacy Requirements 471 Pairing exposes a relation between several devices and their owners. 472 Adversaries may attempt to collect this information, for example in 473 an attempt to track devices, their owners, or their social graph. It 474 is often argued that pairing could be performed in a safe place, from 475 which adversaries are assumed absent, but experience shows that such 476 assumptions are often misguided. It is much safer to acknowledge the 477 privacy issues and design the pairing process accordingly. 479 In order to start the pairing process, devices must first discover 480 each other. We do not have the option of using the private discovery 481 protocol [I-D.ietf-dnssd-privacy] since the privacy of that protocol 482 depends on a pre-existing pairing. In the simplest design, one of 483 the devices will announce a user-friendly name using DNS-SD. 484 Adversaries could monitor the discovery protocol, and record that 485 name. An alternative would be for one device to announce a random 486 name, and communicate it to the other device via some private 487 channel. There is an obvious tradeoff here: friendly names are 488 easier to use but less private than random names. We anticipate that 489 different users will choose different tradeoffs, for example using 490 friendly names if they assume that the environment is safe, and using 491 random names in public places. 493 During the pairing process, the two devices establish a connection 494 and validate a pairing secret. As discussed in Section 4, we have to 495 assume that adversaries can mount MitM attacks. The pairing protocol 496 can detect such attacks and resist them, but the attackers will have 497 access to all messages exchanged before the validation is performed. 498 It is important to not exchange any privacy sensitive information 499 before that validation. This includes, for example, the identities 500 of the parties or their public keys. 502 7. Using TLS 504 The pairing algorithms typically combine the establishment of a 505 shared secret through an [EC]DH exchange with the verification of 506 that secret through displaying and comparing a "short authentication 507 string" (SAS). As explained in Section 5, the secure comparison 508 requires a "commit before disclose" mechanism. 510 We have three possible designs: (1) create a pairing algorithm from 511 scratch, specifying our own cryptographic protocol; (2) use an [EC]DH 512 version of TLS to negotiate a shared secret, export the key to the 513 application as specified in [RFC5705], and implement the "commit 514 before disclose" and SAS verification as part of the pairing 515 application; or, (3) use TLS, integrate the "commit before disclose" 516 and SAS verification as TLS extensions, and export the verified key 517 to the application as specified in [RFC5705]. 519 When faced with the same choice, the designers of ZRTP [RFC6189] 520 chose to design a new protocol integrated in the general framework of 521 real time communications. We don't want to follow that path, and 522 would rather not create yet another protocol. We would need to 523 reinvent a lot of the negotiation capabilities that are part of TLS, 524 not to mention algorithm agility, post quantum, and all that sort of 525 things. It is thus pretty clear that we should use TLS. 527 It turns out that there was already an attempt to define SAS 528 extensions for TLS ([I-D.miers-tls-sas]). It is a very close match 529 to our third design option, full integration of SAS in TLS, but the 530 draft has expired, and there does not seem to be any support for the 531 SAS options in the common TLS packages. 533 In our design, we will choose the middle ground option -- use TLS for 534 [EC]DH, and implement the SAS verification as part of the pairing 535 application. This minimizes dependencies on TLS packages to the 536 availability of a key export API following [RFC5705]. We will need 537 to specify the hash algorithm used for the SAS computation and 538 validation, which carries some of the issues associated with 539 "designing our own crypto". One solution would be to use the same 540 hash algorithm negotiated by the TLS connection, but common TLS 541 packages do not always make this algorithm identifier available 542 through standard APIs. A fallback solution is to specify a state of 543 the art keyed MAC algorithm. 545 8. QR codes 547 In Section 4.3, we reviewed a number of short range communication 548 systems that can be used to facilitate pairing. Out of these, QR 549 codes stand aside because most devices that can display a short 550 string can also display the image of a QR code, and because many 551 pairing scenarios involve cell phones equipped with cameras capable 552 of reading a QR code. 554 QR codes are displayed as images. An adversary equipped with 555 powerful cameras could read the QR code just as well as the pairing 556 parties. If the pairing protocol design embedded passwords or pins 557 in the QR code, adversaries could access these data and compromise 558 the protocol. On the other hand, there are ways to use QR codes even 559 without assuming secrecy. 561 QR codes could be used at two of the three stages of pairing: 562 Discovering the peer device, and authenticating the shared secret. 563 Using QR codes provides advantages in both phases: 565 o Typical network based discovery involves interaction with two 566 devices. The device to be discovered is placed in "server" mode, 567 and waits for requests from the network. The device performing 568 the discovery retrieves a list of candidates from the network. 569 When there is more than one such candidate, the device user is 570 expected to select the desired target from a list. In QR code 571 mode, the discovered device will display a QR code, which the user 572 will scan using the second device. The QR code will embed the 573 device's name, its IP address, and the port number of the pairing 574 service. The connection will be automatic, without relying on the 575 network discovery. This is arguably less error-prone and safer 576 than selecting from a network provided list. 578 o SAS based agreement involves displaying a short string on each 579 device's display, and asking the user to verify that both devices 580 display the same string. In QR code mode, one device could 581 display a QR code containing this short string. The other device 582 could scan it and compare it to the locally computed version. 583 Because the procedure is automated, there is no dependency on the 584 user diligence at comparing the short strings. 586 Offering QR codes as an alternative to discovery and agreement is 587 straightforward. If QR codes are used, the pairing program on the 588 server side might display something like: 590 Please connect to "Bob's phone 359" 591 or scan the following QR code: 593 mmmmmmm m m mmmmmmm 594 # mmm # ## "m # mmm # 595 # ### # m" #" # ### # 596 #mmmmm# # m m #mmmmm# 597 mm m mm"## m mmm mm 598 " ##"mm m"# ####"m""# 599 #"mmm mm# m"# ""m" "m 600 mmmmmmm #mmm###mm# m 601 # mmm # m "mm " " " 602 # ### # " m # "## "# 603 #mmmmm# ### m"m m m 605 If Alice's device is capable of reading the QR code, it will just 606 scan it, establishes a connection, and run the pairing protocol. 607 After the protocol messages have been exchanged, Bob's device will 608 display a new QR code, encoding the hash code that should be matched. 609 The UI might look like this: 611 Please scan the following QR code, 612 or verify that your device displays 613 the number: 388125 615 mmmmmmm mmm mmmmmmm 616 # mmm # ""#m# # mmm # 617 # ### # "# # # ### # 618 #mmmmm# # m"m #mmmmm# 619 mmmmm mmm" m m m m m 620 #"m mmm#"#"#"#m m#m 621 ""mmmmm"m#""#""m # m 622 mmmmmmm # "m"m "m"#"m 623 # mmm # mmmm m "# #" 624 # ### # #mm"#"#m " 625 #mmmmm# #mm"#""m "m" 627 Did the number match (Yes/No)? 629 With the use of QR code, the pairing is established with little 630 reliance on user judgment, which is arguably safer. 632 9. Intra User Pairing and Transitive Pairing 634 There are two usage modes for pairing: inter-user, and intra-user. 635 Users have multiple devices. The simplest design is to not 636 distinguish between pairing devices belonging to two users, e.g., 637 Alice's phone and Bob's phone, and devices belonging to the same 638 user, e.g., Alice's phone and her laptop. This will most certainly 639 work, but it raises the problem of transitivity. If Bob needs to 640 interact with Alice, should he install just one pairing for "Alice 641 and Bob", or should he install four pairings between Alice phone and 642 laptop and Bob phone and laptop? Also, what happens if Alice gets a 643 new phone? 645 One tempting response is to devise a synchronization mechanism that 646 will let devices belonging to the same user share their pairings with 647 other users. But it is fairly obvious that such service will have to 648 be designed cautiously. The pairing system relies on shared secrets. 649 It is much easier to understand how to manage secrets shared between 650 exactly two parties than secrets shared with an unspecified set of 651 devices. 653 Transitive pairing raises similar issues. Suppose that a group of 654 users wants to collaborate. Will they need to set up a fully 655 connected graph of pairings using the simple peer-to-peer mechanism, 656 or could they use some transitive set, so that if Alice is connected 657 with Bob and Bob with Carol, Alice automatically gets connected with 658 Carol? Such transitive mechanisms could be designed, e.g. using a 659 variation of Needham-Scroeder symmetric key protocol [NS1978], but it 660 will require some extensive work. Groups can of course use simpler 661 solution, e.g., build some star topology. 663 Given the time required, intra-user pairing synchronization 664 mechanisms and transitive pairing mechanisms are left for further 665 study. 667 10. Security Considerations 669 This document lists a set of security issues that have to be met by 670 pairing protocols, but does not specify any protocol. 672 11. IANA Considerations 674 This draft does not require any IANA action. 676 12. Acknowledgments 678 We would like to thank Steve Kent for a detailed early review of an 679 early draft of this document. Both him and Ted Lemon were 680 influential in the decision to separate the analysis of pairing 681 requirements from the specification of pairing protocol in 682 [I-D.ietf-dnssd-pairing] 684 13. Informative References 686 [BTLEPairing] 687 Bluetooth SIG, "Bluetooth Low Energy Security Overview", 688 2016, 689 . 692 [I-D.ietf-dnssd-pairing] 693 Huitema, C. and D. Kaiser, "Device Pairing Using Short 694 Authentication Strings", draft-ietf-dnssd-pairing-04 (work 695 in progress), April 2018. 697 [I-D.ietf-dnssd-prireq] 698 Huitema, C., "DNS-SD Privacy and Security Requirements", 699 draft-ietf-dnssd-prireq-00 (work in progress), September 700 2018. 702 [I-D.ietf-dnssd-privacy] 703 Huitema, C. and D. Kaiser, "Privacy Extensions for DNS- 704 SD", draft-ietf-dnssd-privacy-04 (work in progress), April 705 2018. 707 [I-D.miers-tls-sas] 708 Miers, I., Green, M., and E. Rescorla, "Short 709 Authentication Strings for TLS", draft-miers-tls-sas-00 710 (work in progress), February 2014. 712 [K17] Kaiser, D., "Efficient Privacy-Preserving 713 Configurationless Service Discovery Supporting Multi-Link 714 Networks", 2017, 715 . 717 [KFR09] Kainda, R., Flechais, I., and A. Roscoe, "Usability and 718 Security of Out-Of-Band Channels in Secure Device Pairing 719 Protocols", DOI: 10.1145/1572532.1572547, SOUPS 720 09, Proceedings of the 5th Symposium on Usable Privacy and 721 Security, Mountain View, CA, January 2009. 723 [NR11] Nguyen, L. and A. Roscoe, "Authentication protocols based 724 on low-bandwidth unspoofable channels: a comparative 725 survey", DOI: 10.3233/JCS-2010-0403, Journal of Computer 726 Security, Volume 19 Issue 1, Pages 139-201, January 2011. 728 [NS1978] Needham, R. and M. Schroeder, ". Using encryption for 729 authentication in large networks of computers", 730 Communications of the ACM 21 (12): 993-999, 731 DOI: 10.1145/359657.359659, December 1978. 733 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 734 Hashing for Message Authentication", RFC 2104, 735 DOI 10.17487/RFC2104, February 1997, 736 . 738 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 739 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 740 March 2010, . 742 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 743 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 744 RFC 6151, DOI 10.17487/RFC6151, March 2011, 745 . 747 [RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: 748 Media Path Key Agreement for Unicast Secure RTP", 749 RFC 6189, DOI 10.17487/RFC6189, April 2011, 750 . 752 [USK11] Uzun, E., Saxena, N., and A. Kumar, "Pairing devices for 753 social interactions: a comparative usability evaluation", 754 DOI: 10.1145/1978942.1979282, Proceedings of the 755 International Conference on Human Factors in Computing 756 Systems, CHI 2011, Vancouver, BC, Canada, May 2011. 758 [WPS] Wi-Fi Alliance, "Wi-Fi Protected Setup", 2016, 759 . 762 [XKCD936] Munroe, R., "XKCD: Password Strength", 2011, 763 . 765 Authors' Addresses 767 Daniel Kaiser 768 Esch-sur-Alzette 4360 769 Luxembourg 771 Email: daniel@kais3r.de 773 Christian Huitema 774 Private Octopus Inc. 775 Friday Harbor, WA 98250 776 U.S.A. 778 Email: huitema@huitema.net