--- 1/draft-ietf-dnssd-pairing-04.txt 2018-10-15 22:13:07.733234758 -0700 +++ 2/draft-ietf-dnssd-pairing-05.txt 2018-10-15 22:13:07.761235424 -0700 @@ -1,18 +1,18 @@ Network Working Group C. Huitema Internet-Draft Private Octopus Inc. Intended status: Standards Track D. Kaiser -Expires: October 22, 2018 April 20, 2018 +Expires: April 18, 2019 October 15, 2018 Device Pairing Using Short Authentication Strings - draft-ietf-dnssd-pairing-04 + draft-ietf-dnssd-pairing-05 Abstract This document proposes a device pairing mechanism that establishes a relation 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. @@ -30,56 +30,56 @@ 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 18, 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 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. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 - 1.2. Document Organization . . . . . . . . . . . . . . . . . . 3 + 1.2. Document Organization . . . . . . . . . . . . . . . . . . 4 2. Protocol Specification . . . . . . . . . . . . . . . . . . . 4 2.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Agreement on a Shared Secret . . . . . . . . . . . . . . 5 2.3. Authentication . . . . . . . . . . . . . . . . . . . . . 6 3. Optional Use of QR Codes . . . . . . . . . . . . . . . . . . 8 3.1. Discovery Using QR Codes . . . . . . . . . . . . . . . . 8 3.2. Agreement with QR Codes . . . . . . . . . . . . . . . . . 9 3.3. Authentication with QR Codes . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 - 7.2. Informative References . . . . . . . . . . . . . . . . . 10 + 7.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 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 obtain information that could be used to identify the host. The necessary relation between host and peer @@ -120,20 +120,25 @@ The design of this protocol is based on the analysis of pairing protocols issues presented in [I-D.ietf-dnssd-pairing-info] and in [K17]. Many pairing scenarios involve cell phones equipped with cameras capable of reading a QR code. In these scenarios, scanning QR codes might be more user friendly than selecting names or reading short authentication strings from on screen menus. An optional use of QR codes in pairing protocols is presented is Section 3. + DNSSD privacy requirements are analyzed in [I-D.ietf-dnssd-prireq] + and scaling considerations are reviewed in + [I-D.ietf-dnssd-privacyscaling]. Further work on these two drafts + may lead to reviewing the mechanism proposed here. + 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 NOTE TO RFC EDITOR: remove or rewrite this section before publication. @@ -460,28 +465,38 @@ . [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, . 7.2. Informative References [I-D.ietf-dnssd-pairing-info] Kaiser, D. and C. Huitema, "Device Pairing Design Issues", - draft-ietf-dnssd-pairing-info-00 (work in progress), - September 2017. + draft-ietf-dnssd-pairing-info-01 (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.ietf-dnssd-privacyscaling] + Huitema, C., "DNS-SD Privacy Scaling Tradeoffs", draft- + ietf-dnssd-privacyscaling-00 (work in progress), September + 2018. + [K17] Kaiser, D., "Efficient Privacy-Preserving Configurationless Service Discovery Supporting Multi-Link Networks", 2017, . Authors' Addresses Christian Huitema Private Octopus Inc. Friday Harbor, WA 98250