--- 1/draft-ietf-dnssd-pairing-info-00.txt 2018-04-21 10:13:17.363329165 -0700 +++ 2/draft-ietf-dnssd-pairing-info-01.txt 2018-04-21 10:13:17.403330117 -0700 @@ -1,83 +1,84 @@ Network Working Group D. Kaiser -Internet-Draft University of Konstanz +Internet-Draft Intended status: Informational C. Huitema -Expires: March 7, 2018 Private Octopus Inc. - September 3, 2017 +Expires: October 22, 2018 Private Octopus Inc. + April 20, 2018 Device Pairing Design Issues - draft-ietf-dnssd-pairing-info-00 + draft-ietf-dnssd-pairing-info-01 Abstract This document discusses issues and problems occuring in the design of device pairing mechanism. It presents experience with existing pairing systems and general user interaction requirements to make the case for "short authentication strings". It then reviews the design of cryptographic algorithms designed to maximise the robustness of the short authentication string mechanisms, as well as implementation considerations such as integration with TLS. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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/. + Drafts is at https://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 March 7, 2018. + This Internet-Draft will expire on October 22, 2018. Copyright Notice - Copyright (c) 2017 IETF Trust and the persons identified as the + Copyright (c) 2018 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 + (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Document Organization . . . . . . . . . . . . . . . . . . 3 - 2. Secure Pairing Over Internet Connections . . . . . . . . . . 3 - 3. Identity Assurance . . . . . . . . . . . . . . . . . . . . . 3 + 2. Protocol Independent Secure Pairing . . . . . . . . . . . . . 3 + 3. Identity Assurance . . . . . . . . . . . . . . . . . . . . . 4 4. Manual Authentication . . . . . . . . . . . . . . . . . . . . 4 4.1. Short PIN Proved Inadequate . . . . . . . . . . . . . . . 4 4.2. Push Buttons Just Work, But Are Insecure . . . . . . . . 5 4.3. Short Range Communication . . . . . . . . . . . . . . . . 5 4.4. Short Authentication Strings . . . . . . . . . . . . . . 6 - 5. Resist Cryptographic Attacks . . . . . . . . . . . . . . . . 7 - 6. Privacy Requirements . . . . . . . . . . . . . . . . . . . . 9 - 7. Using TLS . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 8. QR codes . . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 9. Intra User Pairing and Transitive Pairing . . . . . . . . . . 13 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 - 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 - 13. Informative References . . . . . . . . . . . . . . . . . . . 14 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 + 4.5. Revisiting the PIN versus SAS discussion . . . . . . . . 7 + 5. Resist Cryptographic Attacks . . . . . . . . . . . . . . . . 8 + 6. Privacy Requirements . . . . . . . . . . . . . . . . . . . . 10 + 7. Using TLS . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 8. QR codes . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 9. Intra User Pairing and Transitive Pairing . . . . . . . . . . 14 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 + 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 + 13. Informative References . . . . . . . . . . . . . . . . . . . 15 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 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, @@ -105,38 +106,49 @@ In his early review, Steve Kent observed that the style of the first part seems inappropriate for a standards track document, and suggested that the two parts should be split into two documents, the first part becoming an informational document, and the second focusing on standard track specification of the protocol, making reference to the informational document as appropriate. The working group approved this split. -2. Secure Pairing Over Internet Connections +2. Protocol Independent Secure Pairing Many pairing protocols have already been developed, in particular for the pairing of devices over specific wireless networks. For example, the current Bluetooth specifications include a pairing protocol that has evolved over several revisions towards better security and usability [BTLEPairing]. The Wi-Fi Alliance defined the Wi-Fi Protected Setup process to ease the setup of security-enabled Wi-Fi networks in home and small office environments [WPS]. Other wireless standards have defined or are defining similar protocols, tailored to specific technologies. - This specification defines a pairing protocol that is independent of - the underlying technology. We simply make the hypothesis that the - two parties engaged in the pairing can discover each other and then - establish connections over IP in order to agree on a shared secret. + In this document we provide background and discuss the design of a + manually authenticated pairing protocol that is independent of the + underlying network protocol stack. We discuss (1) means allowing the + two parties engaged in the pairing to discover each other in an + existing unsecured network -- e.g. means for learning about the + network parameters of the respective other device -- which allows + them to establish a connection; (2) agreeing on a shared secret via + this connection; and (3) manually authenticating this secret. For + our discussion and our secure pairing protocol specification + [I-D.ietf-dnssd-pairing], we assume an IP based unsecured network. + With little adaption, this pairing mechanism can be used on other + protocol stacks as well. - [[TODO: Should we support certificates besides a shared secret?]] + We limit the goal of the protocol to the establishment of a shared + secret between two parties. Once that secret has been established, + it can trivially be used to secure the exchange of other + informations, such as for example public keys and certificates. 3. Identity Assurance The parties in the pairing must be able to identify each other. To put it simply, if Alice believes that she is establishing a pairing with Bob, she must somehow ensure that the pairing is actually 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. @@ -145,61 +157,60 @@ 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. 4. Manual Authentication Because the pairing protocol is executed without prior knowledge, it 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. + Alice and Bob get paired with Eve. Because of this, the protocol + requires specific features to detect Man-in-the-Middle attacks, and + if possible resist them. - This section discusses existing techniques that are used in practice, - and Section 5 provides a layman description of the MiTM problem and + This section discusses existing techniques that are used in practice + for manually authenticating a Diffie-Hellman key exchange, and + Section 5 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]. + authenticated pairing protocols may be found in [NR11] and [K17]. 4.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. + displayed by one of the devices to be paired. The user read that PIN + and provided it to the other device. The PIN was then 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. In the reference implementation, the PIN is picked at random by the paired device before the beginning of the exchange. But this requires that the paired device is capable of generating and displaying a four digit number. It turns out that many devices cannot do that. For example, an audio headset does not have any display capability. These limited devices ended up using static PINs, with fixed values like "0000" or "0001". - Even when the paired device could display a random PIN, that PIN will - have to be copied by the user on the pairing device. It turns out - that users do not like copying long series of numbers, and the - usability thus dictated that the PINs be short -- four digits in - practice. But there is only so much assurance as can be derived from - a four digit key. + Even when the paired device could display a random PIN, that PIN had + to be copied by the user on the pairing device. It turns out that + users do not like copying long series of numbers, and the usability + thus dictated that the PINs be short -- four digits in practice. But + there is only so much assurance as can be derived from a four digit + key. - 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. + 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. 4.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 @@ -247,48 +258,96 @@ 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 8. 4.4. Short Authentication Strings The evolving pairing protocols seem to converge towards using Short - Authentication Strins and verifying them via the "compare and + Authentication Strings 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: 1. Alice and Bob compare displayed strings that represent a fingerprint of the afore exchanged pairing key. 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 + a 6 or 7 digit number. 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 list of common words, and the process to go from a binary fingerprint to a set of words. We would need to be concerned with internationalization issues, such as using different lists of words in German and in English. This could require the negotiation of word lists or languages inside the pairing protocols. In contrast, numbers are easy to specify, as in "take a 20 bit number and display it as an integer using decimal notation". +4.5. Revisiting the PIN versus SAS discussion + + In section Section 4.1 we presented the drawbacks of using short + pins. One could object that many of the technical issues could be + overcome by use of better PAKE algorithms, or by supporting longer + PIN. And one could also argue that if PIN based pairing algorithms + suffer from failure modes such as static PIN configuration, SAS based + protocols are vulnerable to SAS bypass. + + The SAS bypass argument is rooted in the psychology of users. In + practice, pairing processes can be stressful. The user has to + discover on each device the proper combination of key entries that + brings up the required pairing UI, will be anxious and eager to + complete the procedure, and may well be predisposed to click "OK" in + the final stage of the algorithm without actually verifying the SAS. + Some users may bypass the required comparison step, because they just + want to be done with the pairing. + + An advantage of PIN based processes is that they cannot be bypassed. + The user must enter the PIN before continuing. Also, once the PIN is + entered, everything is automatic. The user does not need to input + more data, or press any additional button. PIN based protocols would + be a great fit for the QR-code based interaction. One device would + display a QR code that contains the PIN. Once the QR code is scanned + by the other device, the process is automated. + + QR based PIN entry may be user friendly, but one of the arguments + developed in Section 4.1 still holds. Let's assume that an adversary + somehow obtains the PIN, maybe by scanning the QR code at a distance. + That adversary could mount MITM or impersonation attacks, and + compromise the pairing process. It is thus very important to ensure + that the PIN is only readable by the user doing the pairing. + + We could also argue that the SAS bypass failure mode may be mitigated + by specific user designs. For example, instead of just clicking OK, + the user could be required to enter the SAS displayed by the other + device. This requires about the same interactions as a PIN based + process, and it would be slightly safer because the SAS does not have + to be kept secret once the keys have been exchanged. + + If we summarize the debate, we see that both SAS and PIN based + solutions have failure modes depending on implementations. In the + SAS mode, the failure happens when the UI does not force the user to + copy the PIN and relies on a simple "OK to continue" dialog. In the + PIN mode, the failure happens when the device fails to generate a + random PIN for each session, and comes pre-programmed with a simple + static PIN of "0000" or "0001". + 5. Resist Cryptographic Attacks It is tempting to believe that once two peers are connected, they could create a secret with a few simple steps, such as for example (1) exchange two nonces, (2) hash the concatenation of these nonces with the shared secret that is about to be established, (3) display a short authentication string composed of a short version of that hash on each device, and (4) verify that the two values match. This naive approach might yield the following sequence of messages: @@ -368,21 +427,21 @@ <-- nB nA --> verifies h_a == hash(s|nA) Computes Computes h = hash(s|nA|nB) h = hash(s|nA|nB) Displays short Displays short version of h version of h Alice will only disclose nA after having confirmation from Bob that hash(nA) has been received. At that point, Eve has a problem. She - can still forge the values of the nonces but she needs to pick the + can still forge the values of the nonces, but she needs to pick the nonce nA' before the actual value of nA has been disclosed. Eve would still have a random chance of fooling Alice and Bob, but it will be a very small chance: one in a million if the short authentication string is made of 6 digits, even fewer if that string is longer. Nguyen et al. [NR11] survey these protocols and compare them with respect to the amount of necessary user interaction and the computation time needed on the devices. The authors state that such a protocol is optimal with respect to user interaction if it suffices @@ -624,53 +683,58 @@ 13. Informative References [BTLEPairing] Bluetooth SIG, "Bluetooth Low Energy Security Overview", 2016, . [I-D.ietf-dnssd-pairing] Huitema, C. and D. Kaiser, "Device Pairing Using Short - Authentication Strings", draft-ietf-dnssd-pairing-02 (work - in progress), July 2017. + Authentication Strings", draft-ietf-dnssd-pairing-03 (work + in progress), September 2017. [I-D.ietf-dnssd-privacy] Huitema, C. and D. Kaiser, "Privacy Extensions for DNS- - SD", draft-ietf-dnssd-privacy-02 (work in progress), July - 2017. + SD", draft-ietf-dnssd-privacy-04 (work in progress), April + 2018. [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. + [K17] Kaiser, D., "Efficient Privacy-Preserving + Configurationless Service Discovery Supporting Multi-Link + Networks", 2017, + . + [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 Security, Mountain View, CA, January 2009. [NR11] Nguyen, L. and A. Roscoe, "Authentication protocols based on low-bandwidth unspoofable channels: a comparative survey", DOI: 10.3233/JCS-2010-0403, Journal of Computer Security, Volume 19 Issue 1, Pages 139-201, January 2011. [NS1978] Needham, R. and M. Schroeder, ". Using encryption for authentication in large networks of computers", Communications of the ACM 21 (12): 993-999, DOI: 10.1145/359657.359659, December 1978. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, - DOI 10.17487/RFC2104, February 1997, . + DOI 10.17487/RFC2104, February 1997, + . [RFC5705] Rescorla, E., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, March 2010, . [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, DOI 10.17487/RFC6151, March 2011, . @@ -688,22 +752,20 @@ [WPS] Wi-Fi Alliance, "Wi-Fi Protected Setup", 2016, . [XKCD936] Munroe, R., "XKCD: Password Strength", 2011, . Authors' Addresses Daniel Kaiser - University of Konstanz - Konstanz 78457 - Germany - - Email: daniel.kaiser@uni-konstanz.de + Esch-sur-Alzette 4360 + Luxembourg + Email: daniel@kais3r.de Christian Huitema Private Octopus Inc. Friday Harbor, WA 98250 U.S.A. Email: huitema@huitema.net