idnits 2.17.1 draft-kaiser-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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 20 pages 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 (September 27, 2016) is 2766 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 742 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-02) exists of draft-huitema-dnssd-privacy-01 Summary: 1 error (**), 0 flaws (~~), 3 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 Microsoft 4 Intended status: Standards Track D. Kaiser 5 Expires: March 31, 2017 University of Konstanz 6 September 27, 2016 8 Device Pairing Using Short Authentication Strings 9 draft-kaiser-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 March 31, 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 . . . . . . . . . . . . . . . . . . . . . . . . 12 76 3.2. Agreement . . . . . . . . . . . . . . . . . . . . . . . . 13 77 3.2.1. Length and syntax of the SAS . . . . . . . . . . . . 13 78 3.3. Authentication . . . . . . . . . . . . . . . . . . . . . 14 79 3.4. Intra User Pairing . . . . . . . . . . . . . . . . . . . 14 80 3.5. Pairing Data Synchronization . . . . . . . . . . . . . . 14 81 3.6. Public Authentication Keys . . . . . . . . . . . . . . . 14 82 4. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 4.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 15 84 4.2. Agreement and Authentication . . . . . . . . . . . . . . 15 85 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 87 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 88 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 89 8.1. Normative References . . . . . . . . . . . . . . . . . . 18 90 8.2. Informative References . . . . . . . . . . . . . . . . . 18 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 93 1. Introduction 95 To engage in secure and privacy preserving communication, hosts need 96 to differentiate between authorized peers, which must both know about 97 the host's presence and be able to decrypt messages sent by the host, 98 and other peers, which must not be able to decrypt the host's 99 messages and ideally should not be aware of the host's presence. The 100 necessary relationship between host and peer can be established by a 101 centralized service, e.g. a certificate authority, by a web of trust, 102 e.g. PGP, or -- without using global identities -- by device 103 pairing. 105 This document proposes a device pairing mechanism that provides human 106 operated devices with pairwise authenticated secrets, allowing mutual 107 automatic re-discovery at any later point in time along with mutual 108 private authentication. We especially care about privacy and user- 109 friendliness. 111 The proposed pairing mechanism consists of three steps needed to 112 establish a relationship between a host and a peer: 114 1. Discovery of the peer device. The host needs a means to discover 115 network parameters necessary to establish a connection to the 116 peer. During this discovery process, neither the host nor the 117 peer must disclose its presence. 119 2. Agreeing on pairing data. The devices have to agree on pairing 120 data, which can be used by both parties at any later point in 121 time to generate identifiers for re-discovery and to prove the 122 authenticity of the pairing. The pairing data can e.g. be a 123 shared secret agreed upon via a Diffie-Hellman key exchange. 125 3. Authenticate pairing data. Since in most cases the messages 126 necessary to agree upon pairing data are send over an insecure 127 channel, means that guarantee the authenticity of these messages 128 are necessary; otherwise the pairing data is in turn not suited 129 as a means for a later proof of authenticity. For the proposed 130 pairing mechanism we use manual interaction involving an SAS 131 (short authentication string) to proof the authenticity of the 132 pairing data. 134 1.1. Requirements 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC2119]. 140 2. Problem Statement and Requirements 142 The general pairing requirement is easy to state: establish a trust 143 relation between two entities in a secure manner. But details 144 matter, and in this section we explore the detailed requirements that 145 guide our design. 147 2.1. Secure Pairing Over Internet Connections 149 Many pairing protocols have been already developed, in particular for 150 the pairing of devices over specific wireless networks. For example, 151 the current BlueTooth specifications include a pairing protocol that 152 has evolved over several revisions towards better security and 153 usability [BTLEPairing]. The Wi-Fi Alliance defined the Wi-Fi 154 Protected Setup process to ease the setup of security-enabled Wi-Fi 155 networks in home and small office environments [WPS]. Other wireless 156 standards have defined or are defining similar protocols, tailored to 157 specific technologies. 159 This specification defines a pairing protocol that is independent of 160 the underlying technology. We simply make the hypothesis that the 161 two parties engaged in the pairing can discover each other and can 162 exchange establish connections over IP. 164 TODO: discuss the actual goal. Is it a shared secret or a public 165 key? 167 2.2. Identity Assurance 169 The parties in the pairing must be able to identify each other. To 170 put it simply, if Alice believes that she is establishing a pairing 171 with Bob, she must somehow ensure that the pairing is happening with 172 Bob, and not with some interloper like Eve or Nessie. Providing this 173 assurance requires care at the user interface (UI), and also in the 174 design of the protocol. 176 Consider for example an attack in which Eve tricks Alice into 177 establishing a pairing, and then pretends to be Bob. Alice must be 178 able to discover that something is wrong, and refuse to establish a 179 pairing. At a minimum, the parties engaged in the pairing must be 180 able to verify the identity under which the pairing is established. 182 2.3. Adequate User Interface 184 Because the pairing protocol is executed without prior knowledge, it 185 is typically vulnerable to "Man-in-the-middle" attacks. While Alice 186 is trying to establish a pairing with Bob, Eve positions herself in 187 the middle. Instead of getting a pairing between Alice and Bob, both 188 Alice and Bob get paired with Eve. This requires specific features in 189 the protocol to detect man-in-the-middle attacks, and if possible 190 resist them. The reference [NR11] analyzes the various proposals to 191 solve this problem, and in this document, we present a layman 192 description of these issues in Section 2.4. The various protocols 193 proposed in the literature impose diverse constraints at the UI 194 interface, which we will review here. 196 2.3.1. Short PIN Proved Inadequate 198 The initial Bluetooth pairing protocol relied on a four digit PIN, 199 displayed by one of the devices to be paired. The user would read 200 that PIN and provide it to the other device. The PIN would then be 201 used in a Password Authenticated Key Exchange. Wi-Fi Protected Setup 202 [WPS] offered a similar option. There were various attacks against 203 the actual protocol; some of the problems were caused by issues in 204 the protocol, but most were tied to the usage of short PINs. 206 In the reference implementation, the PIN is picked at random by the 207 paired device before the beginning of the exchange. But this 208 requires that the paired device is capable of generating and 209 displaying a four digit number. It turns out that many devices 210 cannot do that. For example, an audio headset does not have any 211 display capability. These limited devices ended up using static 212 PINs, with fixed values like "0000" or "0001". 214 Even when the paired device could display a random PIN, that PIN will 215 have to be copied by the user on the pairing device. It turns out 216 that users do not like copying long series of numbers, and the 217 usability thus dictated that the PINs be short -- four digits in 218 practice. But there is only so much assurance as can be derived from 219 a four digit key. 221 It is interesting to note that the latest revisions of the Bluetooth 222 Pairing protocol [BTLEPairing] do not include the short PIN option 223 anymore. The PIN entry methods have been superseded by the simple 224 "just works" method for devices without displays, and by a procedure 225 based on an SAS (short authentication string) when displays are 226 available. 228 A further problem with these PIN based approaches is that -- in 229 contrast to SASes -- the PIN is a secret instrumental in the security 230 algorithm. To guarantee security, this PIN had to be transmitted via 231 a secure out of band channel. 233 2.3.2. Push Buttons Just Work, But Are Insecure 235 Some devices are unable to input or display any code. The industry 236 more or less converged on a "push button" solution. When the button 237 is pushed, devices enter a "pairing" mode, during which they will 238 accept a pairing request from whatever other device connects to them. 240 The Bluetooth Pairing protocol [BTLEPairing] denotes that as the 241 "just works" method. It does indeed work, and if the pairing 242 succeeds the devices will later be able to use the pairing keys to 243 authenticate connections. However, the procedure does not provide 244 any protection against MITM attacks during the pairing process. The 245 only protection is that pushing the button will only allow pairing 246 for a limited time, thus limiting the opportunities of attacks. 248 As we set up to define a pairing protocol with a broad set of 249 applications, we cannot limit ourselves to an insecure "push button" 250 method. But we probably need to allow for a mode of operation that 251 works for input-limited and display limited devices. 253 2.3.3. Short Range Communication 255 There have been several attempts to define pairing protocols that use 256 "secure channels." Most of them are based on short range 257 communication systems, where the short range limits the feasibility 258 for attackers to access the channels. Example of such limited 259 systems include for example: 261 o QR codes, displayed on the screen of one device, and read by the 262 camera of the other device. 264 o Near Field Communication (NFC) systems, which provides wireless 265 communication with a very short range. 267 o Sound systems, in which one systems emits a sequence of sounds or 268 ultrasounds that is picked by the microphone of the other system. 270 A common problem with these solutions is that they require special 271 capabilities that may not be present in every device. Another 272 problem is that they are often one-way channels. Yet another problem 273 is that the side channel is not necessarily secret. QR codes could 274 be read by third parties. Powerful radios antennas might be able to 275 interfere with NFC. Sensitive microphones might pick the sounds. We 276 will discuss the specific case of QR codes in Section 2.7. 278 2.3.4. Short Authentication Strings 280 The evolving pairing protocols seem to converge towards a "display 281 and compare" method. This is in line with academic studies, such as 282 [KFR09] or [USK11]. This points to a very simple scenario: 284 1. Alice initiates pairing 286 2. Bob selects Alice's device from a list. 288 3. Alice and Bob compare displayed strings that represent a 289 fingerprint of the key. 291 4. If the strings match, Alice and Bob accept the pairing. 293 Most existing pairing protocols display the fingerprint of the key as 294 a 6 or 7 digit numbers. Usability studies show that gives good 295 results, with little risk that users mistakenly accept two different 296 numbers as matching. However, the authors of [USK11] found that 297 people had more success comparing computer generated sentences than 298 comparing numbers. This is in line with the argument in [XKCD936] to 299 use sequences of randomly chosen common words as passwords. On the 300 other hand, standardizing strings is more complicated than 301 standardizing numbers. We would need to specify a list of common 302 words, and the process to go from a binary fingerprint to a set of 303 words. We would need to be concerned with internationalization 304 issues, such as using different lists of words in German and in 305 English. This could require negotiation of word lists or languages 306 inside the pairing protocols. 308 In contrast, numbers are easy to specify, as in "take a 20 bit number 309 and display it as an integer using decimal notation." 311 2.4. Resist cryptographic attacks 313 It is tempting to believe that once two peers are connected, they 314 could create a secret with a few simple steps, such as for example 315 exchange two nonces, hash the concatenation of this nonces with the 316 shared secret, display a short authentication string composed of a 317 short version of that hash on each device, and verify that the two 318 values match. The sequence of messages would be something like: 320 Alice Bob 321 g^xA --> 322 <-- g^xB 323 nA --> 324 <-- nB 325 Computes Computes 326 s = g^xAxB s = g^xAxB 327 h = hash(s|nA|nB) h = hash(s|nA|nB) 328 Displays short Displays short 329 version of h version of h 331 If the two short hashes match, Alice and Bob are supposedly assured 332 that they have computed the same secret, but there is a problem. The 333 exchange may not deter a smart attacker in the middle. Let's redraw 334 the same message flow, this time involving Eve: 336 Alice Eve Bob 337 g^xA --> 338 g^xA'--> 339 <-- g^xB 340 <--g^xB' 341 nA --> 342 nA --> 343 <-- nB 344 Picks nB' 345 smartly 346 <--nB' 347 Computes Computes 348 s' = g^xAxB' s" = g^xA'xB 349 h' = hash(s|nA|nB') h" = hash(s"|nA|nB) 350 Displays short Displays short 351 version of h' version of h" 353 Let's now assumes that to pick the nonce nB' smartly, Eve runs the 354 following algorithm: 356 s' = g^xAxB' 357 s" = g^xA'xB 358 repeat 359 pick a new version of nB' 360 h' = hash(s|nA|nB') 361 h" = hash(s"|nA|nB) 362 until the short version of h' 363 matches the short version of h" 365 Of course, running this algorithm will require in theory as many 366 iterations as the possible values of the short hash. But hash 367 algorithms are fast, and it is possible to try millions of values in 368 less than a second. If the short string is made up of fewer than 6 369 digits, Eve will find a matching nonce quickly, and Alice and Bob 370 will hardly notice the delay. Even if the matching string is as long 371 as 8 letters, Eve will probably find a value where the short versions 372 of h' and h" are close enough, e.g. start and end with the same two 373 or three letters. Alice and Bob may well be fooled. 375 The classic solution to such problems is to "commit" a possible 376 attacker to a nonce before sending it. This commitment can be 377 realized by a hash. In the modified exchange, Alice and Bob exchange 378 a secure hash of their nonces before sending the actual value: 380 Alice Bob 381 g^xA --> 382 <-- g^xB 384 Computes Computes 385 s = g^xAxB s = g^xAxB 386 h_a = hash(s|nA) --> 387 <-- nB 388 nA --> 389 verifies h_a == hash(s|nA) 390 Computes Computes 391 h = hash(s|nA|nB) h = hash(s|nA|nB) 392 Displays short Displays short 393 version of h version of h 395 Alice will only disclose nA after having confirmation from Bob that 396 hash(nA) has been received. At that point, Eve has a problem. She 397 can still forge the values of the nonces but she needs to pick the 398 nonce nA' before the actual value of nA has been disclosed. On first 399 sight, it seems that once she has committed by sending hash(nA'), it 400 will be impossible to send anything but the nA'. Eve would still 401 have a random chance of fooling Alice and Bob, but it will be a very 402 small chance: one in million if the short authentication string is 403 made of 6 digits, even fewer if that string is longer. 405 Nguyen et al. [NR11] survey these protocols and compare them with 406 respect to the amount of necessary user interaction and the 407 computation time needed on the devices. The authors state that such 408 a protocol is optimal with respect user interaction if it suffices 409 for users to verify a single b-bit SAS while having a one-shot attack 410 success probability of 2^-b. Further, n consecutive attacks on the 411 protocol must not have a better success probability then n one-shot 412 attacks. 414 There is still a theoretical problem, if Eve has somehow managed to 415 "crack" the hash function. We build some "defense in depth" by some 416 simple measures. In the design presented above, the hash "h_a" 417 depends of the shared secret "s", which acts as a "salt" and reduces 418 the effectiveness of potential attacks based on pre-computed 419 catalogs. For simplicity, the design used a simple concatenation 420 mechanism, but we could instead use a keyed-hash message 421 authentication code (HMAC, [RFC2104], [RFC6151]), using the shared 422 secret as a key, since the HMAC construct has proven very robust over 423 time. Then, we can constrain the size of the random numbers to be 424 exactly the same as the output of the hash function. Hash attacks 425 often require padding the input string with arbitrary data; 426 restraining the size limits the likelyhood of such padding. 428 2.5. Privacy Requirements 430 Pairing exposes a relation between several devices and their owners. 431 Adversaries may attempt to collect this information, for example in 432 an attempt to track devices, their owners, or their "social graph." 433 It is often argued that pairing could be performed in a safe place, 434 from which adversaries are assumed absent, but experience shows that 435 such assumptions are often misguided. It is much safer to 436 acknowledge the privacy issues and design the pairing process 437 accordingly. 439 In order to start the pairing process, devices must first discover 440 each other. We do not have the option of using the private discovery 441 protocol [I-D.huitema-dnssd-privacy] since the privacy of that 442 protocol depends on the pre-existing pairing. In the simplest 443 design, one of the devices will announce a "friendly name" using DNS- 444 SD. Adversaries could monitor the discovery protocol, and record 445 that name. An alternative would be for one device to announce a 446 random name, and communicate it to the other device via some private 447 channel. There is an obvious tradeoff here: friendly names are 448 easier to use but less private than random names. We anticipate that 449 different users will choose different tradeoffs, for example using 450 friendly names if they assume that the environment is "safe," and 451 using random names in public places. 453 During the pairing process, the two devices establish a connection 454 and validate a pairing secret. As discussed in Section 2.3, we have 455 to assume that adversaries can mount MITM attacks. The pairing 456 protocol can detect such attacks and resist them, but the attackers 457 will have access to all messages exchanged before validation is 458 performed. It is important to not exchange any privacy sensitive 459 information before that validation. This includes, for example, the 460 identities of the parties or their public keys. 462 2.6. Using TLS 464 The pairing algorithms typically combine the establishment of a 465 shared secret through an [EC]DH exchange, with the verification of 466 that secret through displaying and comparison of a "short 467 authentication string" (SAS). As explained in Section 2.4, the 468 secure comparison requires a "commit before disclose" mechanism. 470 We have three possible designs: create a pairing algorithm from 471 scratch, specifying our own crypto exchanges; use an [EC]DH version 472 of TLS to negotiate a shared secret, export the key to the 473 application as specified in [RFC5705], and implement the "commit 474 before disclose" and SAS verification as part of the pairing 475 application; or, use TLS, integrate the "commit before disclose" and 476 SAS verification as TLS extensions, and export the verified key to 477 the application as specified in [RFC5705]. 479 Creating an algorithm from scratch is probably a bad idea. We would 480 need to reinvent a lot of the negotiation capabilities that are part 481 of TLS, not to mention algorithm agility, post quantum, and all that 482 sort of things. It is thus pretty clear that we should use TLS. 484 It turns out that there was already an attempt to define SAS 485 extensions for TLS ([I-D.miers-tls-sas]). It is a very close match 486 to our third design option, full integration of SAS in TLS, but the 487 draft has expired, and there does not seem to be any support for the 488 SAS options in the common TLS packages. 490 In our design, we will choose the middle ground option -- use TLS for 491 [EC]DH, and implement the SAS verification as part of the pairing 492 application. This minimizes dependencies on TLS packages to the 493 availability of a key export API following [RFC5705]. We will need 494 to specify the hash algorithm used for the SAS computation and 495 validation, which carries some of the issues associated with 496 "designing our own crypto." One solution would be to use the same 497 hash algorithm negotiated by the TLS connection, but common TLS 498 packages do not not always make this algorithm identifier available 499 through standard APIs. A fallback solution is to specify a state of 500 the art keyed MAC algorithm. 502 2.7. QR codes 504 In Section 2.3.3, we reviewed a number of short range communication 505 systems that can be used to facilitate pairing. Out of these, QR 506 codes stand aside because most devices that can display a short 507 string can also display the image of a QR code, and because many 508 pairing scenarios involve cell phones equipped with cameras capable 509 of reading a QR code. 511 QR codes could be particularly useful when starting discovery. QR 512 codes can encode an alphanumeric string, which could for example 513 encode the selected name of the pairing service. This would enable 514 automatic discovery, and would be easier to use than reading the 515 random name of the day and matching it against the results of DNS-SD. 517 In addition to the instance name, a QR code could also be leveraged 518 for authentication. It could encode an SAS or even a longer 519 authentication string. Transmitting the output of a cryptographic 520 hash function or HMAC via the OOB channel would make an offline 521 combinatorial search attack infeasible and thus allow to not sent the 522 commitment discussed in Section 2.4 saving a message. Further, if a 523 single device created both QR codes for discovery and verification, 524 respectively, and the other device scans these, the users could just 525 wait while both QRs are scanned subsequently as no user interaction 526 is necessary between these two scans (but it needs a QR scanner (app) 527 that support this). This could make the process feel like a single 528 user interaction. 530 But still, from a users point of view, scanning QR codes may not be 531 more efficient than visual verification of a short string. The user 532 has to take a picture of the QR code, which is arguably not simpler 533 than just "look at the number on the screen and tell me whether it is 534 the same as yours". 536 In the case of a man-in-the-middle attack, the evaluation of the QR 537 code will fail. The "client" that took the picture will know that, 538 but the "server" will not. The user will still need to click some 539 "Cancel" button on the server, which means that the process will not 540 be completely automated. 542 3. Design of the Pairing Mechanism 544 In this section we discuss the design of pairing protocols that use 545 manually verified short authentication strings (SAS), focusing on the 546 user experience. We will make provision for the optional usage of QR 547 codes. 549 We divide pairing in three parts: discovery, agreement, and 550 authentication, detailed in the following subsections. 552 3.1. Discovery 554 During the discovery phase, the client will find the server. There 555 are two possible experiences depending of whether QR codes are 556 supported or not. If QR codes are supported, the discovery proceeds 557 as follow: 559 1. The server displays a QR code containing the its chosen instance 560 name. 562 2. The client scans the QR code, and discovery is performed 563 automatically, without further client interaction. 565 If QR codes are not supported, the discovery will require some user 566 interaction: 568 1. The server displays its chosen instance name on its screen. 570 2. The client performs a discovery of all the "pairing" servers 571 available on the local network. This may result in the discovery 572 of several servers. 574 3. The client user selects from the list of available servers the 575 instance name that matches the name displayed by the server. 577 3.2. Agreement 579 Once the server has been selected, the client connects to it without 580 further user intervention. Client and server exchange the required 581 messages, and both display an SAS, normally a number encoded over up 582 to 7 decimal digits. 584 The users are asked to validate the pairing by comparing the SASes. 585 If they match, each user enters an agreement, for example by pressing 586 a button labeled "OK". If they do not match, each user should cancel 587 the pairing, for example by pressing a button labeled "CANCEL". 589 3.2.1. Length and syntax of the SAS 591 The length of the SAS is a compromise between the capacity to resit 592 MITM attacks and a the burden placed on the users performing the 593 comparison. We chose the number 7 based on a "well known" psychology 594 result that "the longest sequence a normal person can recall on the 595 fly contains about seven items" [Number7]. We chose decimal numbers 596 because they are a least common denominator, and to not require 597 translations in differnt languages. 599 A simple way to obtain a 7 digit is to print a binary number 20 to 23 600 bits long. In the design, we will use 20 bits because 7 is in fact 601 an upper limit. 20 bits print on 7 digits about 5% of the time, on 6 602 digits about 86% of the time, and on 5 digits or fewer less than 10% 603 of the time. 605 3.3. Authentication 607 Once the agreement has been performed, each device displays the 608 "real" name of the other device, as exchanged through the pairing 609 protocol. Each user verifies that the name matches what they expect. 610 If the names are validated, each user approves the pairing, which 611 will then be remembered. 613 3.4. Intra User Pairing 615 Users can pair their own devices in secure (home) networks without 616 any interaction using a special DNS-SD pairing service. Verification 617 methods where a single user holds both devices, e.g. synchronously 618 pressing buttons on both devices a few times, are also suitable. 619 Further, a secure OOB could be established by connecting two devices 620 with an USB channel. Pairing via an USB connection is also used by 621 some Bluetooth devices, e.g. when pairing a controller with a gaming 622 console. 624 [[TODO: elaborate]] 626 3.5. Pairing Data Synchronization 628 To make it sufficient for users to pair only one of their devices to 629 one of their friends devices while still being able to engage in 630 later communication with all of this friend's devices using any of 631 the own devices, we offer the possibility to synchronize pairing data 632 among devices of the same user. Pairing data synchronization is 633 performed via a special DNS-SD service (_pdsync._tls). 635 [[TODO: elaborate]] 637 3.6. Public Authentication Keys 639 [[TODO: Should we discuss public authentication keys whose 640 fingerprints are verified during pairing?]] 642 4. Solution 644 [[TODO: elaborate on all subsections]] 646 In the proposed pairing protocol, one of the devices acts as a 647 "server", and the other acts as a "client". The server will publish 648 a "pairing service". The client will discover the service instance 649 during the discovery phase, as explained in Section 4.1. The pairing 650 service itself is specified in Section 4.2. 652 4.1. Discovery 654 The discovery uses DNS-SD [RFC6763] over mDNS [RFC6762]. The pairing 655 service is identified in DNS SD as "_pairing._tcp". 657 When the pairing service starts, the server starts publishing the 658 chosen instance name. The client will discover that name and the 659 corresponding connection parameters. 661 4.2. Agreement and Authentication 663 The pairing protocol is built using TLS. The following description 664 uses the presentation language defined in section 4 of [RFC5246]. 665 The protocol uses five message types, defined in the following enum: 667 enum { 668 ClientHash(1), 669 ServerRandom(2), 670 ClientRandom(3), 671 ServerSuccess(4), 672 ClientSuccess(5) 673 } PairingMessageType; 675 Devices implementing the service MUST support TLS 1.2 [RFC5246], and 676 SHOULD support TLS 1.3 as soon as it becomes available. When using 677 TLS, the client and server MUST negotiate a ciphersuite providing 678 forward secrecy (PFS), and strong encryption (256 bits symmetric 679 key). All implementations using TLS 1.2 SHOULD be able to negotiate 680 the cipher suite TLS_DH_anon_WITH_AES_256_CBC_SHA256. 682 Once the TLS connection has been established, each party extracts the 683 pairing secret S_p from the connection context per [RFC5705], using 684 the following parameters: 686 Disambiguating label string: "PAIRING SECRET" 688 Context value: empty. 690 Length value: 32 bytes (256 bits). 692 Once S_p has been obtained, the client picks a random number R_c, 693 exactly 32 bytes long. The client then selects a hash algorithm, 694 which SHOULD be the same algorithm as negotiated for building the PRF 695 in the TLS connection. If there is no suitable API to retrieve that 696 algorithm, the client MAY use SHA256 instead. The client then 697 computes the hash value H_c as: 699 H_c = HMAC_hash(S_p, R_c) 700 Where "HMAC_hash" is the HMAC function constructed with the 701 selected algorithm. 703 The client transmits the selected hash function and the computed 704 value of H_c in the Client Hash message, over the TLS connection: 706 struct { 707 PairingMessageType messageType; 708 hashAlgorithm hash; 709 uint8 hashLength; 710 opaque H_c[hashLength]; 711 } ClientHashMessage; 713 messageType Set to "ClientHash". 715 hash The code of the selected hash algorithm, per definition of 716 HashAlgorithm in section 7.4.1.1.1 of [RFC5246]. 718 hashLength The length of the hash H_c, which MUST be consistent with 719 the selected algorithm "hash". 721 H_c The value of the client hash. 723 Upon reception of this message, the server stores its value. The 724 server picks a random number R_s, exactly 32 bytes long, and 725 transmits it to the client in the server hash message, over the TLS 726 connection: 728 struct { 729 PairingMessageType messageType; 730 opaque R_s[32]; 731 } ServerRandomMessage; 733 messageType Set to "ServerRandom". 735 R_s The value of the random number chosen by the server. 737 Upon reception of this message, the client discloses its own random 738 number by transmitting client random message: 740 struct { 741 PairingMessageType messageType; 742 opaque R_c[32]; 743 } ClientRandomMessage; 745 messageType Set to "ClientRandom". 747 R_c The value of the random number chosen by the client. 749 Upon reception of this message, the server verifies that the number 750 R_c hashes to the previously received value H_c. If the number does 751 not match, the server MUST abandon the pairing attempt and abort the 752 TLS connection. 754 At this stage, both client and server can compute the short hash SAS 755 as: 757 SAS = first 20 bits of HMAC_hash(S_p, R_c + R_s) 759 Where "HMAC_hash" is the HMAC function constructed with the hash 760 algorithm selected by the client in the ClientHashMessage. 762 Both client and server display the 20 bit value as a decimal integer, 763 and ask the user to compare the values. If the values do not match, 764 the user cancels the pairing. Otherwise, the protocol continues with 765 the exchange of names, both server and client announcing their own 766 preferred name in a Success message 768 struct { 769 PairingMessageType messageType; 770 uint8 nameLength; 771 opaque name[nameLength]; 772 } ClientSuccessMessage; 774 messageType Set to "ClientSuccess" if transmitted by the client, 775 "ServerSuccess" if by the server. 777 nameLength The length of the string encoding the selected name. 779 name The selected name of the client or the server, encoded as a 780 string of UTF8 characters. 782 After receiving these messages, client and servers can orderly close 783 the TLS connection, terminating the pairing exchange. 785 5. Security Considerations 787 [[TODO: elaborate]] 789 There are a variety of attacks against pairing systems. They may 790 result in compromised pairing keys. 792 To mitigate such attacks, nodes MUST be able to quickly revoke a 793 compromised pairing. This is however not sufficient, as the 794 compromise of the pairing key could remain undetected for a long 795 time. For further safety, nodes SHOULD assign a time limit to the 796 validity of pairings, discard the corresponding keys when the time 797 has passed, and establish new pairings. 799 The requirement of limiting the Time-To-Live of a pairing can raise 800 doubts about the usability of the protocol. The usability issues 801 would be mitigated if the initial pairing provided both a shared 802 secret and the means to renew that secret over time, e.g. using 803 authenticated public keys. 805 6. IANA Considerations 807 This draft does not require any IANA action. 809 7. Acknowledgments 811 TODO 813 8. References 815 8.1. Normative References 817 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 818 Requirement Levels", BCP 14, RFC 2119, 819 DOI 10.17487/RFC2119, March 1997, 820 . 822 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 823 (TLS) Protocol Version 1.2", RFC 5246, 824 DOI 10.17487/RFC5246, August 2008, 825 . 827 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 828 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 829 March 2010, . 831 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 832 DOI 10.17487/RFC6762, February 2013, 833 . 835 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 836 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 837 . 839 8.2. Informative References 841 [BTLEPairing] 842 Bluetooth SIG, "Bluetooth Low Energy Security Overview", 843 2016, 844 . 847 [I-D.huitema-dnssd-privacy] 848 Huitema, C. and D. Kaiser, "Privacy Extensions for DNS- 849 SD", draft-huitema-dnssd-privacy-01 (work in progress), 850 June 2016. 852 [I-D.miers-tls-sas] 853 Miers, I., Green, M., and E. Rescorla, "Short 854 Authentication Strings for TLS", draft-miers-tls-sas-00 855 (work in progress), February 2014. 857 [KFR09] Kainda, R., Flechais, I., and A. Roscoe, "Authentication 858 protocols based on low-bandwidth unspoofable channels: a 859 comparative survey", 2009. 861 [NR11] Nguyen, L. and A. Roscoe, "Authentication protocols based 862 on low-bandwidth unspoofable channels: a comparative 863 survey", 2011. 865 [Number7] Miller, G., "The magical number seven, plus or minus two: 866 Some limits on our capacity for processing information", 867 1956, . 869 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 870 Hashing for Message Authentication", RFC 2104, 871 DOI 10.17487/RFC2104, February 1997, 872 . 874 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 875 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 876 RFC 6151, DOI 10.17487/RFC6151, March 2011, 877 . 879 [USK11] Uzun, E., Saxena, N., and A. Kumar, ". Pairing devices for 880 social interactions: a comparative usability evaluation", 881 2009. 883 [WPS] Wi-Fi Alliance, "Wi-Fi Protected Setup", 2016, 884 . 887 [XKCD936] Munroe, R., "XKCD: Password Strength", 2011, 888 . 890 Authors' Addresses 892 Christian Huitema 893 Microsoft 894 Redmond, WA 98052 895 U.S.A. 897 Email: huitema@huitema.net 899 Daniel Kaiser 900 University of Konstanz 901 Konstanz 78457 902 Germany 904 Email: daniel.kaiser@uni-konstanz.de