draft-ietf-dnssd-pairing-04.txt   draft-ietf-dnssd-pairing-05.txt 
Network Working Group C. Huitema Network Working Group C. Huitema
Internet-Draft Private Octopus Inc. Internet-Draft Private Octopus Inc.
Intended status: Standards Track D. Kaiser 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 Device Pairing Using Short Authentication Strings
draft-ietf-dnssd-pairing-04 draft-ietf-dnssd-pairing-05
Abstract Abstract
This document proposes a device pairing mechanism that establishes a This document proposes a device pairing mechanism that establishes a
relation between two devices by agreeing on a secret and manually relation between two devices by agreeing on a secret and manually
verifying the secret's authenticity using an SAS (short verifying the secret's authenticity using an SAS (short
authentication string). Pairing has to be performed only once per authentication string). Pairing has to be performed only once per
pair of devices, as for a re-discovery at any later point in time, pair of devices, as for a re-discovery at any later point in time,
the exchanged secret can be used for mutual authentication. the exchanged secret can be used for mutual authentication.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://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 Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://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 publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Document Organization . . . . . . . . . . . . . . . . . . 3 1.2. Document Organization . . . . . . . . . . . . . . . . . . 4
2. Protocol Specification . . . . . . . . . . . . . . . . . . . 4 2. Protocol Specification . . . . . . . . . . . . . . . . . . . 4
2.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Agreement on a Shared Secret . . . . . . . . . . . . . . 5 2.2. Agreement on a Shared Secret . . . . . . . . . . . . . . 5
2.3. Authentication . . . . . . . . . . . . . . . . . . . . . 6 2.3. Authentication . . . . . . . . . . . . . . . . . . . . . 6
3. Optional Use of QR Codes . . . . . . . . . . . . . . . . . . 8 3. Optional Use of QR Codes . . . . . . . . . . . . . . . . . . 8
3.1. Discovery Using QR Codes . . . . . . . . . . . . . . . . 8 3.1. Discovery Using QR Codes . . . . . . . . . . . . . . . . 8
3.2. Agreement with QR Codes . . . . . . . . . . . . . . . . . 9 3.2. Agreement with QR Codes . . . . . . . . . . . . . . . . . 9
3.3. Authentication with QR Codes . . . . . . . . . . . . . . 9 3.3. Authentication with QR Codes . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
To engage in secure and privacy preserving communication, hosts need To engage in secure and privacy preserving communication, hosts need
to differentiate between authorized peers, which must both know about to differentiate between authorized peers, which must both know about
the host's presence and be able to decrypt messages sent by the host, 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 and other peers, which must not be able to decrypt the host's
messages and ideally should not obtain information that could be used messages and ideally should not obtain information that could be used
to identify the host. The necessary relation between host and peer to identify the host. The necessary relation between host and peer
skipping to change at page 3, line 38 skipping to change at page 3, line 38
The design of this protocol is based on the analysis of pairing The design of this protocol is based on the analysis of pairing
protocols issues presented in [I-D.ietf-dnssd-pairing-info] and in protocols issues presented in [I-D.ietf-dnssd-pairing-info] and in
[K17]. [K17].
Many pairing scenarios involve cell phones equipped with cameras Many pairing scenarios involve cell phones equipped with cameras
capable of reading a QR code. In these scenarios, scanning QR codes capable of reading a QR code. In these scenarios, scanning QR codes
might be more user friendly than selecting names or reading short might be more user friendly than selecting names or reading short
authentication strings from on screen menus. An optional use of QR authentication strings from on screen menus. An optional use of QR
codes in pairing protocols is presented is Section 3. 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 1.1. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. Document Organization 1.2. Document Organization
NOTE TO RFC EDITOR: remove or rewrite this section before NOTE TO RFC EDITOR: remove or rewrite this section before
publication. publication.
skipping to change at page 10, line 44 skipping to change at page 11, line 9
<https://www.rfc-editor.org/info/rfc6762>. <https://www.rfc-editor.org/info/rfc6762>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/info/rfc6763>. <https://www.rfc-editor.org/info/rfc6763>.
7.2. Informative References 7.2. Informative References
[I-D.ietf-dnssd-pairing-info] [I-D.ietf-dnssd-pairing-info]
Kaiser, D. and C. Huitema, "Device Pairing Design Issues", Kaiser, D. and C. Huitema, "Device Pairing Design Issues",
draft-ietf-dnssd-pairing-info-00 (work in progress), draft-ietf-dnssd-pairing-info-01 (work in progress), April
September 2017. 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] [I-D.ietf-dnssd-privacy]
Huitema, C. and D. Kaiser, "Privacy Extensions for DNS- Huitema, C. and D. Kaiser, "Privacy Extensions for DNS-
SD", draft-ietf-dnssd-privacy-04 (work in progress), April SD", draft-ietf-dnssd-privacy-04 (work in progress), April
2018. 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 [K17] Kaiser, D., "Efficient Privacy-Preserving
Configurationless Service Discovery Supporting Multi-Link Configurationless Service Discovery Supporting Multi-Link
Networks", 2017, Networks", 2017,
<http://nbn-resolving.de/urn:nbn:de:bsz:352-0-422757>. <http://nbn-resolving.de/urn:nbn:de:bsz:352-0-422757>.
Authors' Addresses Authors' Addresses
Christian Huitema Christian Huitema
Private Octopus Inc. Private Octopus Inc.
Friday Harbor, WA 98250 Friday Harbor, WA 98250
 End of changes. 8 change blocks. 
7 lines changed or deleted 22 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/