idnits 2.17.1 draft-ietf-dnssd-pairing-05.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 15, 2018) is 2013 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 317 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-02) exists of draft-ietf-dnssd-pairing-info-01 == 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: 1 error (**), 0 flaws (~~), 4 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 Private Octopus Inc. 4 Intended status: Standards Track D. Kaiser 5 Expires: April 18, 2019 October 15, 2018 7 Device Pairing Using Short Authentication Strings 8 draft-ietf-dnssd-pairing-05 10 Abstract 12 This document proposes a device pairing mechanism that establishes a 13 relation between two devices by agreeing on a secret and manually 14 verifying the secret's authenticity using an SAS (short 15 authentication string). Pairing has to be performed only once per 16 pair of devices, as for a re-discovery at any later point in time, 17 the exchanged secret can be used for mutual authentication. 19 The proposed pairing method is suited for each application area where 20 human operated devices need to establish a relation that allows 21 configurationless and privacy preserving re-discovery at any later 22 point in time. Since privacy preserving applications are the main 23 suitors, we especially care about privacy. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 18, 2019. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 61 1.2. Document Organization . . . . . . . . . . . . . . . . . . 4 62 2. Protocol Specification . . . . . . . . . . . . . . . . . . . 4 63 2.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.2. Agreement on a Shared Secret . . . . . . . . . . . . . . 5 65 2.3. Authentication . . . . . . . . . . . . . . . . . . . . . 6 66 3. Optional Use of QR Codes . . . . . . . . . . . . . . . . . . 8 67 3.1. Discovery Using QR Codes . . . . . . . . . . . . . . . . 8 68 3.2. Agreement with QR Codes . . . . . . . . . . . . . . . . . 9 69 3.3. Authentication with QR Codes . . . . . . . . . . . . . . 9 70 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 72 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 75 7.2. Informative References . . . . . . . . . . . . . . . . . 11 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 78 1. Introduction 80 To engage in secure and privacy preserving communication, hosts need 81 to differentiate between authorized peers, which must both know about 82 the host's presence and be able to decrypt messages sent by the host, 83 and other peers, which must not be able to decrypt the host's 84 messages and ideally should not obtain information that could be used 85 to identify the host. The necessary relation between host and peer 86 can be established by a centralized service, e.g. a certificate 87 authority, by a web of trust, e.g. PGP, or -- without using global 88 identities -- by device pairing. 90 This document proposes a device pairing mechanism that provides human 91 operated devices with pairwise authenticated secrets, allowing mutual 92 automatic re-discovery at any later point in time along with mutual 93 private authentication. We especially care about privacy and user- 94 friendliness. This pairing system can provide the pairing secrets 95 used in DNSSD Privacy Extensions [I-D.ietf-dnssd-privacy]. 97 The proposed pairing mechanism consists of three steps needed to 98 establish a relationship between a host and a peer: 100 1. Discovering the peer device. The host needs a means to discover 101 network parameters necessary to establish a connection to the 102 peer. During this discovery process, neither the host nor the 103 peer must disclose its presence. 105 2. Agreeing on pairing data. The devices have to agree on pairing 106 data, which can be used by both parties at any later point in 107 time to generate identifiers for re-discovery and to prove the 108 authenticity of the pairing. The pairing data can e.g. be a 109 shared secret agreed upon via a Diffie-Hellman key exchange. 111 3. Authenticating pairing data. Since in most cases the messages 112 necessary to agree upon pairing data are send over an insecure 113 channel, means that guarantee the authenticity of these messages 114 are necessary; otherwise the pairing data is in turn not suited 115 as a means for a later proof of authenticity. For the proposed 116 pairing mechanism we use manual authentication involving an SAS 117 (short authentication string) to proof the authenticity of the 118 pairing data. 120 The design of this protocol is based on the analysis of pairing 121 protocols issues presented in [I-D.ietf-dnssd-pairing-info] and in 122 [K17]. 124 Many pairing scenarios involve cell phones equipped with cameras 125 capable of reading a QR code. In these scenarios, scanning QR codes 126 might be more user friendly than selecting names or reading short 127 authentication strings from on screen menus. An optional use of QR 128 codes in pairing protocols is presented is Section 3. 130 DNSSD privacy requirements are analyzed in [I-D.ietf-dnssd-prireq] 131 and scaling considerations are reviewed in 132 [I-D.ietf-dnssd-privacyscaling]. Further work on these two drafts 133 may lead to reviewing the mechanism proposed here. 135 1.1. Requirements 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119]. 141 1.2. Document Organization 143 NOTE TO RFC EDITOR: remove or rewrite this section before 144 publication. 146 The original version of this document was organized in two parts. 147 The first part presented the pairing need, the list of requirements 148 that shall be met. This first part was informational in nature. The 149 second part composed the actual specification of the protocol. 151 In his early review, Steve Kent observed that the style of the first 152 part seems inappropriate for a standards track document, and 153 suggested that the two parts should be split into two documents, the 154 first part becoming an informational document, and the second 155 focusing on standard track specification of the protocol, making 156 reference to the informational document as appropriate. 158 The DNS-SD working group approved this split during its meeting in 159 Prague in July 2017. This version of the document implements the 160 split, only retaining the specification part. 162 2. Protocol Specification 164 In the proposed pairing protocol, we will consider the device that 165 initiates the pairing as the "client" and the device that responds as 166 the "server". The server will publish a "pairing service". The 167 client will discover the service instance during the discovery phase, 168 as explained in Section 2.1. The pairing service itself is specified 169 in Section 2.3. 171 We divide pairing in three parts: discovery, agreement, and 172 authentication, detailed in the following subsections. 174 2.1. Discovery 176 The goal of the discovery phase is establishing a connection, which 177 is later used to exchange the pairing data between the two devices 178 that are about to be paired in an IP network without any prior 179 knowledge and without publishing any private information. 181 When the pairing service starts, the server will advertise the 182 pairing service according to DNS-SD [RFC6763] over mDNS [RFC6762]. 183 In conformance with DNS-SD, the service is described by an SRV record 184 and by and empty TXT record. These records will be organized as 185 follows: 187 1. The pairing service is identified in DNS-SD as "_pairing._tcp". 189 2. The instance name will be a text chosen by the server. It MAY be 190 a random string if the server does not want to advertise its 191 identity in the local environment, or the user friendly name of 192 the server in other cases. 194 3. The priority and weight fields of the SRV record SHOULD be set 195 according to [RFC6763]. 197 4. The host name MUST be set to the host name advertised by the 198 server in mDNS. The server MAY use a randomized host name as 199 explained in [I-D.ietf-dnssd-privacy], provided that this name is 200 properly published in mDNS. 202 5. The port number MUST be set to the number at which the server is 203 listening for the pairing service. This port number SHOULD be 204 randomly picked by the server. 206 The discovery proceeds as follows: 208 1. The server advertises an instance of the above described pairing 209 service and displays its instance name on the server's screen. 211 2. The client discovers all the instances of the pairing service 212 available on the local network. This may result in the discovery 213 of several instance names. 215 3. Among these available instance names, the client's user selects 216 the name that matches the name displayed by the server. 218 4. Per DNS-SD, the client then retrieves the SRV record of the 219 selected instance, retrieves the corresponding server's A (or 220 AAAA) record, and establishes the connection. 222 2.2. Agreement on a Shared Secret 224 Once the server has been selected at the end of the discovery phase, 225 the client connects to it without further user intervention. Client 226 and server use this connection for exchanging data that allows them 227 to agree on a shared secret by using TLS and a key exporter. 229 Devices implementing the service MUST support TLS 1.2 [RFC5246], and 230 MAY negotiate TLS 1.3 when it becomes available. When using TLS, the 231 client and server MUST negotiate a ciphersuite providing forward 232 secrecy (PFS), and strong encryption (256 bits symmetric key). All 233 implementations using TLS 1.2 MUST be able to negotiate the cipher 234 suite TLS_DH_anon_WITH_AES_256_CBC_SHA256. 236 Once the TLS connection has been established, each party extracts the 237 pairing secret S_p from the connection context per [RFC5705], using 238 the following parameters: 240 Disambiguating label string: "PAIRING SECRET" 242 Context value: empty. 244 Length value: 32 bytes (256 bits). 246 The secret "S_p" will be authenticated in the authentication part of 247 the protocol. 249 2.3. Authentication 251 The pairing protocol implemented on top of TLS allows the users to 252 authenticate the shared secret established in the "Agreement" phase, 253 and to minimize the risk of interference by a third party like a 254 "man-in-the-middle". The pairing protocol is built using TLS. The 255 following description uses the presentation language defined in 256 section 4 of [RFC5246]. The protocol uses five message types, 257 defined in the following enum: 259 enum { 260 ClientHash(1), 261 ServerRandom(2), 262 ClientRandom(3), 263 ServerSuccess(4), 264 ClientSuccess(5) 265 } PairingMessageType; 267 Once S_p has been obtained, the client picks a random number R_c, 268 exactly 32 bytes long. The client then selects a hash algorithm, 269 which MUST be the same algorithm as negotiated for building the PRF 270 in the TLS connection. The client then computes the hash value H_c 271 as: 273 H_c = HMAC_hash(S_p, R_c) 275 Where "HMAC_hash" is the HMAC function constructed with the 276 selected algorithm. 278 The client transmits the selected hash function and the computed 279 value of H_c in the Client Hash message, over the TLS connection: 281 struct { 282 PairingMessageType messageType; 283 hashAlgorithm hash; 284 uint8 hashLength; 285 opaque H_c[hashLength]; 286 } ClientHashMessage; 288 messageType: Set to "ClientHash". 290 hash: The code of the selected hash algorithm, per definition of 291 HashAlgorithm in section 7.4.1.1.1 of [RFC5246]. 293 hashLength: The length of the hash H_c, which MUST be consistent 294 with the selected algorithm "hash". 296 H_c: The value of the client hash. 298 Upon reception of this message, the server stores its value. The 299 server picks a random number R_s, exactly 32 bytes long, and 300 transmits it to the client in the server random message, over the TLS 301 connection: 303 struct { 304 PairingMessageType messageType; 305 opaque R_s[32]; 306 } ServerRandomMessage; 308 messageType Set to "ServerRandom". 310 R_s: The value of the random number chosen by the server. 312 Upon reception of this message, the client discloses its own random 313 number by transmitting the client random message: 315 struct { 316 PairingMessageType messageType; 317 opaque R_c[32]; 318 } ClientRandomMessage; 320 messageType Set to "ClientRandom". 322 R_c: The value of the random number chosen by the client. 324 Upon reception of this message, the server verifies that the number 325 R_c hashes to the previously received value H_c. If the number does 326 not match, the server MUST abandon the pairing attempt and abort the 327 TLS connection. 329 At this stage, both client and server can compute the short hash SAS 330 as: 332 SAS = first 20 bits of HMAC_hash(S_p, R_c || R_s) 334 Where "HMAC_hash" is the HMAC function constructed with the hash 335 algorithm selected by the client in the ClientHashMessage. 337 Both client and server display the SAS as a 7 digit decimal integer, 338 including leading zeroes, and ask the user to compare the values. If 339 the SASes match, each user enters an agreement, for example by 340 pressing a button labeled "OK", which results in the pairing being 341 remembered. If they do not match, each user should cancel the 342 pairing, for example by pressing a button labeled "CANCEL". 344 If the values do match and both users agree, the protocol continues 345 with the exchange of names, both server and client announcing their 346 own preferred name in a Success message 348 struct { 349 PairingMessageType messageType; 350 uint8 nameLength; 351 opaque name[nameLength]; 352 } ClientSuccessMessage; 354 messageType: Set to "ClientSuccess" if transmitted by the client, 355 "ServerSuccess" if by the server. 357 nameLength: The length of the string encoding the selected name. 359 name: The selected name of the client or the server, encoded as a 360 string of UTF8 characters. 362 After receiving these messages, client and servers can orderly close 363 the TLS connection, terminating the pairing exchange. 365 3. Optional Use of QR Codes 367 When QR codes are supported, the discovery process can be independent 368 of DNS-SD, because QR codes allow the transmission of a sufficient 369 amount of data. The agreement process can also be streamlined by the 370 scanning of a second QR code. 372 3.1. Discovery Using QR Codes 374 If QR code scanning is available as out-of-band channel, the 375 discovery data is directly transmitted via QR codes instead of DNS-SD 376 over mDNS. Leveraging QR codes, the discovery proceeds as follows: 378 1. The server displays a QR code containing the connection data 379 otherwise found in the SRV and A or AAAA records: IPv4 or IPv6 380 address, port number, and optionally host name. 382 2. The client scans the QR code retrieving the necessary information 383 for establishing a connection to the server. 385 [[TODO: We should precisely specify the data layout of this QR code. 386 It could either be the wire format of the corresponding resource 387 records (which would be easier for us), or a more efficient 388 representation. If we chose the wire format, we could use a fixed 389 name as instance name.]] 391 3.2. Agreement with QR Codes 393 When QR codes are available, the agreement on a shared secret 394 proceeds exactly as in the general case. 396 3.3. Authentication with QR Codes 398 The availability of QR codes does not change the required network 399 messages or the computation of the SAS, which will performed exactly 400 as specified in Section 2.3, but when QR codes are supported, the SAS 401 may also be represented as QR code. 403 In the general case, both client and server display the SAS as a 404 decimal integer, and ask the user to compare the values. If the 405 server supports QR codes, the server displays a QR code encoding the 406 decimal string representation of the SAS. If the client is capable 407 of scanning QR codes, it may scan the value and compare it to the 408 locally computed value. 410 Once user agreement has been obtained, the protocol continues as in 411 the general case presented in Section 2.3. 413 4. Security Considerations 415 We need to consider two types of attacks against a pairing system: 416 attacks that occur during the establishment of the pairing relation, 417 and attacks that occur after that establishment. 419 During the establishment of the pairing system, we are concerned with 420 privacy attacks and with MitM attacks. Privacy attacks reveal the 421 existence of a pairing between two devices, which can be used to 422 track graphs of relations. MitM attacks result in compromised 423 pairing keys. The discovery procedures specified in Section 2.1 and 424 the authentication procedures specified in Section 2.3 are 425 specifically designed to mitigate such attacks, assuming that the 426 client and user are in close, physical proximity and thus a human 427 user can visually acquire and verify the pairing information. 429 The establishment of the pairing results in the creation of a shared 430 secret. After the establishment of the pairing relation, attackers 431 who compromise one of the devices could access the shared secret. 432 This will enable them to either track or spoof the devices. To 433 mitigate such attacks, nodes MUST store the secret safely, and MUST 434 be able to quickly revoke a compromised pairing. 436 5. IANA Considerations 438 This draft does not require any IANA action. 440 6. Acknowledgments 442 We would like to thank Steve Kent and Ted Lemon for their detailed 443 reviews of this document, and for their advice on how to improve it. 445 7. References 447 7.1. Normative References 449 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 450 Requirement Levels", BCP 14, RFC 2119, 451 DOI 10.17487/RFC2119, March 1997, 452 . 454 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 455 (TLS) Protocol Version 1.2", RFC 5246, 456 DOI 10.17487/RFC5246, August 2008, 457 . 459 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 460 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 461 March 2010, . 463 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 464 DOI 10.17487/RFC6762, February 2013, 465 . 467 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 468 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 469 . 471 7.2. Informative References 473 [I-D.ietf-dnssd-pairing-info] 474 Kaiser, D. and C. Huitema, "Device Pairing Design Issues", 475 draft-ietf-dnssd-pairing-info-01 (work in progress), April 476 2018. 478 [I-D.ietf-dnssd-prireq] 479 Huitema, C., "DNS-SD Privacy and Security Requirements", 480 draft-ietf-dnssd-prireq-00 (work in progress), September 481 2018. 483 [I-D.ietf-dnssd-privacy] 484 Huitema, C. and D. Kaiser, "Privacy Extensions for DNS- 485 SD", draft-ietf-dnssd-privacy-04 (work in progress), April 486 2018. 488 [I-D.ietf-dnssd-privacyscaling] 489 Huitema, C., "DNS-SD Privacy Scaling Tradeoffs", draft- 490 ietf-dnssd-privacyscaling-00 (work in progress), September 491 2018. 493 [K17] Kaiser, D., "Efficient Privacy-Preserving 494 Configurationless Service Discovery Supporting Multi-Link 495 Networks", 2017, 496 . 498 Authors' Addresses 500 Christian Huitema 501 Private Octopus Inc. 502 Friday Harbor, WA 98250 503 U.S.A. 505 Email: huitema@huitema.net 507 Daniel Kaiser 508 Esch-sur-Alzette 4360 509 Luxembourg 511 Email: daniel@kais3r.de