idnits 2.17.1 draft-ietf-dnssd-pairing-03.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 (September 10, 2017) is 2420 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 312 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-02) exists of draft-ietf-dnssd-pairing-info-00 == Outdated reference: A later version (-05) exists of draft-ietf-dnssd-privacy-02 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 Private Octopus Inc. 4 Intended status: Standards Track D. Kaiser 5 Expires: March 14, 2018 University of Konstanz 6 September 10, 2017 8 Device Pairing Using Short Authentication Strings 9 draft-ietf-dnssd-pairing-03 11 Abstract 13 This document proposes a device pairing mechanism that establishes a 14 relation 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 https://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 14, 2018. 43 Copyright Notice 45 Copyright (c) 2017 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 62 1.2. Document Organization . . . . . . . . . . . . . . . . . . 3 63 2. Protocol Specification . . . . . . . . . . . . . . . . . . . 4 64 2.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2.2. Agreement on a Shared Secret . . . . . . . . . . . . . . 5 66 2.3. Authentication . . . . . . . . . . . . . . . . . . . . . 6 67 3. Optional Use of QR Codes . . . . . . . . . . . . . . . . . . 8 68 3.1. Discovery Using QR Codes . . . . . . . . . . . . . . . . 8 69 3.2. Agreement with QR Codes . . . . . . . . . . . . . . . . . 9 70 3.3. Authentication with QR Codes . . . . . . . . . . . . . . 9 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 76 7.2. Informative References . . . . . . . . . . . . . . . . . 10 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 79 1. Introduction 81 To engage in secure and privacy preserving communication, hosts need 82 to differentiate between authorized peers, which must both know about 83 the host's presence and be able to decrypt messages sent by the host, 84 and other peers, which must not be able to decrypt the host's 85 messages and ideally should not obtain information that could be used 86 to identify the host. The necessary relation between host and peer 87 can be established by a centralized service, e.g. a certificate 88 authority, by a web of trust, e.g. PGP, or -- without using global 89 identities -- by device pairing. 91 This document proposes a device pairing mechanism that provides human 92 operated devices with pairwise authenticated secrets, allowing mutual 93 automatic re-discovery at any later point in time along with mutual 94 private authentication. We especially care about privacy and user- 95 friendliness. This pairing system can provide the pairing secrets 96 used in DNSSD Privacy Extensions [I-D.ietf-dnssd-privacy]. 98 The proposed pairing mechanism consists of three steps needed to 99 establish a relationship between a host and a peer: 101 1. Discovering the peer device. The host needs a means to discover 102 network parameters necessary to establish a connection to the 103 peer. During this discovery process, neither the host nor the 104 peer must disclose its presence. 106 2. Agreeing on pairing data. The devices have to agree on pairing 107 data, which can be used by both parties at any later point in 108 time to generate identifiers for re-discovery and to prove the 109 authenticity of the pairing. The pairing data can e.g. be a 110 shared secret agreed upon via a Diffie-Hellman key exchange. 112 3. Authenticating pairing data. Since in most cases the messages 113 necessary to agree upon pairing data are send over an insecure 114 channel, means that guarantee the authenticity of these messages 115 are necessary; otherwise the pairing data is in turn not suited 116 as a means for a later proof of authenticity. For the proposed 117 pairing mechanism we use manual authentication involving an SAS 118 (short authentication string) to proof the authenticity of the 119 pairing data. 121 The design of this protocol is based on the analysis of pairing 122 protocols issues presented in [I-D.ietf-dnssd-pairing-info] and in 123 [K17]. 125 Many pairing scenarios involve cell phones equipped with cameras 126 capable of reading a QR code. In these scenarios, scanning QR codes 127 might be more user friendly than selecting names or reading short 128 authentication strings from on screen menus. An optional use of QR 129 codes in pairing protocols is presented is Section 3. 131 1.1. Requirements 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 1.2. Document Organization 139 NOTE TO RFC EDITOR: remove or rewrite this section before 140 publication. 142 The original version of this document was organized in two parts. 143 The first part presented the pairing need, the list of requirements 144 that shall be met. This first part was informational in nature. The 145 second part composed the actual specification of the protocol. 147 In his early review, Steve Kent observed that the style of the first 148 part seems inappropriate for a standards track document, and 149 suggested that the two parts should be split into two documents, the 150 first part becoming an informational document, and the second 151 focusing on standard track specification of the protocol, making 152 reference to the informational document as appropriate. 154 The DNS-SD working group approved this split during its meeting in 155 Prague in July 2017. This version of the document implements the 156 split, only retaining the specification part. 158 2. Protocol Specification 160 In the proposed pairing protocol, we will consider the device that 161 initiates the pairing as the "client" and the device that responds as 162 the "server". The server will publish a "pairing service". The 163 client will discover the service instance during the discovery phase, 164 as explained in Section 2.1. The pairing service itself is specified 165 in Section 2.3. 167 We divide pairing in three parts: discovery, agreement, and 168 authentication, detailed in the following subsections. 170 2.1. Discovery 172 The goal of the discovery phase is establishing a connection, which 173 is later used to exchange the pairing data between the two devices 174 that are about to be paired in an IP network without any prior 175 knowledge and without publishing any private information. 177 When the pairing service starts, the server will advertise the 178 pairing service according to DNS-SD [RFC6763] over mDNS [RFC6762]. 179 In conformance with DNS-SD, the service is described by an SRV record 180 and by and empty TXT record. These records will be organized as 181 follows: 183 1. The pairing service is identified in DNS-SD as "_pairing._tcp". 185 2. The instance name will be a text chosen by the server. It MAY be 186 a random string if the server does not want to advertise its 187 identity in the local environment, or the user friendly name of 188 the server in other cases. 190 3. The priority and weight fields of the SRV record SHOULD be set 191 according to [RFC6763]. 193 4. The host name MUST be set to the host name advertised by the 194 server in mDNS. The server MAY use a randomized host name as 195 explained in [I-D.ietf-dnssd-privacy], provided that this name is 196 properly published in mDNS. 198 5. The port number MUST be set to the number at which the server is 199 listening for the pairing service. This port number SHOULD be 200 randomly picked by the server. 202 The discovery proceeds as follows: 204 1. The server advertises an instance of the above described pairing 205 service and displays its instance name on the server's screen. 207 2. The client discovers all the instances of the pairing service 208 available on the local network. This may result in the discovery 209 of several instance names. 211 3. Among these available instance names, the client's user selects 212 the name that matches the name displayed by the server. 214 4. Per DNS-SD, the client then retrieves the SRV record of the 215 selected instance, retrieves the corresponding server's A (or 216 AAAA) record, and establishes the connection. 218 2.2. Agreement on a Shared Secret 220 Once the server has been selected at the end of the discovery phase, 221 the client connects to it without further user intervention. Client 222 and server use this connection for exchanging data that allows them 223 to agree on a shared secret by using TLS and a key exporter. 225 Devices implementing the service MUST support TLS 1.2 [RFC5246], and 226 MAY negotiate TLS 1.3 when it becomes available. When using TLS, the 227 client and server MUST negotiate a ciphersuite providing forward 228 secrecy (PFS), and strong encryption (256 bits symmetric key). All 229 implementations using TLS 1.2 MUST be able to negotiate the cipher 230 suite TLS_DH_anon_WITH_AES_256_CBC_SHA256. 232 Once the TLS connection has been established, each party extracts the 233 pairing secret S_p from the connection context per [RFC5705], using 234 the following parameters: 236 Disambiguating label string: "PAIRING SECRET" 237 Context value: empty. 239 Length value: 32 bytes (256 bits). 241 The secret "S_p" will be authenticated in the authentication part of 242 the protocol. 244 2.3. Authentication 246 The pairing protocol implemented on top of TLS allows the users to 247 authenticate the shared secret established in the "Agreement" phase, 248 and to minimize the risk of interference by a third party like a 249 "man-in-the-middle". The pairing protocol is built using TLS. The 250 following description uses the presentation language defined in 251 section 4 of [RFC5246]. The protocol uses five message types, 252 defined in the following enum: 254 enum { 255 ClientHash(1), 256 ServerRandom(2), 257 ClientRandom(3), 258 ServerSuccess(4), 259 ClientSuccess(5) 260 } PairingMessageType; 262 Once S_p has been obtained, the client picks a random number R_c, 263 exactly 32 bytes long. The client then selects a hash algorithm, 264 which MUST be the same algorithm as negotiated for building the PRF 265 in the TLS connection. The client then computes the hash value H_c 266 as: 268 H_c = HMAC_hash(S_p, R_c) 270 Where "HMAC_hash" is the HMAC function constructed with the 271 selected algorithm. 273 The client transmits the selected hash function and the computed 274 value of H_c in the Client Hash message, over the TLS connection: 276 struct { 277 PairingMessageType messageType; 278 hashAlgorithm hash; 279 uint8 hashLength; 280 opaque H_c[hashLength]; 281 } ClientHashMessage; 283 messageType: Set to "ClientHash". 285 hash: The code of the selected hash algorithm, per definition of 286 HashAlgorithm in section 7.4.1.1.1 of [RFC5246]. 288 hashLength: The length of the hash H_c, which MUST be consistent 289 with the selected algorithm "hash". 291 H_c: The value of the client hash. 293 Upon reception of this message, the server stores its value. The 294 server picks a random number R_s, exactly 32 bytes long, and 295 transmits it to the client in the server random message, over the TLS 296 connection: 298 struct { 299 PairingMessageType messageType; 300 opaque R_s[32]; 301 } ServerRandomMessage; 303 messageType Set to "ServerRandom". 305 R_s: The value of the random number chosen by the server. 307 Upon reception of this message, the client discloses its own random 308 number by transmitting the client random message: 310 struct { 311 PairingMessageType messageType; 312 opaque R_c[32]; 313 } ClientRandomMessage; 315 messageType Set to "ClientRandom". 317 R_c: The value of the random number chosen by the client. 319 Upon reception of this message, the server verifies that the number 320 R_c hashes to the previously received value H_c. If the number does 321 not match, the server MUST abandon the pairing attempt and abort the 322 TLS connection. 324 At this stage, both client and server can compute the short hash SAS 325 as: 327 SAS = first 20 bits of HMAC_hash(S_p, R_c || R_s) 329 Where "HMAC_hash" is the HMAC function constructed with the hash 330 algorithm selected by the client in the ClientHashMessage. 332 Both client and server display the SAS as a 7 digit decimal integer, 333 including leading zeroes, and ask the user to compare the values. If 334 the SASes match, each user enters an agreement, for example by 335 pressing a button labeled "OK", which results in the pairing being 336 remembered. If they do not match, each user should cancel the 337 pairing, for example by pressing a button labeled "CANCEL". 339 If the values do match and both users agree, the protocol continues 340 with the exchange of names, both server and client announcing their 341 own preferred name in a Success message 343 struct { 344 PairingMessageType messageType; 345 uint8 nameLength; 346 opaque name[nameLength]; 347 } ClientSuccessMessage; 349 messageType: Set to "ClientSuccess" if transmitted by the client, 350 "ServerSuccess" if by the server. 352 nameLength: The length of the string encoding the selected name. 354 name: The selected name of the client or the server, encoded as a 355 string of UTF8 characters. 357 After receiving these messages, client and servers can orderly close 358 the TLS connection, terminating the pairing exchange. 360 3. Optional Use of QR Codes 362 When QR codes are supported, the discovery process can be independent 363 of DNS-SD, because QR codes allow the transmission of a sufficient 364 amount of data. The agreement process can also be streamlined by the 365 scanning of a second QR code. 367 3.1. Discovery Using QR Codes 369 If QR code scanning is available as out-of-band channel, the 370 discovery data is directly transmitted via QR codes instead of DNS-SD 371 over mDNS. Leveraging QR codes, the discovery proceeds as follows: 373 1. The server displays a QR code containing the connection data 374 otherwise found in the SRV and A or AAAA records: IPv4 or IPv6 375 address, port number, and optionally host name. 377 2. The client scans the QR code retrieving the necessary information 378 for establishing a connection to the server. 380 [[TODO: We should precisely specify the data layout of this QR code. 381 It could either be the wire format of the corresponding resource 382 records (which would be easier for us), or a more efficient 383 representation. If we chose the wire format, we could use a fixed 384 name as instance name.]] 386 3.2. Agreement with QR Codes 388 When QR codes are available, the agreement on a shared secret 389 proceeds exactly as in the general case. 391 3.3. Authentication with QR Codes 393 The availability of QR codes does not change the required network 394 messages or the computation of the SAS, which will performed exactly 395 as specified in Section 2.3, but when QR codes are supported, the SAS 396 may also be represented as QR code. 398 In the general case, both client and server display the SAS as a 399 decimal integer, and ask the user to compare the values. If the 400 server supports QR codes, the server displays a QR code encoding the 401 decimal string representation of the SAS. If the client is capable 402 of scanning QR codes, it may scan the value and compare it to the 403 locally computed value. 405 Once user agreement has been obtained, the protocol continues as in 406 the general case presented in Section 2.3. 408 4. Security Considerations 410 We need to consider two types of attacks against a pairing system: 411 attacks that occur during the establishment of the pairing relation, 412 and attacks that occur after that establishment. 414 During the establishment of the pairing system, we are concerned with 415 privacy attacks and with MitM attacks. Privacy attacks reveal the 416 existence of a pairing between two devices, which can be used to 417 track graphs of relations. MitM attacks result in compromised 418 pairing keys. The discovery procedures specified in Section 2.1 and 419 the authentication procedures specified in Section 2.3 are 420 specifically designed to mitigate such attacks, assuming that the 421 client and user are in close, physical proximity and thus a human 422 user can visually acquire and verify the pairing information. 424 The establishment of the pairing results in the creation of a shared 425 secret. After the establishment of the pairing relation, attackers 426 who compromise one of the devices could access the shared secret. 427 This will enable them to either track or spoof the devices. To 428 mitigate such attacks, nodes MUST store the secret safely, and MUST 429 be able to quickly revoke a compromised pairing. 431 5. IANA Considerations 433 This draft does not require any IANA action. 435 6. Acknowledgments 437 We would like to thank Steve Kent and Ted Lemon for their detailed 438 reviews of this document, and for their advice on how to improve it. 440 7. References 442 7.1. Normative References 444 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 445 Requirement Levels", BCP 14, RFC 2119, 446 DOI 10.17487/RFC2119, March 1997, 447 . 449 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 450 (TLS) Protocol Version 1.2", RFC 5246, 451 DOI 10.17487/RFC5246, August 2008, 452 . 454 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 455 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 456 March 2010, . 458 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 459 DOI 10.17487/RFC6762, February 2013, 460 . 462 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 463 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 464 . 466 7.2. Informative References 468 [I-D.ietf-dnssd-pairing-info] 469 Kaiser, D. and C. Huitema, "Device Pairing Design Issues", 470 draft-ietf-dnssd-pairing-info-00 (work in progress), 471 September 2017. 473 [I-D.ietf-dnssd-privacy] 474 Huitema, C. and D. Kaiser, "Privacy Extensions for DNS- 475 SD", draft-ietf-dnssd-privacy-02 (work in progress), July 476 2017. 478 [K17] Kaiser, D., "Efficient Privacy-Preserving 479 Configurationless Service Discovery Supporting Multi-Link 480 Networks", 2017, 481 . 483 Authors' Addresses 485 Christian Huitema 486 Private Octopus Inc. 487 Friday Harbor, WA 98250 488 U.S.A. 490 Email: huitema@huitema.net 492 Daniel Kaiser 493 University of Konstanz 494 Konstanz 78457 495 Germany 497 Email: daniel.kaiser@uni-konstanz.de