draft-ietf-dnssd-pairing-01.txt   draft-ietf-dnssd-pairing-02.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: September 8, 2017 University of Konstanz Expires: January 4, 2018 University of Konstanz
March 7, 2017 July 3, 2017
Device Pairing Using Short Authentication Strings Device Pairing Using Short Authentication Strings
draft-ietf-dnssd-pairing-01.txt draft-ietf-dnssd-pairing-02.txt
Abstract Abstract
This document proposes a device pairing mechanism that establishes a This document proposes a device pairing mechanism that establishes a
relationship between two devices by agreeing on a secret and manually relationship 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 42 skipping to change at page 1, line 42
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 September 8, 2017. This Internet-Draft will expire on January 4, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 23 skipping to change at page 2, line 23
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Document Organization . . . . . . . . . . . . . . . . . . 4 1.2. Document Organization . . . . . . . . . . . . . . . . . . 4
2. Problem Statement and Requirements . . . . . . . . . . . . . 4 2. Problem Statement and Requirements . . . . . . . . . . . . . 4
2.1. Secure Pairing Over Internet Connections . . . . . . . . 4 2.1. Secure Pairing Over Internet Connections . . . . . . . . 4
2.2. Identity Assurance . . . . . . . . . . . . . . . . . . . 5 2.2. Identity Assurance . . . . . . . . . . . . . . . . . . . 5
2.3. Adequate User Interface . . . . . . . . . . . . . . . . . 5 2.3. Manual Authentication . . . . . . . . . . . . . . . . . . 5
2.3.1. Short PIN Proved Inadequate . . . . . . . . . . . . . 5 2.3.1. Short PIN Proved Inadequate . . . . . . . . . . . . . 5
2.3.2. Push Buttons Just Work, But Are Insecure . . . . . . 6 2.3.2. Push Buttons Just Work, But Are Insecure . . . . . . 6
2.3.3. Short Range Communication . . . . . . . . . . . . . . 6 2.3.3. Short Range Communication . . . . . . . . . . . . . . 6
2.3.4. Short Authentication Strings . . . . . . . . . . . . 7 2.3.4. Short Authentication Strings . . . . . . . . . . . . 7
2.4. Resist Cryptographic Attacks . . . . . . . . . . . . . . 8 2.4. Resist Cryptographic Attacks . . . . . . . . . . . . . . 8
2.5. Privacy Requirements . . . . . . . . . . . . . . . . . . 10 2.5. Privacy Requirements . . . . . . . . . . . . . . . . . . 11
2.6. Using TLS . . . . . . . . . . . . . . . . . . . . . . . . 11 2.6. Using TLS . . . . . . . . . . . . . . . . . . . . . . . . 11
2.7. QR codes . . . . . . . . . . . . . . . . . . . . . . . . 12 2.7. QR codes . . . . . . . . . . . . . . . . . . . . . . . . 12
2.8. Intra User Pairing and Transitive Pairing . . . . . . . . 13 2.8. Intra User Pairing and Transitive Pairing . . . . . . . . 14
3. Design of the Pairing Mechanism . . . . . . . . . . . . . . . 14 3. Design of the Pairing Mechanism . . . . . . . . . . . . . . . 15
3.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2. Agreement . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2. Agreement . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3. Authentication . . . . . . . . . . . . . . . . . . . . . 15 3.3. Authentication . . . . . . . . . . . . . . . . . . . . . 16
3.4. Public Authentication Keys . . . . . . . . . . . . . . . 16 3.4. Authenticating Public Keys . . . . . . . . . . . . . . . 16
4. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2. Agreement and Authentication . . . . . . . . . . . . . . 16 4.2. Agreement and Authentication . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . 20 8.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
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,
skipping to change at page 3, line 42 skipping to change at page 3, line 42
data, which can be used by both parties at any later point in data, which can be used by both parties at any later point in
time to generate identifiers for re-discovery and to prove the time to generate identifiers for re-discovery and to prove the
authenticity of the pairing. The pairing data can e.g. be a authenticity of the pairing. The pairing data can e.g. be a
shared secret agreed upon via a Diffie-Hellman key exchange. shared secret agreed upon via a Diffie-Hellman key exchange.
3. Authenticating pairing data. Since in most cases the messages 3. Authenticating pairing data. Since in most cases the messages
necessary to agree upon pairing data are send over an insecure necessary to agree upon pairing data are send over an insecure
channel, means that guarantee the authenticity of these messages channel, means that guarantee the authenticity of these messages
are necessary; otherwise the pairing data is in turn not suited are necessary; otherwise the pairing data is in turn not suited
as a means for a later proof of authenticity. For the proposed as a means for a later proof of authenticity. For the proposed
pairing mechanism we use manual interaction involving an SAS pairing mechanism we use manual authentication involving an SAS
(short authentication string) to proof the authenticity of the (short authentication string) to proof the authenticity of the
pairing data. pairing data.
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
skipping to change at page 5, line 20 skipping to change at page 5, line 20
established with Bob, and not with some interloper like Eve or established with Bob, and not with some interloper like Eve or
Nessie. Providing this assurance requires designing both the Nessie. Providing this assurance requires designing both the
protocol and the user interface (UI) with care. protocol and the user interface (UI) with care.
Consider for example an attack in which Eve tricks Alice into Consider for example an attack in which Eve tricks Alice into
engaging in a pairing process while pretending to be Bob. Alice must engaging in a pairing process while pretending to be Bob. Alice must
be able to discover that something is wrong, and refuse to establish be able to discover that something is wrong, and refuse to establish
the pairing. The parties engaged in the pairing must at least be the pairing. The parties engaged in the pairing must at least be
able to verify their identities, respectively. able to verify their identities, respectively.
2.3. Adequate User Interface 2.3. Manual Authentication
Because the pairing protocol is executed without prior knowledge, it Because the pairing protocol is executed without prior knowledge, it
is typically vulnerable to "Man-in-the-middle" attacks. While Alice is typically vulnerable to "Man-in-the-Middle" attacks. While Alice
is trying to establish a pairing with Bob, Eve positions herself in is trying to establish a pairing with Bob, Eve positions herself in
the middle. Instead of getting a pairing between Alice and Bob, both the middle. Instead of getting a pairing between Alice and Bob, both
Alice and Bob get paired with Eve. This requires specific features in Alice and Bob get paired with Eve. This requires specific features in
the protocol to detect man-in-the-middle attacks, and if possible the protocol to detect Man-in-the-Middle attacks, and if possible
resist them. The reference [NR11] analyzes the various proposals to resist them.
solve this problem, and in this document, we present a layman
description of these issues in Section 2.4. The various protocols This section discusses existing techniques that are used in practice,
proposed in the literature impose diverse constraints on the UI and Section 2.4 provides a layman description of the MiTM problem and
interface, which we will review here. countermeasures. A more in depth exploration of manually
authenticated pairing protocols may be found in [NR11] and [thesis
kaiserd].
2.3.1. Short PIN Proved Inadequate 2.3.1. Short PIN Proved Inadequate
The initial Bluetooth pairing protocol relied on a four digit PIN, The initial Bluetooth pairing protocol relied on a four digit PIN,
displayed by one of the devices to be paired. The user would read 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 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 used in a Password Authenticated Key Exchange. Wi-Fi Protected Setup
[WPS] offered a similar option. There were various attacks against [WPS] offered a similar option. There were various attacks against
the actual protocol; some of the problems were caused by issues in the actual protocol; some of the problems were caused by issues in
the protocol, but most were tied to the usage of short PINs. the protocol, but most were tied to the usage of short PINs.
skipping to change at page 6, line 22 skipping to change at page 6, line 22
It is interesting to note that the latest revisions of the Bluetooth It is interesting to note that the latest revisions of the Bluetooth
Pairing protocol [BTLEPairing] do not include the short PIN option Pairing protocol [BTLEPairing] do not include the short PIN option
anymore. The PIN entry methods have been superseded by the simple anymore. The PIN entry methods have been superseded by the simple
"just works" method for devices without displays, and by a procedure "just works" method for devices without displays, and by a procedure
based on an SAS (short authentication string) when displays are based on an SAS (short authentication string) when displays are
available. available.
A further problem with these PIN based approaches is that -- in A further problem with these PIN based approaches is that -- in
contrast to SASes -- the PIN is a secret instrumental in the security contrast to SASes -- the PIN is a secret instrumental in the security
algorithm. To guarantee security, this PIN would have to be algorithm. To guarantee security, this PIN would have to be
transmitted via a secure out of band channel. transmitted via a secure out-of-band channel.
2.3.2. Push Buttons Just Work, But Are Insecure 2.3.2. Push Buttons Just Work, But Are Insecure
Some devices are unable to input or display any code. The industry Some devices are unable to input or display any code. The industry
more or less converged on a "push button" solution. When the button more or less converged on a "push button" solution. When the button
is pushed, devices enter a "pairing" mode, during which they will is pushed, devices enter a "pairing" mode, during which they will
accept a pairing request from whatever other device connects to them. accept a pairing request from whatever other device connects to them.
The Bluetooth Pairing protocol [BTLEPairing] denotes that as the The Bluetooth Pairing protocol [BTLEPairing] denotes that as the
"just works" method. It does indeed work, and if the pairing "just works" method. It does indeed work, and if the pairing
succeeds the devices will later be able to use the pairing keys to succeeds the devices will later be able to use the pairing keys to
authenticate connections. However, the procedure does not provide authenticate connections. However, the procedure does not provide
any protection against MITM attacks during the pairing process. The any protection against MitM attacks during the pairing process. The
only protection is that pushing the button will only allow pairing only protection is that pushing the button will only allow pairing
for a limited time, thus limiting the opportunities of attacks. for a limited time, thus limiting the opportunities of attacks.
As we set up to define a pairing protocol with a broad set of As we set up to define a pairing protocol with a broad set of
applications, we cannot limit ourselves to an insecure "push button" applications, we cannot limit ourselves to an insecure "push button"
method. But we probably need to allow for a mode of operation that method. But we probably need to allow for a mode of operation that
works for input-limited and display limited devices. works for input-limited and display limited devices.
2.3.3. Short Range Communication 2.3.3. Short Range Communication
There have been several attempts to define pairing protocols that use Many pairing protocols that use out-of-band channels have been
"secure channels." Most of them are based on short range defined. Most of them are based on short range communication
communication systems, where the short range limits the feasibility systems, where the short range limits the feasibility for attackers
for attackers to access the channels. Example of such limited to access the channels. Example of such limited systems include for
systems include for example: example:
o QR codes, displayed on the screen of one device, and read by the o QR codes, displayed on the screen of one device, and read by the
camera of the other device. camera of the other device.
o Near Field Communication (NFC) systems, which provides wireless o Near Field Communication (NFC) systems, which provides wireless
communication with a very short range. communication with a very short range.
o Sound systems, in which one systems emits a sequence of sounds or o Sound systems, in which one systems emits a sequence of sounds or
ultrasounds that is picked by the microphone of the other system. ultrasounds that is picked by the microphone of the other system.
A common problem with these solutions is that they require special A common problem with these solutions is that they require special
capabilities that may not be present in every device. Another capabilities that may not be present in every device. Another
problem is that they are often one-way channels. Yet another problem problem is that they are often one-way channels.
is that the side channel is not necessarily secret. QR codes could
be read by third parties. Powerful radio antennas might be able to
interfere with NFC. Sensitive microphones might pick the sounds. We
will discuss the specific case of QR codes in Section 2.7.
2.3.4. Short Authentication Strings
The evolving pairing protocols seem to converge towards a "display The pairing protocols should not rely on the secrecy of the out-of-
and compare" method. This is in line with academic studies, such as band channels; most of these out-of-band channels do not provide
[KFR09] or [USK11], and points to a very simple scenario: confidentiality. QR codes could be read by third parties. Powerful
radio antennas might be able to interfere with NFC. Sensitive
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 2.7.
1. Alice initiates pairing 2.3.4. Short Authentication Strings
2. Bob selects Alice's device from a list. The evolving pairing protocols seem to converge towards using Short
Authentication Strins 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:
3. Alice and Bob compare displayed strings that represent a 1. Alice and Bob compare displayed strings that represent a
fingerprint of the key. fingerprint of the afore exchanged pairing key.
4. If the strings match, Alice and Bob accept the pairing. 2. If the strings match, Alice and Bob accept the pairing.
Most existing pairing protocols display the fingerprint of the key as Most existing pairing protocols display the fingerprint of the key as
a 6 or 7 digit numbers. Usability studies show that this method a 6 or 7 digit numbers. Usability studies show that this method
gives good results, with little risk that users mistakenly accept two gives good results, with little risk that users mistakenly accept two
different numbers as matching. However, the authors of [USK11] found different numbers as matching. However, the authors of [USK11] found
that people had more success comparing computer generated sentences that people had more success comparing computer generated sentences
than comparing numbers. This is in line with the argument in than comparing numbers. This is in line with the argument in
[XKCD936] to use sequences of randomly chosen common words as [XKCD936] to use sequences of randomly chosen common words as
passwords. On the other hand, standardizing strings is more passwords. On the other hand, standardizing strings is more
complicated than standardizing numbers. We would need to specify a complicated than standardizing numbers. We would need to specify a
skipping to change at page 8, line 30 skipping to change at page 8, line 33
<-- g^xB <-- g^xB
nA --> nA -->
<-- nB <-- nB
Computes Computes Computes Computes
s = g^xAxB s = g^xAxB s = g^xAxB s = g^xAxB
h = hash(s|nA|nB) h = hash(s|nA|nB) h = hash(s|nA|nB) h = hash(s|nA|nB)
Displays short Displays short Displays short Displays short
version of h version of h version of h version of h
If the two short hashes match, Alice and Bob are supposedly assured If the two short hashes match, Alice and Bob are supposedly assured
that they have computed the same secret, but there is a problem. The that they have computed the same secret, but there is a problem.
exchange may not deter a smart attacker in the middle. Let's redraw Let's redraw the same message flow, this time involving the attacker
the same message flow, this time involving Eve: Eve:
Alice Eve Bob Alice Eve Bob
g^xA --> g^xA -->
g^xA'--> g^xA'-->
<-- g^xB <-- g^xB
<--g^xB' <--g^xB'
nA --> nA -->
nA --> nA -->
<-- nB <-- nB
Picks nB' Picks nB'
smartly smartly
<--nB' <--nB'
Computes Computes Computes Computes
s' = g^xAxB' s" = g^xA'xB s' = g^xAxB' s" = g^xA'xB
h' = hash(s|nA|nB') h" = hash(s"|nA|nB) h' = hash(s'|nA|nB') h" = hash(s"|nA|nB)
Displays short Displays short Displays short Displays short
version of h' version of h" version of h' version of h"
Let's now assume that, in order to pick the nonce nB' smartly, Eve In order to pick a nonce nB' that circumvents this naive security
runs the following algorithm: measure, Eve runs the following algorithm:
s' = g^xAxB' s' = g^xAxB'
s" = g^xA'xB s" = g^xA'xB
repeat repeat
pick a new version of nB' pick a new version of nB'
h' = hash(s|nA|nB') h' = hash(s'|nA|nB')
h" = hash(s"|nA|nB) h" = hash(s"|nA|nB)
until the short version of h' until the short version of h'
matches the short version of h" matches the short version of h"
Of course, running this algorithm will, in theory, require as many Running this algorithm will take O(2^b) iterations on average
iterations as there are possible values of the short hash. But hash (assuming a uniform distribution), where b is the bit length of the
algorithms are fast, and it is possible to try millions of values in SAS. Since hash algorithms are fast, it is possible to try millions
less than a second. If the short string is made up of fewer than 6 of values in less than a second. If the short string is made up of
digits, Eve will find a matching nonce quickly, and Alice and Bob fewer than 6 digits, Eve will find a matching nonce quickly, and
will hardly notice the delay. Even if the matching string is as long Alice and Bob will hardly notice the delay. Even if the matching
as 8 letters, Eve will probably find a value where the short versions string is as long as 8 letters, Eve will probably find a value where
of h' and h" are close enough, e.g. start and end with the same two the short versions of h' and h" are close enough, e.g. start and end
or three letters. Alice and Bob may well be fooled. with the same two or three letters. Alice and Bob may well be
fooled.
Eve could also utilize the fact that she may freely choose the whole
input for the hash function and thus choose g^xA' and g^xB' so that
an arbitrary collision (birthday attack) instead of a second preimage
is sufficient for fooling Alice and Bob.
The classic solution to such problems is to "commit" a possible The classic solution to such problems is to "commit" a possible
attacker to a nonce before sending it. This commitment can be attacker to a nonce before sending it. This commitment can be
realized by a hash. In the modified exchange, Alice sends a secure realized by a hash. In the modified exchange, Alice sends a secure
hash of her nonce before sending the actual value: hash of her nonce before sending the actual value:
Alice Bob Alice Bob
g^xA --> g^xA -->
<-- g^xB <-- g^xB
skipping to change at page 10, line 32 skipping to change at page 11, line 11
secret as a key, since the HMAC construct has proven very robust over secret as a key, since the HMAC construct has proven very robust over
time. Then, we can constrain the size of the random numbers to be time. Then, we can constrain the size of the random numbers to be
exactly the same as the output of the hash function. Hash attacks exactly the same as the output of the hash function. Hash attacks
often require padding the input string with arbitrary data; often require padding the input string with arbitrary data;
restraining the size limits the likelyhood of such padding. restraining the size limits the likelyhood of such padding.
2.5. Privacy Requirements 2.5. Privacy Requirements
Pairing exposes a relation between several devices and their owners. Pairing exposes a relation between several devices and their owners.
Adversaries may attempt to collect this information, for example in Adversaries may attempt to collect this information, for example in
an attempt to track devices, their owners, or their "social graph". an attempt to track devices, their owners, or their social graph. It
It is often argued that pairing could be performed in a safe place, is often argued that pairing could be performed in a safe place, from
from which adversaries are assumed absent, but experience shows that which adversaries are assumed absent, but experience shows that such
such assumptions are often misguided. It is much safer to assumptions are often misguided. It is much safer to acknowledge the
acknowledge the privacy issues and design the pairing process privacy issues and design the pairing process accordingly.
accordingly.
In order to start the pairing process, devices must first discover In order to start the pairing process, devices must first discover
each other. We do not have the option of using the private discovery each other. We do not have the option of using the private discovery
protocol [I-D.ietf-dnssd-privacy] since the privacy of that protocol protocol [I-D.ietf-dnssd-privacy] since the privacy of that protocol
depends on a pre-existing pairing. In the simplest design, one of depends on a pre-existing pairing. In the simplest design, one of
the devices will announce a "friendly name" using DNS-SD. the devices will announce a user-friendly name using DNS-SD.
Adversaries could monitor the discovery protocol, and record that Adversaries could monitor the discovery protocol, and record that
name. An alternative would be for one device to announce a random name. An alternative would be for one device to announce a random
name, and communicate it to the other device via some private name, and communicate it to the other device via some private
channel. There is an obvious tradeoff here: friendly names are channel. There is an obvious tradeoff here: friendly names are
easier to use but less private than random names. We anticipate that easier to use but less private than random names. We anticipate that
different users will choose different tradeoffs, for example using different users will choose different tradeoffs, for example using
friendly names if they assume that the environment is "safe," and friendly names if they assume that the environment is safe, and using
using random names in public places. random names in public places.
During the pairing process, the two devices establish a connection During the pairing process, the two devices establish a connection
and validate a pairing secret. As discussed in Section 2.3, we have and validate a pairing secret. As discussed in Section 2.3, we have
to assume that adversaries can mount MITM attacks. The pairing to assume that adversaries can mount MitM attacks. The pairing
protocol can detect such attacks and resist them, but the attackers protocol can detect such attacks and resist them, but the attackers
will have access to all messages exchanged before validation is will have access to all messages exchanged before the validation is
performed. It is important to not exchange any privacy sensitive performed. It is important to not exchange any privacy sensitive
information before that validation. This includes, for example, the information before that validation. This includes, for example, the
identities of the parties or their public keys. identities of the parties or their public keys.
2.6. Using TLS 2.6. Using TLS
The pairing algorithms typically combine the establishment of a The pairing algorithms typically combine the establishment of a
shared secret through an [EC]DH exchange with the verification of shared secret through an [EC]DH exchange with the verification of
that secret through displaying and comparison of a "short that secret through displaying and comparing a "short authentication
authentication string" (SAS). As explained in Section 2.4, the string" (SAS). As explained in Section 2.4, the secure comparison
secure comparison requires a "commit before disclose" mechanism. requires a "commit before disclose" mechanism.
We have three possible designs: (1) create a pairing algorithm from We have three possible designs: (1) create a pairing algorithm from
scratch, specifying our own crypto exchanges; (2) use an [EC]DH scratch, specifying our own cryptographic protocol; (2) use an [EC]DH
version of TLS to negotiate a shared secret, export the key to the version of TLS to negotiate a shared secret, export the key to the
application as specified in [RFC5705], and implement the "commit application as specified in [RFC5705], and implement the "commit
before disclose" and SAS verification as part of the pairing before disclose" and SAS verification as part of the pairing
application; or, (3) use TLS, integrate the "commit before disclose" application; or, (3) use TLS, integrate the "commit before disclose"
and SAS verification as TLS extensions, and export the verified key and SAS verification as TLS extensions, and export the verified key
to the application as specified in [RFC5705]. to the application as specified in [RFC5705].
When faced with the same choice, the designers of ZRTP [RFC6189] When faced with the same choice, the designers of ZRTP [RFC6189]
chose to design a new protocol integrated in the general framework of chose to design a new protocol integrated in the general framework of
real time communications. We don't want to follow that path, and real time communications. We don't want to follow that path, and
skipping to change at page 12, line 26 skipping to change at page 13, line 7
QR codes are displayed as images. An adversary equipped with QR codes are displayed as images. An adversary equipped with
powerful cameras could read the QR code just as well as the pairing powerful cameras could read the QR code just as well as the pairing
parties. If the pairing protocol design embedded passwords or pins parties. If the pairing protocol design embedded passwords or pins
in the QR code, adversaries could access these data and compromise in the QR code, adversaries could access these data and compromise
the protocol. On the other hand, there are ways to use QR codes even the protocol. On the other hand, there are ways to use QR codes even
without assuming secrecy. without assuming secrecy.
QR codes could be used at two of the three stages of pairing: QR codes could be used at two of the three stages of pairing:
Discovering the peer device, and authenticating the shared secret. Discovering the peer device, and authenticating the shared secret.
Using QR codes provide advantages in both phases: Using QR codes provides advantages in both phases:
o Typical network based discovery involves interaction with two o Typical network based discovery involves interaction with two
devices. The device to be discovered is placed in "server" mode, devices. The device to be discovered is placed in "server" mode,
and waits for requests from the network. The device performing and waits for requests from the network. The device performing
the discovery retrieves a list of candidates from the network. the discovery retrieves a list of candidates from the network.
When there is more than one such candidate, the device user is When there is more than one such candidate, the device user is
expected to select the desired target from a list. In QR code expected to select the desired target from a list. In QR code
mode, the discovered device will display a QR code, which the user mode, the discovered device will display a QR code, which the user
will scan using the second device. The QR code will embed the will scan using the second device. The QR code will embed the
device's name, its IP address, and the port number of the pairing device's name, its IP address, and the port number of the pairing
skipping to change at page 13, line 49 skipping to change at page 14, line 30
# ### # #mm"#"#m " # ### # #mm"#"#m "
#mmmmm# #mm"#""m "m" #mmmmm# #mm"#""m "m"
Did the number match (Yes/No)? Did the number match (Yes/No)?
With the use of QR code, the pairing is established with little With the use of QR code, the pairing is established with little
reliance on user judgment, which is arguably safer. reliance on user judgment, which is arguably safer.
2.8. Intra User Pairing and Transitive Pairing 2.8. Intra User Pairing and Transitive Pairing
There are two usage modes for pairing: inter-users, and intra-user. There are two usage modes for pairing: inter-user, and intra-user.
Users have multiple devices. The simplest design is to not Users have multiple devices. The simplest design is to not
distinguish between pairing devices belonging to two users, e.g., distinguish between pairing devices belonging to two users, e.g.,
Alice's phone and Bob's phone, and devices belonging to the same Alice's phone and Bob's phone, and devices belonging to the same
user, e.g., Alice's phone and her laptop. This will most certainly user, e.g., Alice's phone and her laptop. This will most certainly
work, but it raises the problem of transitivity. If Bob needs to work, but it raises the problem of transitivity. If Bob needs to
interact with Alice, should he install just one pairing for "Alice interact with Alice, should he install just one pairing for "Alice
and Bob", or should he install four pairings between Alice phone and and Bob", or should he install four pairings between Alice phone and
laptop and Bob phone and laptop? Also, what happens if Alice gets a laptop and Bob phone and laptop? Also, what happens if Alice gets a
new phone? new phone?
skipping to change at page 15, line 32 skipping to change at page 16, line 13
1. The server displays its chosen instance name on its screen. 1. The server displays its chosen instance name on its screen.
2. The client performs a discovery of all the "pairing" servers 2. The client performs a discovery of all the "pairing" servers
available on the local network. This may result in the discovery available on the local network. This may result in the discovery
of several servers. of several servers.
3. Among these available "pairing servers" the client's user selects 3. Among these available "pairing servers" the client's user selects
the name that matches the name displayed by the server. the name that matches the name displayed by the server.
4. Per DNS-SD, the client then retrieves the SRV records of the 4. Per DNS-SD, the client then retrieves the SRV records of the
selected instance, select one of the document servers, retrieves selected instance, selects one of the discovered servers,
its A or AAAA records, and establishes the connection. retrieves its A or AAAA records, and establishes the connection.
3.2. Agreement 3.2. Agreement
Once the server has been selected, the client connects to it without Once the server has been selected, the client connects to it without
further user intervention. Client and server use this connection for further user intervention. Client and server use this connection for
exchanging data that allows them to agree on a shared secret by using exchanging data that allows them to agree on a shared secret by using
a cryptographic protocol that yields an SAS. We discussed design a cryptographic protocol that yields an SAS. We discussed design
aspects of such protocols in Section 2.4. aspects of such protocols in Section 2.4.
3.3. Authentication 3.3. Authentication
skipping to change at page 16, line 13 skipping to change at page 16, line 42
labeled "CANCEL". labeled "CANCEL".
Depending on whether QR codes are supported, the SAS may also be Depending on whether QR codes are supported, the SAS may also be
represented as QR code. Despite the fact that using QR codes to represented as QR code. Despite the fact that using QR codes to
represent the authentication string renders using longer represent the authentication string renders using longer
authentication strings feasible, we suggest to always generate an SAS authentication strings feasible, we suggest to always generate an SAS
during the agreement phase, because this makes realizations of the during the agreement phase, because this makes realizations of the
agreement phase and the authentication phase independent. Devices agreement phase and the authentication phase independent. Devices
may display the "real" name of the other device alongside the SAS. may display the "real" name of the other device alongside the SAS.
3.4. Public Authentication Keys 3.4. Authenticating Public Keys
[[TODO: Should we discuss public authentication keys whose [[TODO: Should we discuss verifying public keys using our pairing
fingerprints are verified during pairing?]] mechanism?]]
4. Solution 4. Solution
In the proposed pairing protocol, one of the devices acts as a In the proposed pairing protocol, one of the devices acts as a
"server", and the other acts as a "client". The server will publish "server", and the other acts as a "client". The server will publish
a "pairing service". The client will discover the service instance a "pairing service". The client will discover the service instance
during the discovery phase, as explained in Section 4.1. The pairing during the discovery phase, as explained in Section 4.1. The pairing
service itself is specified in Section 4.2. service itself is specified in Section 4.2.
4.1. Discovery 4.1. Discovery
The discovery uses DNS-SD [RFC6763] over mDNS [RFC6762]. The pairing The discovery uses DNS-SD [RFC6763] over mDNS [RFC6762]. The pairing
service is identified in DNS SD as "_pairing._tcp". When the pairing service is identified in DNS SD as "_pairing._tcp". When the pairing
service starts, the server starts publishing the chosen instance service starts, the server starts publishing the chosen instance
name. The client will discover that name and the corresponding name. The client will discover that name and the corresponding
connection parameters. connection parameters.
If QR code scanning is available as OOB channel, the discovery data If QR code scanning is available as out-of-band channel, the
is directly transmitted via QR codes instead of DNS-SD over mDNS. discovery data is directly transmitted via QR codes instead of DNS-SD
The QR data contains connection data otherwise found in the SRV and A over mDNS. The QR code data contains connection data otherwise found
or AAAA records: IPv4 or IPv6 address, port number, and optionally in the SRV and A or AAAA records: IPv4 or IPv6 address, port number,
host name. and optionally host name.
[[TODO: We should precisely specify the data layout of this QR code. [[TODO: We should precisely specify the data layout of this QR code.
It could either be the wire format of the corresponding resource It could either be the wire format of the corresponding resource
records (which would be easier for us), or a more efficient records (which would be easier for us), or a more efficient
representation. If we chose the wire format, we could use a fix name representation. If we chose the wire format, we could use a fix name
as instance name.]] as instance name.]]
4.2. Agreement and Authentication 4.2. Agreement and Authentication
The pairing protocol is built using TLS. The following description The pairing protocol is built using TLS. The following description
skipping to change at page 19, line 39 skipping to change at page 20, line 20
After receiving these messages, client and servers can orderly close After receiving these messages, client and servers can orderly close
the TLS connection, terminating the pairing exchange. the TLS connection, terminating the pairing exchange.
5. Security Considerations 5. Security Considerations
We need to consider two types of attacks against a pairing system: We need to consider two types of attacks against a pairing system:
attacks that occur during the establishment of the pairing relation, attacks that occur during the establishment of the pairing relation,
and attacks that occur after that establishment. and attacks that occur after that establishment.
During the establishment of the pairing system, we are concerned with During the establishment of the pairing system, we are concerned with
privacy attacks and with MITM attacks. Privacy attacks reveal the privacy attacks and with MitM attacks. Privacy attacks reveal the
existence of a pairing between two devices, which can be used to existence of a pairing between two devices, which can be used to
track graphs of relations. MITM attacks result in compromised track graphs of relations. MitM attacks result in compromised
pairing keys. The discovery procedures specified in Section 4.1 and pairing keys. The discovery procedures specified in Section 4.1 and
the authentication procedures specified in Section 4.2 are the authentication procedures specified in Section 4.2 are
specifically designed to mitigate such attacks, assuming that the specifically designed to mitigate such attacks, assuming that the
client and user are in close, physical proximity and thus a human client and user are in close, physical proximity and thus a human
user can visually acquire and verify the pairing information. user can visually acquire and verify the pairing information.
The establishment of the pairing results in the creation of a shared The establishment of the pairing results in the creation of a shared
secret. After the establishment of the pairing relation, attackers secret. After the establishment of the pairing relation, attackers
who compromise one of the devices could access the shared secret. who compromise one of the devices could access the shared secret.
This will enable them to either track or spoof the devices. To This will enable them to either track or spoof the devices. To
skipping to change at page 21, line 7 skipping to change at page 21, line 41
8.2. Informative References 8.2. 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-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-00 (work in progress), SD", draft-ietf-dnssd-privacy-01 (work in progress), March
October 2016. 2017.
[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.
[KFR09] Kainda, R., Flechais, I., and A. Roscoe, "Usability and [KFR09] Kainda, R., Flechais, I., and A. Roscoe, "Usability and
Security of Out-Of-Band Channels in Secure Device Pairing Security of Out-Of-Band Channels in Secure Device Pairing
Protocols", DOI: 10.1145/1572532.1572547, SOUPS Protocols", DOI: 10.1145/1572532.1572547, SOUPS
09, Proceedings of the 5th Symposium on Usable Privacy and 09, Proceedings of the 5th Symposium on Usable Privacy and
 End of changes. 42 change blocks. 
97 lines changed or deleted 109 lines changed or added

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