--- 1/draft-ietf-dnssd-pairing-01.txt 2017-07-03 11:14:18.564008954 -0700 +++ 2/draft-ietf-dnssd-pairing-02.txt 2017-07-03 11:14:18.608009998 -0700 @@ -1,19 +1,19 @@ Network Working Group C. Huitema Internet-Draft Private Octopus Inc. Intended status: Standards Track D. Kaiser -Expires: September 8, 2017 University of Konstanz - March 7, 2017 +Expires: January 4, 2018 University of Konstanz + July 3, 2017 Device Pairing Using Short Authentication Strings - draft-ietf-dnssd-pairing-01.txt + draft-ietf-dnssd-pairing-02.txt Abstract This document proposes a device pairing mechanism that establishes a relationship between two devices by agreeing on a secret and manually verifying the secret's authenticity using an SAS (short authentication string). Pairing has to be performed only once per pair of devices, as for a re-discovery at any later point in time, the exchanged secret can be used for mutual authentication. @@ -31,21 +31,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 8, 2017. + This Internet-Draft will expire on January 4, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -56,45 +56,45 @@ described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Document Organization . . . . . . . . . . . . . . . . . . 4 2. Problem Statement and Requirements . . . . . . . . . . . . . 4 2.1. Secure Pairing Over Internet Connections . . . . . . . . 4 2.2. Identity Assurance . . . . . . . . . . . . . . . . . . . 5 - 2.3. Adequate User Interface . . . . . . . . . . . . . . . . . 5 + 2.3. Manual Authentication . . . . . . . . . . . . . . . . . . 5 2.3.1. Short PIN Proved Inadequate . . . . . . . . . . . . . 5 2.3.2. Push Buttons Just Work, But Are Insecure . . . . . . 6 2.3.3. Short Range Communication . . . . . . . . . . . . . . 6 2.3.4. Short Authentication Strings . . . . . . . . . . . . 7 2.4. Resist Cryptographic Attacks . . . . . . . . . . . . . . 8 - 2.5. Privacy Requirements . . . . . . . . . . . . . . . . . . 10 + 2.5. Privacy Requirements . . . . . . . . . . . . . . . . . . 11 2.6. Using TLS . . . . . . . . . . . . . . . . . . . . . . . . 11 2.7. QR codes . . . . . . . . . . . . . . . . . . . . . . . . 12 - 2.8. Intra User Pairing and Transitive Pairing . . . . . . . . 13 - 3. Design of the Pairing Mechanism . . . . . . . . . . . . . . . 14 - 3.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 14 - 3.2. Agreement . . . . . . . . . . . . . . . . . . . . . . . . 15 - 3.3. Authentication . . . . . . . . . . . . . . . . . . . . . 15 - 3.4. Public Authentication Keys . . . . . . . . . . . . . . . 16 + 2.8. Intra User Pairing and Transitive Pairing . . . . . . . . 14 + 3. Design of the Pairing Mechanism . . . . . . . . . . . . . . . 15 + 3.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 15 + 3.2. Agreement . . . . . . . . . . . . . . . . . . . . . . . . 16 + 3.3. Authentication . . . . . . . . . . . . . . . . . . . . . 16 + 3.4. Authenticating Public Keys . . . . . . . . . . . . . . . 16 4. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 4.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 16 - 4.2. Agreement and Authentication . . . . . . . . . . . . . . 16 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 + 4.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 17 + 4.2. Agreement and Authentication . . . . . . . . . . . . . . 17 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 20 - 8.2. Informative References . . . . . . . . . . . . . . . . . 20 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 21 + 8.2. Informative References . . . . . . . . . . . . . . . . . 21 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction To engage in secure and privacy preserving communication, hosts need to differentiate between authorized peers, which must both know about the host's presence and be able to decrypt messages sent by the host, and other peers, which must not be able to decrypt the host's messages and ideally should not be aware of the host's presence. The necessary relationship between host and peer can be established by a centralized service, e.g. a certificate authority, by a web of trust, @@ -119,21 +119,21 @@ data, which can be used by both parties at any later point in time to generate identifiers for re-discovery and to prove the authenticity of the pairing. The pairing data can e.g. be a shared secret agreed upon via a Diffie-Hellman key exchange. 3. Authenticating pairing data. Since in most cases the messages necessary to agree upon pairing data are send over an insecure channel, means that guarantee the authenticity of these messages are necessary; otherwise the pairing data is in turn not suited as a means for a later proof of authenticity. For the proposed - pairing mechanism we use manual interaction involving an SAS + pairing mechanism we use manual authentication involving an SAS (short authentication string) to proof the authenticity of the pairing data. 1.1. Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.2. Document Organization @@ -191,33 +191,35 @@ established with Bob, and not with some interloper like Eve or Nessie. Providing this assurance requires designing both the protocol and the user interface (UI) with care. Consider for example an attack in which Eve tricks Alice into engaging in a pairing process while pretending to be Bob. Alice must be able to discover that something is wrong, and refuse to establish the pairing. The parties engaged in the pairing must at least be able to verify their identities, respectively. -2.3. Adequate User Interface +2.3. Manual Authentication Because the pairing protocol is executed without prior knowledge, it - is typically vulnerable to "Man-in-the-middle" attacks. While Alice + is typically vulnerable to "Man-in-the-Middle" attacks. While Alice is trying to establish a pairing with Bob, Eve positions herself in the middle. Instead of getting a pairing between Alice and Bob, both Alice and Bob get paired with Eve. This requires specific features in - the protocol to detect man-in-the-middle attacks, and if possible - resist them. The reference [NR11] analyzes the various proposals to - solve this problem, and in this document, we present a layman - description of these issues in Section 2.4. The various protocols - proposed in the literature impose diverse constraints on the UI - interface, which we will review here. + the protocol to detect Man-in-the-Middle attacks, and if possible + resist them. + + This section discusses existing techniques that are used in practice, + and Section 2.4 provides a layman description of the MiTM problem and + countermeasures. A more in depth exploration of manually + authenticated pairing protocols may be found in [NR11] and [thesis + kaiserd]. 2.3.1. Short PIN Proved Inadequate The initial Bluetooth pairing protocol relied on a four digit PIN, displayed by one of the devices to be paired. The user would read that PIN and provide it to the other device. The PIN would then be used in a Password Authenticated Key Exchange. Wi-Fi Protected Setup [WPS] offered a similar option. There were various attacks against the actual protocol; some of the problems were caused by issues in the protocol, but most were tied to the usage of short PINs. @@ -240,81 +242,86 @@ It is interesting to note that the latest revisions of the Bluetooth Pairing protocol [BTLEPairing] do not include the short PIN option anymore. The PIN entry methods have been superseded by the simple "just works" method for devices without displays, and by a procedure based on an SAS (short authentication string) when displays are available. A further problem with these PIN based approaches is that -- in contrast to SASes -- the PIN is a secret instrumental in the security algorithm. To guarantee security, this PIN would have to be - transmitted via a secure out of band channel. + transmitted via a secure out-of-band channel. 2.3.2. Push Buttons Just Work, But Are Insecure Some devices are unable to input or display any code. The industry more or less converged on a "push button" solution. When the button is pushed, devices enter a "pairing" mode, during which they will accept a pairing request from whatever other device connects to them. The Bluetooth Pairing protocol [BTLEPairing] denotes that as the "just works" method. It does indeed work, and if the pairing succeeds the devices will later be able to use the pairing keys to authenticate connections. However, the procedure does not provide - any protection against MITM attacks during the pairing process. The + any protection against MitM attacks during the pairing process. The only protection is that pushing the button will only allow pairing for a limited time, thus limiting the opportunities of attacks. As we set up to define a pairing protocol with a broad set of applications, we cannot limit ourselves to an insecure "push button" method. But we probably need to allow for a mode of operation that works for input-limited and display limited devices. 2.3.3. Short Range Communication - There have been several attempts to define pairing protocols that use - "secure channels." Most of them are based on short range - communication systems, where the short range limits the feasibility - for attackers to access the channels. Example of such limited - systems include for example: + Many pairing protocols that use out-of-band channels have been + defined. Most of them are based on short range communication + systems, where the short range limits the feasibility for attackers + to access the channels. Example of such limited systems include for + example: o QR codes, displayed on the screen of one device, and read by the camera of the other device. o Near Field Communication (NFC) systems, which provides wireless communication with a very short range. o Sound systems, in which one systems emits a sequence of sounds or ultrasounds that is picked by the microphone of the other system. A common problem with these solutions is that they require special capabilities that may not be present in every device. Another - problem is that they are often one-way channels. Yet another problem - is that the side channel is not necessarily secret. QR codes could - be read by third parties. Powerful radio antennas might be able to - interfere with NFC. Sensitive microphones might pick the sounds. We - will discuss the specific case of QR codes in Section 2.7. - -2.3.4. Short Authentication Strings + problem is that they are often one-way channels. - The evolving pairing protocols seem to converge towards a "display - and compare" method. This is in line with academic studies, such as - [KFR09] or [USK11], and points to a very simple scenario: + The pairing protocols should not rely on the secrecy of the out-of- + band channels; most of these out-of-band channels do not provide + confidentiality. QR codes could be read by third parties. Powerful + radio antennas might be able to interfere with NFC. Sensitive + microphones might pick the sounds. However, a property that all of + these channels share is authenticity, i.e. an assurance that the data + obtained over the out-of-band channel actually comes from the other + party. This is because these out-of-band channels involve the user + transmitting information from one device to the other. We will + discuss the specific case of QR codes in Section 2.7. - 1. Alice initiates pairing +2.3.4. Short Authentication Strings - 2. Bob selects Alice's device from a list. + The evolving pairing protocols seem to converge towards using Short + Authentication Strins and verifying them via the "compare and + confirm" method. This is in line with academic studies, such as + [KFR09] or [USK11], and, from the users' perspective, results in a + very simple interaction: - 3. Alice and Bob compare displayed strings that represent a - fingerprint of the key. + 1. Alice and Bob compare displayed strings that represent a + fingerprint of the afore exchanged pairing key. - 4. If the strings match, Alice and Bob accept the pairing. + 2. If the strings match, Alice and Bob accept the pairing. Most existing pairing protocols display the fingerprint of the key as a 6 or 7 digit numbers. Usability studies show that this method gives good results, with little risk that users mistakenly accept two different numbers as matching. However, the authors of [USK11] found that people had more success comparing computer generated sentences than comparing numbers. This is in line with the argument in [XKCD936] to use sequences of randomly chosen common words as passwords. On the other hand, standardizing strings is more complicated than standardizing numbers. We would need to specify a @@ -342,62 +349,68 @@ <-- g^xB nA --> <-- nB Computes Computes s = g^xAxB s = g^xAxB h = hash(s|nA|nB) h = hash(s|nA|nB) Displays short Displays short version of h version of h If the two short hashes match, Alice and Bob are supposedly assured - that they have computed the same secret, but there is a problem. The - exchange may not deter a smart attacker in the middle. Let's redraw - the same message flow, this time involving Eve: + that they have computed the same secret, but there is a problem. + Let's redraw the same message flow, this time involving the attacker + Eve: Alice Eve Bob g^xA --> g^xA'--> <-- g^xB <--g^xB' nA --> nA --> <-- nB Picks nB' smartly <--nB' Computes Computes s' = g^xAxB' s" = g^xA'xB - h' = hash(s|nA|nB') h" = hash(s"|nA|nB) + h' = hash(s'|nA|nB') h" = hash(s"|nA|nB) Displays short Displays short version of h' version of h" - Let's now assume that, in order to pick the nonce nB' smartly, Eve - runs the following algorithm: + In order to pick a nonce nB' that circumvents this naive security + measure, Eve runs the following algorithm: s' = g^xAxB' s" = g^xA'xB repeat pick a new version of nB' - h' = hash(s|nA|nB') + h' = hash(s'|nA|nB') h" = hash(s"|nA|nB) until the short version of h' matches the short version of h" - Of course, running this algorithm will, in theory, require as many - iterations as there are possible values of the short hash. But hash - algorithms are fast, and it is possible to try millions of values in - less than a second. If the short string is made up of fewer than 6 - digits, Eve will find a matching nonce quickly, and Alice and Bob - will hardly notice the delay. Even if the matching string is as long - as 8 letters, Eve will probably find a value where the short versions - of h' and h" are close enough, e.g. start and end with the same two - or three letters. Alice and Bob may well be fooled. + Running this algorithm will take O(2^b) iterations on average + (assuming a uniform distribution), where b is the bit length of the + SAS. Since hash algorithms are fast, it is possible to try millions + of values in less than a second. If the short string is made up of + fewer than 6 digits, Eve will find a matching nonce quickly, and + Alice and Bob will hardly notice the delay. Even if the matching + string is as long as 8 letters, Eve will probably find a value where + the short versions of h' and h" are close enough, e.g. start and end + with the same two or three letters. Alice and Bob may well be + fooled. + + Eve could also utilize the fact that she may freely choose the whole + input for the hash function and thus choose g^xA' and g^xB' so that + an arbitrary collision (birthday attack) instead of a second preimage + is sufficient for fooling Alice and Bob. The classic solution to such problems is to "commit" a possible attacker to a nonce before sending it. This commitment can be realized by a hash. In the modified exchange, Alice sends a secure hash of her nonce before sending the actual value: Alice Bob g^xA --> <-- g^xB @@ -441,60 +454,59 @@ secret as a key, since the HMAC construct has proven very robust over time. Then, we can constrain the size of the random numbers to be exactly the same as the output of the hash function. Hash attacks often require padding the input string with arbitrary data; restraining the size limits the likelyhood of such padding. 2.5. Privacy Requirements Pairing exposes a relation between several devices and their owners. Adversaries may attempt to collect this information, for example in - an attempt to track devices, their owners, or their "social graph". - It is often argued that pairing could be performed in a safe place, - from which adversaries are assumed absent, but experience shows that - such assumptions are often misguided. It is much safer to - acknowledge the privacy issues and design the pairing process - accordingly. + an attempt to track devices, their owners, or their social graph. It + is often argued that pairing could be performed in a safe place, from + which adversaries are assumed absent, but experience shows that such + assumptions are often misguided. It is much safer to acknowledge the + privacy issues and design the pairing process accordingly. In order to start the pairing process, devices must first discover each other. We do not have the option of using the private discovery protocol [I-D.ietf-dnssd-privacy] since the privacy of that protocol depends on a pre-existing pairing. In the simplest design, one of - the devices will announce a "friendly name" using DNS-SD. + the devices will announce a user-friendly name using DNS-SD. Adversaries could monitor the discovery protocol, and record that name. An alternative would be for one device to announce a random name, and communicate it to the other device via some private channel. There is an obvious tradeoff here: friendly names are easier to use but less private than random names. We anticipate that different users will choose different tradeoffs, for example using - friendly names if they assume that the environment is "safe," and - using random names in public places. + friendly names if they assume that the environment is safe, and using + random names in public places. During the pairing process, the two devices establish a connection and validate a pairing secret. As discussed in Section 2.3, we have - to assume that adversaries can mount MITM attacks. The pairing + to assume that adversaries can mount MitM attacks. The pairing protocol can detect such attacks and resist them, but the attackers - will have access to all messages exchanged before validation is + will have access to all messages exchanged before the validation is performed. It is important to not exchange any privacy sensitive information before that validation. This includes, for example, the identities of the parties or their public keys. 2.6. Using TLS The pairing algorithms typically combine the establishment of a shared secret through an [EC]DH exchange with the verification of - that secret through displaying and comparison of a "short - authentication string" (SAS). As explained in Section 2.4, the - secure comparison requires a "commit before disclose" mechanism. + that secret through displaying and comparing a "short authentication + string" (SAS). As explained in Section 2.4, the secure comparison + requires a "commit before disclose" mechanism. We have three possible designs: (1) create a pairing algorithm from - scratch, specifying our own crypto exchanges; (2) use an [EC]DH + scratch, specifying our own cryptographic protocol; (2) use an [EC]DH version of TLS to negotiate a shared secret, export the key to the application as specified in [RFC5705], and implement the "commit before disclose" and SAS verification as part of the pairing application; or, (3) use TLS, integrate the "commit before disclose" and SAS verification as TLS extensions, and export the verified key to the application as specified in [RFC5705]. When faced with the same choice, the designers of ZRTP [RFC6189] chose to design a new protocol integrated in the general framework of real time communications. We don't want to follow that path, and @@ -532,21 +544,21 @@ QR codes are displayed as images. An adversary equipped with powerful cameras could read the QR code just as well as the pairing parties. If the pairing protocol design embedded passwords or pins in the QR code, adversaries could access these data and compromise the protocol. On the other hand, there are ways to use QR codes even without assuming secrecy. QR codes could be used at two of the three stages of pairing: Discovering the peer device, and authenticating the shared secret. - Using QR codes provide advantages in both phases: + Using QR codes provides advantages in both phases: o Typical network based discovery involves interaction with two devices. The device to be discovered is placed in "server" mode, and waits for requests from the network. The device performing the discovery retrieves a list of candidates from the network. When there is more than one such candidate, the device user is expected to select the desired target from a list. In QR code mode, the discovered device will display a QR code, which the user will scan using the second device. The QR code will embed the device's name, its IP address, and the port number of the pairing @@ -603,21 +615,21 @@ # ### # #mm"#"#m " #mmmmm# #mm"#""m "m" Did the number match (Yes/No)? With the use of QR code, the pairing is established with little reliance on user judgment, which is arguably safer. 2.8. Intra User Pairing and Transitive Pairing - There are two usage modes for pairing: inter-users, and intra-user. + There are two usage modes for pairing: inter-user, and intra-user. Users have multiple devices. The simplest design is to not distinguish between pairing devices belonging to two users, e.g., Alice's phone and Bob's phone, and devices belonging to the same user, e.g., Alice's phone and her laptop. This will most certainly work, but it raises the problem of transitivity. If Bob needs to interact with Alice, should he install just one pairing for "Alice and Bob", or should he install four pairings between Alice phone and laptop and Bob phone and laptop? Also, what happens if Alice gets a new phone? @@ -682,22 +694,22 @@ 1. The server displays its chosen instance name on its screen. 2. The client performs a discovery of all the "pairing" servers available on the local network. This may result in the discovery of several servers. 3. Among these available "pairing servers" the client's user selects the name that matches the name displayed by the server. 4. Per DNS-SD, the client then retrieves the SRV records of the - selected instance, select one of the document servers, retrieves - its A or AAAA records, and establishes the connection. + selected instance, selects one of the discovered servers, + retrieves its A or AAAA records, and establishes the connection. 3.2. Agreement Once the server has been selected, the client connects to it without further user intervention. Client and server use this connection for exchanging data that allows them to agree on a shared secret by using a cryptographic protocol that yields an SAS. We discussed design aspects of such protocols in Section 2.4. 3.3. Authentication @@ -711,46 +723,46 @@ labeled "CANCEL". Depending on whether QR codes are supported, the SAS may also be represented as QR code. Despite the fact that using QR codes to represent the authentication string renders using longer authentication strings feasible, we suggest to always generate an SAS during the agreement phase, because this makes realizations of the agreement phase and the authentication phase independent. Devices may display the "real" name of the other device alongside the SAS. -3.4. Public Authentication Keys +3.4. Authenticating Public Keys - [[TODO: Should we discuss public authentication keys whose - fingerprints are verified during pairing?]] + [[TODO: Should we discuss verifying public keys using our pairing + mechanism?]] 4. Solution In the proposed pairing protocol, one of the devices acts as a "server", and the other acts as a "client". The server will publish a "pairing service". The client will discover the service instance during the discovery phase, as explained in Section 4.1. The pairing service itself is specified in Section 4.2. 4.1. Discovery The discovery uses DNS-SD [RFC6763] over mDNS [RFC6762]. The pairing service is identified in DNS SD as "_pairing._tcp". When the pairing service starts, the server starts publishing the chosen instance name. The client will discover that name and the corresponding connection parameters. - If QR code scanning is available as OOB channel, the discovery data - is directly transmitted via QR codes instead of DNS-SD over mDNS. - The QR data contains connection data otherwise found in the SRV and A - or AAAA records: IPv4 or IPv6 address, port number, and optionally - host name. + If QR code scanning is available as out-of-band channel, the + discovery data is directly transmitted via QR codes instead of DNS-SD + over mDNS. The QR code data contains connection data otherwise found + in the SRV and A or AAAA records: IPv4 or IPv6 address, port number, + and optionally host name. [[TODO: We should precisely specify the data layout of this QR code. It could either be the wire format of the corresponding resource records (which would be easier for us), or a more efficient representation. If we chose the wire format, we could use a fix name as instance name.]] 4.2. Agreement and Authentication The pairing protocol is built using TLS. The following description @@ -880,23 +891,23 @@ After receiving these messages, client and servers can orderly close the TLS connection, terminating the pairing exchange. 5. Security Considerations We need to consider two types of attacks against a pairing system: attacks that occur during the establishment of the pairing relation, and attacks that occur after that establishment. During the establishment of the pairing system, we are concerned with - privacy attacks and with MITM attacks. Privacy attacks reveal the + privacy attacks and with MitM attacks. Privacy attacks reveal the existence of a pairing between two devices, which can be used to - track graphs of relations. MITM attacks result in compromised + track graphs of relations. MitM attacks result in compromised pairing keys. The discovery procedures specified in Section 4.1 and the authentication procedures specified in Section 4.2 are specifically designed to mitigate such attacks, assuming that the client and user are in close, physical proximity and thus a human user can visually acquire and verify the pairing information. The establishment of the pairing results in the creation of a shared secret. After the establishment of the pairing relation, attackers who compromise one of the devices could access the shared secret. This will enable them to either track or spoof the devices. To @@ -945,22 +956,22 @@ 8.2. Informative References [BTLEPairing] Bluetooth SIG, "Bluetooth Low Energy Security Overview", 2016, . [I-D.ietf-dnssd-privacy] Huitema, C. and D. Kaiser, "Privacy Extensions for DNS- - SD", draft-ietf-dnssd-privacy-00 (work in progress), - October 2016. + SD", draft-ietf-dnssd-privacy-01 (work in progress), March + 2017. [I-D.miers-tls-sas] Miers, I., Green, M., and E. Rescorla, "Short Authentication Strings for TLS", draft-miers-tls-sas-00 (work in progress), February 2014. [KFR09] Kainda, R., Flechais, I., and A. Roscoe, "Usability and Security of Out-Of-Band Channels in Secure Device Pairing Protocols", DOI: 10.1145/1572532.1572547, SOUPS 09, Proceedings of the 5th Symposium on Usable Privacy and