idnits 2.17.1 draft-ietf-dnssd-pairing-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 -- The document date (October 27, 2016) is 2728 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '32' on line 754 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-05) exists of draft-ietf-dnssd-privacy-00 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Huitema 3 Internet-Draft 4 Intended status: Standards Track D. Kaiser 5 Expires: April 30, 2017 University of Konstanz 6 October 27, 2016 8 Device Pairing Using Short Authentication Strings 9 draft-ietf-dnssd-pairing-00.txt 11 Abstract 13 This document proposes a device pairing mechanism that establishes a 14 relationship between two devices by agreeing on a secret and manually 15 verifying the secret's authenticity using an SAS (short 16 authentication string). Pairing has to be performed only once per 17 pair of devices, as for a re-discovery at any later point in time, 18 the exchanged secret can be used for mutual authentication. 20 The proposed pairing method is suited for each application area where 21 human operated devices need to establish a relation that allows 22 configurationless and privacy preserving re-discovery at any later 23 point in time. Since privacy preserving applications are the main 24 suitors, we especially care about privacy. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 30, 2017. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Problem Statement and Requirements . . . . . . . . . . . . . 4 63 2.1. Secure Pairing Over Internet Connections . . . . . . . . 4 64 2.2. Identity Assurance . . . . . . . . . . . . . . . . . . . 4 65 2.3. Adequate User Interface . . . . . . . . . . . . . . . . . 4 66 2.3.1. Short PIN Proved Inadequate . . . . . . . . . . . . . 5 67 2.3.2. Push Buttons Just Work, But Are Insecure . . . . . . 6 68 2.3.3. Short Range Communication . . . . . . . . . . . . . . 6 69 2.3.4. Short Authentication Strings . . . . . . . . . . . . 7 70 2.4. Resist Cryptographic Attacks . . . . . . . . . . . . . . 7 71 2.5. Privacy Requirements . . . . . . . . . . . . . . . . . . 10 72 2.6. Using TLS . . . . . . . . . . . . . . . . . . . . . . . . 11 73 2.7. QR codes . . . . . . . . . . . . . . . . . . . . . . . . 11 74 3. Design of the Pairing Mechanism . . . . . . . . . . . . . . . 12 75 3.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 13 76 3.2. Agreement . . . . . . . . . . . . . . . . . . . . . . . . 13 77 3.3. Authentication . . . . . . . . . . . . . . . . . . . . . 14 78 3.4. Intra User Pairing . . . . . . . . . . . . . . . . . . . 14 79 3.5. Pairing Data Synchronization . . . . . . . . . . . . . . 14 80 3.6. Public Authentication Keys . . . . . . . . . . . . . . . 14 81 4. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 4.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 15 83 4.2. Agreement and Authentication . . . . . . . . . . . . . . 15 84 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 86 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 87 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 88 8.1. Normative References . . . . . . . . . . . . . . . . . . 18 89 8.2. Informative References . . . . . . . . . . . . . . . . . 19 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 92 1. Introduction 94 To engage in secure and privacy preserving communication, hosts need 95 to differentiate between authorized peers, which must both know about 96 the host's presence and be able to decrypt messages sent by the host, 97 and other peers, which must not be able to decrypt the host's 98 messages and ideally should not be aware of the host's presence. The 99 necessary relationship between host and peer can be established by a 100 centralized service, e.g. a certificate authority, by a web of trust, 101 e.g. PGP, or -- without using global identities -- by device 102 pairing. 104 This document proposes a device pairing mechanism that provides human 105 operated devices with pairwise authenticated secrets, allowing mutual 106 automatic re-discovery at any later point in time along with mutual 107 private authentication. We especially care about privacy and user- 108 friendliness. 110 The proposed pairing mechanism consists of three steps needed to 111 establish a relationship between a host and a peer: 113 1. Discovery of the peer device. The host needs a means to discover 114 network parameters necessary to establish a connection to the 115 peer. During this discovery process, neither the host nor the 116 peer must disclose its presence. 118 2. Agreeing on pairing data. The devices have to agree on pairing 119 data, which can be used by both parties at any later point in 120 time to generate identifiers for re-discovery and to prove the 121 authenticity of the pairing. The pairing data can e.g. be a 122 shared secret agreed upon via a Diffie-Hellman key exchange. 124 3. Authenticate pairing data. Since in most cases the messages 125 necessary to agree upon pairing data are send over an insecure 126 channel, means that guarantee the authenticity of these messages 127 are necessary; otherwise the pairing data is in turn not suited 128 as a means for a later proof of authenticity. For the proposed 129 pairing mechanism we use manual interaction involving an SAS 130 (short authentication string) to proof the authenticity of the 131 pairing data. 133 1.1. Requirements 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in [RFC2119]. 139 2. Problem Statement and Requirements 141 The general pairing requirement is easy to state: establish a trust 142 relation between two entities in a secure manner. But details 143 matter, and in this section we explore the detailed requirements that 144 guide our design. 146 2.1. Secure Pairing Over Internet Connections 148 Many pairing protocols have already been developed, in particular for 149 the pairing of devices over specific wireless networks. For example, 150 the current Bluetooth specifications include a pairing protocol that 151 has evolved over several revisions towards better security and 152 usability [BTLEPairing]. The Wi-Fi Alliance defined the Wi-Fi 153 Protected Setup process to ease the setup of security-enabled Wi-Fi 154 networks in home and small office environments [WPS]. Other wireless 155 standards have defined or are defining similar protocols, tailored to 156 specific technologies. 158 This specification defines a pairing protocol that is independent of 159 the underlying technology. We simply make the hypothesis that the 160 two parties engaged in the pairing can discover each other and then 161 establish connections over IP in order to agree a shared secret. 163 [[TODO: Should we support certificates besides a shared secret?]] 165 2.2. Identity Assurance 167 The parties in the pairing must be able to identify each other. To 168 put it simply, if Alice believes that she is establishing a pairing 169 with Bob, she must somehow ensure that the pairing is actually 170 established with Bob, and not with some interloper like Eve or 171 Nessie. Providing this assurance requires designing both the 172 protocol and the user interface (UI) with care. 174 Consider for example an attack in which Eve tricks Alice into 175 engaging in a pairing process while pretending to be Bob. Alice must 176 be able to discover that something is wrong, and refuse to establish 177 the pairing. The parties engaged in the pairing must at least be 178 able to verify their identities, respectively. 180 2.3. Adequate User Interface 182 Because the pairing protocol is executed without prior knowledge, it 183 is typically vulnerable to "Man-in-the-middle" attacks. While Alice 184 is trying to establish a pairing with Bob, Eve positions herself in 185 the middle. Instead of getting a pairing between Alice and Bob, both 186 Alice and Bob get paired with Eve. This requires specific features in 187 the protocol to detect man-in-the-middle attacks, and if possible 188 resist them. The reference [NR11] analyzes the various proposals to 189 solve this problem, and in this document, we present a layman 190 description of these issues in Section 2.4. The various protocols 191 proposed in the literature impose diverse constraints on the UI 192 interface, which we will review here. 194 2.3.1. Short PIN Proved Inadequate 196 The initial Bluetooth pairing protocol relied on a four digit PIN, 197 displayed by one of the devices to be paired. The user would read 198 that PIN and provide it to the other device. The PIN would then be 199 used in a Password Authenticated Key Exchange. Wi-Fi Protected Setup 200 [WPS] offered a similar option. There were various attacks against 201 the actual protocol; some of the problems were caused by issues in 202 the protocol, but most were tied to the usage of short PINs. 204 In the reference implementation, the PIN is picked at random by the 205 paired device before the beginning of the exchange. But this 206 requires that the paired device is capable of generating and 207 displaying a four digit number. It turns out that many devices 208 cannot do that. For example, an audio headset does not have any 209 display capability. These limited devices ended up using static 210 PINs, with fixed values like "0000" or "0001". 212 Even when the paired device could display a random PIN, that PIN will 213 have to be copied by the user on the pairing device. It turns out 214 that users do not like copying long series of numbers, and the 215 usability thus dictated that the PINs be short -- four digits in 216 practice. But there is only so much assurance as can be derived from 217 a four digit key. 219 It is interesting to note that the latest revisions of the Bluetooth 220 Pairing protocol [BTLEPairing] do not include the short PIN option 221 anymore. The PIN entry methods have been superseded by the simple 222 "just works" method for devices without displays, and by a procedure 223 based on an SAS (short authentication string) when displays are 224 available. 226 A further problem with these PIN based approaches is that -- in 227 contrast to SASes -- the PIN is a secret instrumental in the security 228 algorithm. To guarantee security, this PIN had to be transmitted via 229 a secure out of band channel. 231 2.3.2. Push Buttons Just Work, But Are Insecure 233 Some devices are unable to input or display any code. The industry 234 more or less converged on a "push button" solution. When the button 235 is pushed, devices enter a "pairing" mode, during which they will 236 accept a pairing request from whatever other device connects to them. 238 The Bluetooth Pairing protocol [BTLEPairing] denotes that as the 239 "just works" method. It does indeed work, and if the pairing 240 succeeds the devices will later be able to use the pairing keys to 241 authenticate connections. However, the procedure does not provide 242 any protection against MITM attacks during the pairing process. The 243 only protection is that pushing the button will only allow pairing 244 for a limited time, thus limiting the opportunities of attacks. 246 As we set up to define a pairing protocol with a broad set of 247 applications, we cannot limit ourselves to an insecure "push button" 248 method. But we probably need to allow for a mode of operation that 249 works for input-limited and display limited devices. 251 2.3.3. Short Range Communication 253 There have been several attempts to define pairing protocols that use 254 "secure channels." Most of them are based on short range 255 communication systems, where the short range limits the feasibility 256 for attackers to access the channels. Example of such limited 257 systems include for example: 259 o QR codes, displayed on the screen of one device, and read by the 260 camera of the other device. 262 o Near Field Communication (NFC) systems, which provides wireless 263 communication with a very short range. 265 o Sound systems, in which one systems emits a sequence of sounds or 266 ultrasounds that is picked by the microphone of the other system. 268 A common problem with these solutions is that they require special 269 capabilities that may not be present in every device. Another 270 problem is that they are often one-way channels. Yet another problem 271 is that the side channel is not necessarily secret. QR codes could 272 be read by third parties. Powerful radios antennas might be able to 273 interfere with NFC. Sensitive microphones might pick the sounds. We 274 will discuss the specific case of QR codes in Section 2.7. 276 2.3.4. Short Authentication Strings 278 The evolving pairing protocols seem to converge towards a "display 279 and compare" method. This is in line with academic studies, such as 280 [KFR09] or [USK11]. This points to a very simple scenario: 282 1. Alice initiates pairing 284 2. Bob selects Alice's device from a list. 286 3. Alice and Bob compare displayed strings that represent a 287 fingerprint of the key. 289 4. If the strings match, Alice and Bob accept the pairing. 291 Most existing pairing protocols display the fingerprint of the key as 292 a 6 or 7 digit numbers. Usability studies show that gives good 293 results, with little risk that users mistakenly accept two different 294 numbers as matching. However, the authors of [USK11] found that 295 people had more success comparing computer generated sentences than 296 comparing numbers. This is in line with the argument in [XKCD936] to 297 use sequences of randomly chosen common words as passwords. On the 298 other hand, standardizing strings is more complicated than 299 standardizing numbers. We would need to specify a list of common 300 words, and the process to go from a binary fingerprint to a set of 301 words. We would need to be concerned with internationalization 302 issues, such as using different lists of words in German and in 303 English. This could require negotiation of word lists or languages 304 inside the pairing protocols. 306 In contrast, numbers are easy to specify, as in "take a 20 bit number 307 and display it as an integer using decimal notation." 309 2.4. Resist Cryptographic Attacks 311 It is tempting to believe that once two peers are connected, they 312 could create a secret with a few simple steps, such as for example 313 exchange two nonces, hash the concatenation of these nonces with the 314 shared secret that is about to be established, display a short 315 authentication string composed of a short version of that hash on 316 each device, and verify that the two values match. The sequence of 317 messages would be something like: 319 Alice Bob 320 g^xA --> 321 <-- g^xB 322 nA --> 323 <-- nB 324 Computes Computes 325 s = g^xAxB s = g^xAxB 326 h = hash(s|nA|nB) h = hash(s|nA|nB) 327 Displays short Displays short 328 version of h version of h 330 If the two short hashes match, Alice and Bob are supposedly assured 331 that they have computed the same secret, but there is a problem. The 332 exchange may not deter a smart attacker in the middle. Let's redraw 333 the same message flow, this time involving Eve: 335 Alice Eve Bob 336 g^xA --> 337 g^xA'--> 338 <-- g^xB 339 <--g^xB' 340 nA --> 341 nA --> 342 <-- nB 343 Picks nB' 344 smartly 345 <--nB' 346 Computes Computes 347 s' = g^xAxB' s" = g^xA'xB 348 h' = hash(s|nA|nB') h" = hash(s"|nA|nB) 349 Displays short Displays short 350 version of h' version of h" 352 Let's now assume that to pick the nonce nB' smartly, Eve runs the 353 following algorithm: 355 s' = g^xAxB' 356 s" = g^xA'xB 357 repeat 358 pick a new version of nB' 359 h' = hash(s|nA|nB') 360 h" = hash(s"|nA|nB) 361 until the short version of h' 362 matches the short version of h" 364 Of course, running this algorithm will require in theory as many 365 iterations as the possible values of the short hash. But hash 366 algorithms are fast, and it is possible to try millions of values in 367 less than a second. If the short string is made up of fewer than 6 368 digits, Eve will find a matching nonce quickly, and Alice and Bob 369 will hardly notice the delay. Even if the matching string is as long 370 as 8 letters, Eve will probably find a value where the short versions 371 of h' and h" are close enough, e.g. start and end with the same two 372 or three letters. Alice and Bob may well be fooled. 374 The classic solution to such problems is to "commit" a possible 375 attacker to a nonce before sending it. This commitment can be 376 realized by a hash. In the modified exchange, Alice sends a secure 377 hash of her nonce before sending the actual value: 379 Alice Bob 380 g^xA --> 381 <-- g^xB 383 Computes Computes 384 s = g^xAxB s = g^xAxB 385 h_a = hash(s|nA) --> 386 <-- nB 387 nA --> 388 verifies h_a == hash(s|nA) 389 Computes Computes 390 h = hash(s|nA|nB) h = hash(s|nA|nB) 391 Displays short Displays short 392 version of h version of h 394 Alice will only disclose nA after having confirmation from Bob that 395 hash(nA) has been received. At that point, Eve has a problem. She 396 can still forge the values of the nonces but she needs to pick the 397 nonce nA' before the actual value of nA has been disclosed. Eve 398 would still have a random chance of fooling Alice and Bob, but it 399 will be a very small chance: one in a million if the short 400 authentication string is made of 6 digits, even fewer if that string 401 is longer. 403 Nguyen et al. [NR11] survey these protocols and compare them with 404 respect to the amount of necessary user interaction and the 405 computation time needed on the devices. The authors state that such 406 a protocol is optimal with respect to user interaction if it suffices 407 for users to verify a single b-bit SAS while having a one-shot attack 408 success probability of 2^-b. Further, n consecutive attacks on the 409 protocol must not have a better success probability then n one-shot 410 attacks. 412 There is still a theoretical problem, if Eve has somehow managed to 413 "crack" the hash function. We build some "defense in depth" by some 414 simple measures. In the design presented above, the hash "h_a" 415 depends on the shared secret "s", which acts as a "salt" and reduces 416 the effectiveness of potential attacks based on pre-computed 417 catalogs. For simplicity, the design used a simple concatenation 418 mechanism, but we could instead use a keyed-hash message 419 authentication code (HMAC, [RFC2104], [RFC6151]), using the shared 420 secret as a key, since the HMAC construct has proven very robust over 421 time. Then, we can constrain the size of the random numbers to be 422 exactly the same as the output of the hash function. Hash attacks 423 often require padding the input string with arbitrary data; 424 restraining the size limits the likelyhood of such padding. 426 2.5. Privacy Requirements 428 Pairing exposes a relation between several devices and their owners. 429 Adversaries may attempt to collect this information, for example in 430 an attempt to track devices, their owners, or their "social graph." 431 It is often argued that pairing could be performed in a safe place, 432 from which adversaries are assumed absent, but experience shows that 433 such assumptions are often misguided. It is much safer to 434 acknowledge the privacy issues and design the pairing process 435 accordingly. 437 In order to start the pairing process, devices must first discover 438 each other. We do not have the option of using the private discovery 439 protocol [I-D.ietf-dnssd-privacy] since the privacy of that protocol 440 depends on the pre-existing pairing. In the simplest design, one of 441 the devices will announce a "friendly name" using DNS-SD. 442 Adversaries could monitor the discovery protocol, and record that 443 name. An alternative would be for one device to announce a random 444 name, and communicate it to the other device via some private 445 channel. There is an obvious tradeoff here: friendly names are 446 easier to use but less private than random names. We anticipate that 447 different users will choose different tradeoffs, for example using 448 friendly names if they assume that the environment is "safe," and 449 using random names in public places. 451 During the pairing process, the two devices establish a connection 452 and validate a pairing secret. As discussed in Section 2.3, we have 453 to assume that adversaries can mount MITM attacks. The pairing 454 protocol can detect such attacks and resist them, but the attackers 455 will have access to all messages exchanged before validation is 456 performed. It is important to not exchange any privacy sensitive 457 information before that validation. This includes, for example, the 458 identities of the parties or their public keys. 460 2.6. Using TLS 462 The pairing algorithms typically combine the establishment of a 463 shared secret through an [EC]DH exchange with the verification of 464 that secret through displaying and comparison of a "short 465 authentication string" (SAS). As explained in Section 2.4, the 466 secure comparison requires a "commit before disclose" mechanism. 468 We have three possible designs: (1) create a pairing algorithm from 469 scratch, specifying our own crypto exchanges; (2) use an [EC]DH 470 version of TLS to negotiate a shared secret, export the key to the 471 application as specified in [RFC5705], and implement the "commit 472 before disclose" and SAS verification as part of the pairing 473 application; or, (3) use TLS, integrate the "commit before disclose" 474 and SAS verification as TLS extensions, and export the verified key 475 to the application as specified in [RFC5705]. 477 When faced with the same choice, the designers of ZRTP [RFC6189] 478 chose to design a new protocol integrated in the general framework of 479 real time communications. We don't want to follow that path, and 480 would rather not create yet another protocol. We would need to 481 reinvent a lot of the negotiation capabilities that are part of TLS, 482 not to mention algorithm agility, post quantum, and all that sort of 483 things. It is thus pretty clear that we should use TLS. 485 It turns out that there was already an attempt to define SAS 486 extensions for TLS ([I-D.miers-tls-sas]). It is a very close match 487 to our third design option, full integration of SAS in TLS, but the 488 draft has expired, and there does not seem to be any support for the 489 SAS options in the common TLS packages. 491 In our design, we will choose the middle ground option -- use TLS for 492 [EC]DH, and implement the SAS verification as part of the pairing 493 application. This minimizes dependencies on TLS packages to the 494 availability of a key export API following [RFC5705]. We will need 495 to specify the hash algorithm used for the SAS computation and 496 validation, which carries some of the issues associated with 497 "designing our own crypto". One solution would be to use the same 498 hash algorithm negotiated by the TLS connection, but common TLS 499 packages do not not always make this algorithm identifier available 500 through standard APIs. A fallback solution is to specify a state of 501 the art keyed MAC algorithm. 503 2.7. QR codes 505 In Section 2.3.3, we reviewed a number of short range communication 506 systems that can be used to facilitate pairing. Out of these, QR 507 codes stand aside because most devices that can display a short 508 string can also display the image of a QR code, and because many 509 pairing scenarios involve cell phones equipped with cameras capable 510 of reading a QR code. 512 QR codes could be particularly useful when starting discovery. QR 513 codes can encode an alphanumeric string, which could for example 514 encode the selected name of the pairing service. This would enable 515 automatic discovery, and would be easier to use than reading the 516 random name of the day and matching it against the results of DNS-SD. 518 In addition to the instance name, a QR code could also be leveraged 519 for authentication. It could encode an SAS or even a longer 520 authentication string. Transmitting the output of a cryptographic 521 hash function or HMAC via the OOB channel would make an offline 522 combinatorial search attack infeasible and thus allow to not sent the 523 commitment discussed in Section 2.4 saving a message. Further, if a 524 single device created both QR codes for discovery and verifcation, 525 respecitvely, and the other device scans these, the users could just 526 wait while both QRs are scanned subsequently as no user interaction 527 is necessary between these two scans (but it needs a QR scanner (app) 528 that support this). This could make the process feel like a single 529 user interaction. 531 But still, from a users point of view, scanning QR codes may not be 532 more efficient than visual verification of a short string. The user 533 has to take a picture of the QR code, which is arguably not simpler 534 than just "look at the number on the screen and tell me whether it is 535 the same as yours". 537 In the case of a man-in-the-middle attack, the evaluation of the QR 538 code will fail. The "client" that took the picture will know that, 539 but the "server" will not. The user will still need to click some 540 "Cancel" button on the server, which means that the process will not 541 be completely automated. 543 3. Design of the Pairing Mechanism 545 In this section we discuss the design of pairing protocols that use 546 manually verified short authentication strings (SAS), considering 547 both security and user experience. 549 We divide pairing in three parts: discovery, agreement, and 550 authentication, detailed in the following subsections. 552 3.1. Discovery 554 The goal of the discovery phase is establishing a connection, which 555 is later used to exchange the pairing data, between the two devices 556 that are about to be paired in an IP network without any a priori 557 knowledge and without publishing any private information. In 558 accordance with TLS, we refer to the device initiating the 559 cryptographic protocol as client, and to the other device as server; 560 the server has to be discoverable by the client. 562 Granting privacy during the discovery phase without relying on a 563 priori knowledge demands another user interaction (besides the SAS 564 verification during the authentication phase). There are two 565 possible ways of realizing this user interaction depending on whether 566 QR codes are supported or not. If QR codes are supported, the 567 discovery process can be independent of DNS-SD, because QR codes 568 allow the transmission of a sufficient amount of data. Leveraging QR 569 codes, the discovery proceeds as follows. 571 1. The server displays a QR code containing the clients A and AAAA 572 resource records, and further the SRV resource record 573 corresponding to the pairing service instance. A privacy 574 preserving instance name is not necessary, because this instance 575 is never published via an unsecured network. 577 2. The client scans the QR code retrieving the necessary information 578 for establishing a connection to the server. 580 If QR codes are not supported, the discovery proceeds as follows. 582 1. The server displays its chosen instance name on its screen. 584 2. The client performs a discovery of all the "pairing" servers 585 available on the local network. This may result in the discovery 586 of several servers. 588 3. Among these available "pairing servers" the client user selects 589 the name that matches the name displayed by the server. 591 3.2. Agreement 593 Once the server has been selected, the client connects to it without 594 further user intervention. Client and server use this connection for 595 exchanging data that allows them to agree on a shared secret by using 596 a cryptographic protocol that yields an SAS. We discussed design 597 aspects of such protocols in Section 2.4. 599 3.3. Authentication 601 In the authentication phase, the users are asked to validate the 602 pairing by comparing the SASes -- typically represented by a number 603 encoded over up to 7 decimal digits. If the SASes match, each user 604 enters an agreement, for example by pressing a button labeled "OK", 605 which results in the pairing being remembered. If they do not match, 606 each user should cancel the pairing, for example by pressing a button 607 labeled "CANCEL". 609 Depending on whether QR codes are supported, the SAS may also be 610 represented as QR code. Despite the fact that using QR codes to 611 represent the authentication string renders using longer 612 authentication strings feasible, we suggest to always generate an SAS 613 during the agreement phase, because this makes realizations of the 614 agreement phase and the authentication phase independent. Devices 615 may display the "real" name of the other device alongside the SAS. 617 3.4. Intra User Pairing 619 Users can pair their own devices in secure (home) networks without 620 any interaction using a special DNS-SD pairing service. Verification 621 methods where a single user holds both devices, e.g. synchronously 622 pressing buttons on both devices a few times, are also suitable. 623 Further, a secure OOB could be established by connecting two devices 624 with an USB channel. Pairing via an USB connection is also used by 625 some Bluetooth devices, e.g. when pairing a controller with a gaming 626 console. 628 [[TODO: elaborate]] 630 3.5. Pairing Data Synchronization 632 To make it sufficient for users to pair only one of their devices to 633 one of their friends devices while still being able to engage in 634 later communication with all of this friend's devices using any of 635 the own devices, we offer the possibility to synchronize pairing data 636 among devices of the same user. Pairing data synchronization is 637 performed via a special DNS-SD service (_pdsync._tls). 639 [[TODO: elaborate]] 641 3.6. Public Authentication Keys 643 [[TODO: Should we discuss public authentication keys whose 644 fingerprints are verified during pairing?]] 646 4. Solution 648 [[TODO: elaborate on all subsections]] 650 In the proposed pairing protocol, one of the devices acts as a 651 "server", and the other acts as a "client". The server will publish 652 a "pairing service". The client will discover the service instance 653 during the discovery phase, as explained in Section 4.1. The pairing 654 service itself is specified in Section 4.2. 656 4.1. Discovery 658 The discovery uses DNS-SD [RFC6763] over mDNS [RFC6762]. The pairing 659 service is identified in DNS SD as "_pairing._tcp". When the pairing 660 service starts, the server starts publishing the chosen instance 661 name. The client will discover that name and the corresponding 662 connection parameters. 664 If QR code scanning is available as OOB channel, the discovery data 665 is directly transmitted via QR codes instead of DNS-SD over mDNS. 666 [[TODO: We should precisely specify the data layout of this QR code. 667 It could either be the wire format of the corresponding resource 668 records (which would be easier for us), or a more efficient 669 representation. If we chose the wire format, we could use a fix name 670 as instance name.]] 672 4.2. Agreement and Authentication 674 The pairing protocol is built using TLS. The following description 675 uses the presentation language defined in section 4 of [RFC5246]. 676 The protocol uses five message types, defined in the following enum: 678 enum { 679 ClientHash(1), 680 ServerRandom(2), 681 ClientRandom(3), 682 ServerSuccess(4), 683 ClientSuccess(5) 684 } PairingMessageType; 686 Devices implementing the service MUST support TLS 1.2 [RFC5246], and 687 SHOULD support TLS 1.3 as soon as it becomes available. When using 688 TLS, the client and server MUST negotiate a ciphersuite providing 689 forward secrecy (PFS), and strong encryption (256 bits symmetric 690 key). All implementations using TLS 1.2 SHOULD be able to negotiate 691 the cipher suite TLS_DH_anon_WITH_AES_256_CBC_SHA256. 693 Once the TLS connection has been established, each party extracts the 694 pairing secret S_p from the connection context per [RFC5705], using 695 the following parameters: 697 Disambiguating label string: "PAIRING SECRET" 699 Context value: empty. 701 Length value: 32 bytes (256 bits). 703 Once S_p has been obtained, the client picks a random number R_c, 704 exactly 32 bytes long. The client then selects a hash algorithm, 705 which SHOULD be the same algorithm as negotiated for building the PRF 706 in the TLS connection. If there is no suitable API to retrieve that 707 algorithm, the client MAY use SHA256 instead. The client then 708 computes the hash value H_c as: 710 H_c = HMAC_hash(S_p, R_c) 712 Where "HMAC_hash" is the HMAC function constructed with the 713 selected algorithm. 715 The client transmits the selected hash function and the computed 716 value of H_c in the Client Hash message, over the TLS connection: 718 struct { 719 PairingMessageType messageType; 720 hashAlgorithm hash; 721 uint8 hashLength; 722 opaque H_c[hashLength]; 723 } ClientHashMessage; 725 messageType Set to "ClientHash". 727 hash The code of the selected hash algorithm, per definition of 728 HashAlgorithm in section 7.4.1.1.1 of [RFC5246]. 730 hashLength The length of the hash H_c, which MUST be consistent with 731 the selected algorithm "hash". 733 H_c The value of the client hash. 735 Upon reception of this message, the server stores its value. The 736 server picks a random number R_s, exactly 32 bytes long, and 737 transmits it to the client in the server random message, over the TLS 738 connection: 740 struct { 741 PairingMessageType messageType; 742 opaque R_s[32]; 743 } ServerRandomMessage; 745 messageType Set to "ServerRandom". 747 R_s The value of the random number chosen by the server. 749 Upon reception of this message, the client discloses its own random 750 number by transmitting the client random message: 752 struct { 753 PairingMessageType messageType; 754 opaque R_c[32]; 755 } ClientRandomMessage; 757 messageType Set to "ClientRandom". 759 R_c The value of the random number chosen by the client. 761 Upon reception of this message, the server verifies that the number 762 R_c hashes to the previously received value H_c. If the number does 763 not match, the server MUST abandon the pairing attempt and abort the 764 TLS connection. 766 At this stage, both client and server can compute the short hash SAS 767 as: 769 SAS = first 20 bits of HMAC_hash(S_p, R_c + R_s) 771 Where "HMAC_hash" is the HMAC function constructed with the hash 772 algorithm selected by the client in the ClientHashMessage. 774 Both client and server display the SAS as a decimal integer, and ask 775 the user to compare the values. If the values do not match, the user 776 cancels the pairing. Otherwise, the protocol continues with the 777 exchange of names, both server and client announcing their own 778 preferred name in a Success message 780 struct { 781 PairingMessageType messageType; 782 uint8 nameLength; 783 opaque name[nameLength]; 784 } ClientSuccessMessage; 786 messageType Set to "ClientSuccess" if transmitted by the client, 787 "ServerSuccess" if by the server. 789 nameLength The length of the string encoding the selected name. 791 name The selected name of the client or the server, encoded as a 792 string of UTF8 characters. 794 After receiving these messages, client and servers can orderly close 795 the TLS connection, terminating the pairing exchange. 797 5. Security Considerations 799 We need to consider two types of attacks against a pairing system: 800 attacks that occur during the establishment of the pairing relation, 801 and attacks that occur after that establishment. 803 During the establishment of the pairing system, we are concerned with 804 privacy attacks and with MITM attacks. Privacy attacks reveal the 805 existence of a pairing between two devices, which can be used to 806 track graphs of relations. MITM attacks result in compromised 807 pairing keys. The discovery procedures specified in Section 4.1 and 808 the authentication procedures specified in Section 4.2 are 809 specifically designed to mitigate such attacks. 811 The establishment of the pairing results in the creation of a shared 812 secret. After the establishment of the pairing relation, attackers 813 who compromise one of the devices could access the shared secret. 814 This will enable them to either track or spoof the devices. To 815 mitigate such attacks, nodes MUST store the secret safely, and MUST 816 be able to quickly revoke a compromised pairing. This is however not 817 sufficient, as the compromise of the pairing key could remain 818 undetected for a long time. For further safety, nodes SHOULD assign 819 a time limit to the validity of pairings, discard the corresponding 820 keys when the time has passed, and establish new pairings. 822 6. IANA Considerations 824 This draft does not require any IANA action. 826 7. Acknowledgments 828 TODO 830 8. References 832 8.1. Normative References 834 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 835 Requirement Levels", BCP 14, RFC 2119, 836 DOI 10.17487/RFC2119, March 1997, 837 . 839 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 840 (TLS) Protocol Version 1.2", RFC 5246, 841 DOI 10.17487/RFC5246, August 2008, 842 . 844 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 845 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 846 March 2010, . 848 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 849 DOI 10.17487/RFC6762, February 2013, 850 . 852 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 853 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 854 . 856 8.2. Informative References 858 [BTLEPairing] 859 Bluetooth SIG, "Bluetooth Low Energy Security Overview", 860 2016, 861 . 864 [I-D.ietf-dnssd-privacy] 865 Huitema, C. and D. Kaiser, "Privacy Extensions for DNS- 866 SD", draft-ietf-dnssd-privacy-00 (work in progress), 867 October 2016. 869 [I-D.miers-tls-sas] 870 Miers, I., Green, M., and E. Rescorla, "Short 871 Authentication Strings for TLS", draft-miers-tls-sas-00 872 (work in progress), February 2014. 874 [KFR09] Kainda, R., Flechais, I., and A. Roscoe, "Authentication 875 protocols based on low-bandwidth unspoofable channels: a 876 comparative survey", 2009. 878 [NR11] Nguyen, L. and A. Roscoe, "Authentication protocols based 879 on low-bandwidth unspoofable channels: a comparative 880 survey", 2011. 882 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 883 Hashing for Message Authentication", RFC 2104, 884 DOI 10.17487/RFC2104, February 1997, 885 . 887 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 888 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 889 RFC 6151, DOI 10.17487/RFC6151, March 2011, 890 . 892 [RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: 893 Media Path Key Agreement for Unicast Secure RTP", 894 RFC 6189, DOI 10.17487/RFC6189, April 2011, 895 . 897 [USK11] Uzun, E., Saxena, N., and A. Kumar, ". Pairing devices for 898 social interactions: a comparative usability evaluation", 899 2009. 901 [WPS] Wi-Fi Alliance, "Wi-Fi Protected Setup", 2016, 902 . 905 [XKCD936] Munroe, R., "XKCD: Password Strength", 2011, 906 . 908 Authors' Addresses 910 Christian Huitema 911 Friday Harbor, WA 98250 912 U.S.A. 914 Email: huitema@huitema.net 916 Daniel Kaiser 917 University of Konstanz 918 Konstanz 78457 919 Germany 921 Email: daniel.kaiser@uni-konstanz.de