draft-ietf-dnssd-pairing-info-01.txt   draft-ietf-dnssd-pairing-info-02.txt 
Network Working Group D. Kaiser Network Working Group D. Kaiser
Internet-Draft Internet-Draft
Intended status: Informational C. Huitema Intended status: Informational C. Huitema
Expires: October 22, 2018 Private Octopus Inc. Expires: April 26, 2019 Private Octopus Inc.
April 20, 2018 October 23, 2018
Device Pairing Design Issues Device Pairing Design Issues
draft-ietf-dnssd-pairing-info-01 draft-ietf-dnssd-pairing-info-02
Abstract Abstract
This document discusses issues and problems occuring in the design of This document discusses issues and problems occuring in the design of
device pairing mechanism. It presents experience with existing device pairing mechanism. It presents experience with existing
pairing systems and general user interaction requirements to make the pairing systems and general user interaction requirements to make the
case for "short authentication strings". It then reviews the design case for "short authentication strings". It then reviews the design
of cryptographic algorithms designed to maximise the robustness of of cryptographic algorithms designed to maximise the robustness of
the short authentication string mechanisms, as well as implementation the short authentication string mechanisms, as well as implementation
considerations such as integration with TLS. considerations such as integration with TLS.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 26, 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
skipping to change at page 2, line 17 skipping to change at page 2, line 17
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Document Organization . . . . . . . . . . . . . . . . . . 3 1.1. Document Organization . . . . . . . . . . . . . . . . . . 3
2. Protocol Independent Secure Pairing . . . . . . . . . . . . . 3 2. Protocol Independent Secure Pairing . . . . . . . . . . . . . 3
3. Identity Assurance . . . . . . . . . . . . . . . . . . . . . 4 3. Identity Assurance . . . . . . . . . . . . . . . . . . . . . 4
4. Manual Authentication . . . . . . . . . . . . . . . . . . . . 4 4. Manual Authentication . . . . . . . . . . . . . . . . . . . . 4
4.1. Short PIN Proved Inadequate . . . . . . . . . . . . . . . 4 4.1. Short PIN Proved Inadequate . . . . . . . . . . . . . . . 4
4.2. Push Buttons Just Work, But Are Insecure . . . . . . . . 5 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.4. Short Authentication Strings . . . . . . . . . . . . . . 6
4.5. Revisiting the PIN versus SAS discussion . . . . . . . . 7 4.5. Revisiting the PIN versus SAS discussion . . . . . . . . 7
5. Resist Cryptographic Attacks . . . . . . . . . . . . . . . . 8 5. Resist Cryptographic Attacks . . . . . . . . . . . . . . . . 8
6. Privacy Requirements . . . . . . . . . . . . . . . . . . . . 10 6. Privacy Requirements . . . . . . . . . . . . . . . . . . . . 11
7. Using TLS . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Using TLS . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. QR codes . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. QR codes . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Intra User Pairing and Transitive Pairing . . . . . . . . . . 14 9. Intra User Pairing and Transitive Pairing . . . . . . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
13. Informative References . . . . . . . . . . . . . . . . . . . 15 13. Informative References . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
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 be aware of the host's presence. The messages and ideally should not be aware of the host's presence. The
necessary relationship between host and peer can be established by a necessary relationship between host and peer can be established by a
centralized service, e.g. a certificate authority, by a web of trust, centralized service, e.g. a certificate authority, by a web of trust,
e.g. PGP, or -- without using global identities -- by device e.g. PGP, or -- without using global identities -- by device
pairing. pairing.
The general pairing requirement is easy to state: establish a trust The general pairing requirement is easy to state: establish a trust
relation between two entities in a secure manner. But details relation between two entities in a secure manner. But details
matter, and in this section we explore the detailed requirements that matter, and in this section we explore the detailed requirements that
will guide the design of a pairing protocol. will guide the design of a pairing protocol.
This document does not specify an actual pairing protocol, but it This document does not specify an actual pairing protocol, but it
served as the basis for the design of the pairing protocol developed 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 1.1. Document Organization
NOTE TO RFC EDITOR: remove or rewrite this section before NOTE TO RFC EDITOR: remove or rewrite this section before
publication. publication.
This document results from a split of an earlier pairing draft that This document results from a split of an earlier pairing draft that
contained two parts. The first part, presented the pairing need, and contained two parts. The first part, presented the pairing need, and
the list of requirements that shall be met. The second part the list of requirements that shall be met. The second part
presented the design is the actual specification of the protocol. presented the design is the actual specification of the protocol.
skipping to change at page 15, line 23 skipping to change at page 15, line 42
13. Informative References 13. Informative References
[BTLEPairing] [BTLEPairing]
Bluetooth SIG, "Bluetooth Low Energy Security Overview", Bluetooth SIG, "Bluetooth Low Energy Security Overview",
2016, 2016,
<https://developer.bluetooth.org/TechnologyOverview/Pages/ <https://developer.bluetooth.org/TechnologyOverview/Pages/
LE-Security.aspx>. LE-Security.aspx>.
[I-D.ietf-dnssd-pairing] [I-D.ietf-dnssd-pairing]
Huitema, C. and D. Kaiser, "Device Pairing Using Short Huitema, C. and D. Kaiser, "Device Pairing Using Short
Authentication Strings", draft-ietf-dnssd-pairing-03 (work Authentication Strings", draft-ietf-dnssd-pairing-04 (work
in progress), September 2017. 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] [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.miers-tls-sas] [I-D.miers-tls-sas]
Miers, I., Green, M., and E. Rescorla, "Short Miers, I., Green, M., and E. Rescorla, "Short
Authentication Strings for TLS", draft-miers-tls-sas-00 Authentication Strings for TLS", draft-miers-tls-sas-00
(work in progress), February 2014. (work in progress), February 2014.
 End of changes. 9 change blocks. 
12 lines changed or deleted 19 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/