--- 1/draft-ietf-dnssd-pairing-info-01.txt 2018-10-23 01:13:36.513565009 -0700 +++ 2/draft-ietf-dnssd-pairing-info-02.txt 2018-10-23 01:13:36.553565966 -0700 @@ -1,19 +1,19 @@ Network Working Group D. Kaiser Internet-Draft Intended status: Informational C. Huitema -Expires: October 22, 2018 Private Octopus Inc. - April 20, 2018 +Expires: April 26, 2019 Private Octopus Inc. + October 23, 2018 Device Pairing Design Issues - draft-ietf-dnssd-pairing-info-01 + draft-ietf-dnssd-pairing-info-02 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. @@ -26,21 +26,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 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 October 22, 2018. + This Internet-Draft will expire on April 26, 2019. Copyright Notice 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -52,54 +52,56 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Document Organization . . . . . . . . . . . . . . . . . . 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.3. Short Range Communication . . . . . . . . . . . . . . . . 6 4.4. Short Authentication Strings . . . . . . . . . . . . . . 6 4.5. Revisiting the PIN versus SAS discussion . . . . . . . . 7 5. Resist Cryptographic Attacks . . . . . . . . . . . . . . . . 8 - 6. Privacy Requirements . . . . . . . . . . . . . . . . . . . . 10 + 6. Privacy Requirements . . . . . . . . . . . . . . . . . . . . 11 7. Using TLS . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. QR codes . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. Intra User Pairing and Transitive Pairing . . . . . . . . . . 14 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 13. Informative References . . . . . . . . . . . . . . . . . . . 15 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 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, e.g. PGP, or -- without using global identities -- by device pairing. The general pairing requirement is easy to state: establish a trust relation between two entities in a secure manner. But details matter, and in this section we explore the detailed requirements that will guide the design of a pairing protocol. This document does not specify an actual pairing protocol, but it served as the basis for the design of the pairing protocol developed - for DNS-SD privacy [I-D.ietf-dnssd-pairing]. + for DNS-SD privacy [I-D.ietf-dnssd-pairing]. The requirement of a + pairing system for private discovery are analyzed in part in + [I-D.ietf-dnssd-prireq]. 1.1. Document Organization NOTE TO RFC EDITOR: remove or rewrite this section before publication. This document results from a split of an earlier pairing draft that contained two parts. The first part, presented the pairing need, and the list of requirements that shall be met. The second part presented the design is the actual specification of the protocol. @@ -683,22 +684,27 @@ 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-03 (work - in progress), September 2017. + Authentication Strings", draft-ietf-dnssd-pairing-04 (work + in progress), April 2018. + + [I-D.ietf-dnssd-prireq] + Huitema, C., "DNS-SD Privacy and Security Requirements", + draft-ietf-dnssd-prireq-00 (work in progress), September + 2018. [I-D.ietf-dnssd-privacy] Huitema, C. and D. Kaiser, "Privacy Extensions for DNS- 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.