draft-ietf-dnssd-pairing-00.txt   draft-ietf-dnssd-pairing-01.txt 
Network Working Group C. Huitema Network Working Group C. Huitema
Internet-Draft Internet-Draft Private Octopus Inc.
Intended status: Standards Track D. Kaiser Intended status: Standards Track D. Kaiser
Expires: April 30, 2017 University of Konstanz Expires: September 8, 2017 University of Konstanz
October 27, 2016 March 7, 2017
Device Pairing Using Short Authentication Strings Device Pairing Using Short Authentication Strings
draft-ietf-dnssd-pairing-00.txt draft-ietf-dnssd-pairing-01.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 April 30, 2017. This Internet-Draft will expire on September 8, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . . . 4 2.2. Identity Assurance . . . . . . . . . . . . . . . . . . . 5
2.3. Adequate User Interface . . . . . . . . . . . . . . . . . 4 2.3. Adequate User Interface . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . 7 2.4. Resist Cryptographic Attacks . . . . . . . . . . . . . . 8
2.5. Privacy Requirements . . . . . . . . . . . . . . . . . . 10 2.5. Privacy Requirements . . . . . . . . . . . . . . . . . . 10
2.6. Using TLS . . . . . . . . . . . . . . . . . . . . . . . . 11 2.6. Using TLS . . . . . . . . . . . . . . . . . . . . . . . . 11
2.7. QR codes . . . . . . . . . . . . . . . . . . . . . . . . 11 2.7. QR codes . . . . . . . . . . . . . . . . . . . . . . . . 12
3. Design of the Pairing Mechanism . . . . . . . . . . . . . . . 12 2.8. Intra User Pairing and Transitive Pairing . . . . . . . . 13
3.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 13 3. Design of the Pairing Mechanism . . . . . . . . . . . . . . . 14
3.2. Agreement . . . . . . . . . . . . . . . . . . . . . . . . 13 3.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3. Authentication . . . . . . . . . . . . . . . . . . . . . 14 3.2. Agreement . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4. Intra User Pairing . . . . . . . . . . . . . . . . . . . 14 3.3. Authentication . . . . . . . . . . . . . . . . . . . . . 15
3.5. Pairing Data Synchronization . . . . . . . . . . . . . . 14 3.4. Public Authentication Keys . . . . . . . . . . . . . . . 16
3.6. Public Authentication Keys . . . . . . . . . . . . . . . 14 4. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 15 4.2. Agreement and Authentication . . . . . . . . . . . . . . 16
4.2. Agreement and Authentication . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
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 26 skipping to change at page 3, line 26
This document proposes a device pairing mechanism that provides human This document proposes a device pairing mechanism that provides human
operated devices with pairwise authenticated secrets, allowing mutual operated devices with pairwise authenticated secrets, allowing mutual
automatic re-discovery at any later point in time along with mutual automatic re-discovery at any later point in time along with mutual
private authentication. We especially care about privacy and user- private authentication. We especially care about privacy and user-
friendliness. friendliness.
The proposed pairing mechanism consists of three steps needed to The proposed pairing mechanism consists of three steps needed to
establish a relationship between a host and a peer: establish a relationship between a host and a peer:
1. Discovery of the peer device. The host needs a means to discover 1. Discovering the peer device. The host needs a means to discover
network parameters necessary to establish a connection to the network parameters necessary to establish a connection to the
peer. During this discovery process, neither the host nor the peer. During this discovery process, neither the host nor the
peer must disclose its presence. peer must disclose its presence.
2. Agreeing on pairing data. The devices have to agree on pairing 2. Agreeing on pairing data. The devices have to agree on pairing
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. Authenticate 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 interaction 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
NOTE TO RFC EDITOR: remove or rewrite this section before
publication.
This document is organized in two parts. The first part, composed of
Section 1, Section 2, and Section 3 presents the pairing need, the
list of requirements that shall be met, and the general design of the
solution. This first part is informational in nature. The second
part, composed of Section 4 and Section 5, is the actual
specification of the protocol.
In his early review, Steve Kent observed that the style of the first
part seems inappropriate for a standards track document, and
suggested that the two parts should be split into two documents, the
first part becoming an informational document, and the second
focusing on standard track specification of the protocol, making
reference to the informational document as appropriate. We, the
authors, will seek working group approval before performing this
split.
2. Problem Statement and Requirements 2. Problem Statement and Requirements
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
guide our design. guide our design.
2.1. Secure Pairing Over Internet Connections 2.1. Secure Pairing Over Internet Connections
Many pairing protocols have already been developed, in particular for Many pairing protocols have already been developed, in particular for
skipping to change at page 4, line 27 skipping to change at page 4, line 48
has evolved over several revisions towards better security and has evolved over several revisions towards better security and
usability [BTLEPairing]. The Wi-Fi Alliance defined the Wi-Fi usability [BTLEPairing]. The Wi-Fi Alliance defined the Wi-Fi
Protected Setup process to ease the setup of security-enabled Wi-Fi Protected Setup process to ease the setup of security-enabled Wi-Fi
networks in home and small office environments [WPS]. Other wireless networks in home and small office environments [WPS]. Other wireless
standards have defined or are defining similar protocols, tailored to standards have defined or are defining similar protocols, tailored to
specific technologies. specific technologies.
This specification defines a pairing protocol that is independent of This specification defines a pairing protocol that is independent of
the underlying technology. We simply make the hypothesis that the the underlying technology. We simply make the hypothesis that the
two parties engaged in the pairing can discover each other and then two parties engaged in the pairing can discover each other and then
establish connections over IP in order to agree a shared secret. establish connections over IP in order to agree on a shared secret.
[[TODO: Should we support certificates besides a shared secret?]] [[TODO: Should we support certificates besides a shared secret?]]
2.2. Identity Assurance 2.2. Identity Assurance
The parties in the pairing must be able to identify each other. To The parties in the pairing must be able to identify each other. To
put it simply, if Alice believes that she is establishing a pairing put it simply, if Alice believes that she is establishing a pairing
with Bob, she must somehow ensure that the pairing is actually with Bob, she must somehow ensure that the pairing is actually
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
skipping to change at page 5, line 45 skipping to change at page 6, line 21
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 had to be transmitted via algorithm. To guarantee security, this PIN would have to be
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
skipping to change at page 6, line 46 skipping to change at page 7, line 18
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. Yet another problem
is that the side channel is not necessarily secret. QR codes could is that the side channel is not necessarily secret. QR codes could
be read by third parties. Powerful radios antennas might be able to be read by third parties. Powerful radio antennas might be able to
interfere with NFC. Sensitive microphones might pick the sounds. We interfere with NFC. Sensitive microphones might pick the sounds. We
will discuss the specific case of QR codes in Section 2.7. will discuss the specific case of QR codes in Section 2.7.
2.3.4. Short Authentication Strings 2.3.4. Short Authentication Strings
The evolving pairing protocols seem to converge towards a "display The evolving pairing protocols seem to converge towards a "display
and compare" method. This is in line with academic studies, such as and compare" method. This is in line with academic studies, such as
[KFR09] or [USK11]. This points to a very simple scenario: [KFR09] or [USK11], and points to a very simple scenario:
1. Alice initiates pairing 1. Alice initiates pairing
2. Bob selects Alice's device from a list. 2. Bob selects Alice's device from a list.
3. Alice and Bob compare displayed strings that represent a 3. Alice and Bob compare displayed strings that represent a
fingerprint of the key. fingerprint of the key.
4. If the strings match, Alice and Bob accept the pairing. 4. 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 gives good a 6 or 7 digit numbers. Usability studies show that this method
results, with little risk that users mistakenly accept two different gives good results, with little risk that users mistakenly accept two
numbers as matching. However, the authors of [USK11] found that different numbers as matching. However, the authors of [USK11] found
people had more success comparing computer generated sentences than that people had more success comparing computer generated sentences
comparing numbers. This is in line with the argument in [XKCD936] to than comparing numbers. This is in line with the argument in
use sequences of randomly chosen common words as passwords. On the [XKCD936] to use sequences of randomly chosen common words as
other hand, standardizing strings is more complicated than passwords. On the other hand, standardizing strings is more
standardizing numbers. We would need to specify a list of common complicated than standardizing numbers. We would need to specify a
words, and the process to go from a binary fingerprint to a set of list of common words, and the process to go from a binary fingerprint
words. We would need to be concerned with internationalization to a set of words. We would need to be concerned with
issues, such as using different lists of words in German and in internationalization issues, such as using different lists of words
English. This could require negotiation of word lists or languages in German and in English. This could require the negotiation of word
inside the pairing protocols. lists or languages inside the pairing protocols.
In contrast, numbers are easy to specify, as in "take a 20 bit number In contrast, numbers are easy to specify, as in "take a 20 bit number
and display it as an integer using decimal notation." and display it as an integer using decimal notation".
2.4. Resist Cryptographic Attacks 2.4. Resist Cryptographic Attacks
It is tempting to believe that once two peers are connected, they It is tempting to believe that once two peers are connected, they
could create a secret with a few simple steps, such as for example could create a secret with a few simple steps, such as for example
exchange two nonces, hash the concatenation of these nonces with the (1) exchange two nonces, (2) hash the concatenation of these nonces
shared secret that is about to be established, display a short with the shared secret that is about to be established, (3) display a
authentication string composed of a short version of that hash on short authentication string composed of a short version of that hash
each device, and verify that the two values match. The sequence of on each device, and (4) verify that the two values match. This naive
messages would be something like: approach might yield the following sequence of messages:
Alice Bob Alice Bob
g^xA --> g^xA -->
<-- 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
skipping to change at page 8, line 38 skipping to change at page 8, line 51
<-- 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 to pick the nonce nB' smartly, Eve runs the Let's now assume that, in order to pick the nonce nB' smartly, Eve
following algorithm: 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 require in theory as many Of course, running this algorithm will, in theory, require as many
iterations as the possible values of the short hash. But hash iterations as there are possible values of the short hash. But hash
algorithms are fast, and it is possible to try millions of values in algorithms are fast, and it is possible to try millions of values in
less than a second. If the short string is made up of fewer than 6 less than a second. If the short string is made up of fewer than 6
digits, Eve will find a matching nonce quickly, and Alice and Bob digits, Eve will find a matching nonce quickly, and Alice and Bob
will hardly notice the delay. Even if the matching string is as long will hardly notice the delay. Even if the matching string is as long
as 8 letters, Eve will probably find a value where the short versions as 8 letters, Eve will probably find a value where the short versions
of h' and h" are close enough, e.g. start and end with the same two of h' and h" are close enough, e.g. start and end with the same two
or three letters. Alice and Bob may well be fooled. or three letters. Alice and Bob may well be fooled.
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
skipping to change at page 10, line 8 skipping to change at page 10, line 21
protocol must not have a better success probability then n one-shot protocol must not have a better success probability then n one-shot
attacks. attacks.
There is still a theoretical problem, if Eve has somehow managed to There is still a theoretical problem, if Eve has somehow managed to
"crack" the hash function. We build some "defense in depth" by some "crack" the hash function. We build some "defense in depth" by some
simple measures. In the design presented above, the hash "h_a" simple measures. In the design presented above, the hash "h_a"
depends on the shared secret "s", which acts as a "salt" and reduces depends on the shared secret "s", which acts as a "salt" and reduces
the effectiveness of potential attacks based on pre-computed the effectiveness of potential attacks based on pre-computed
catalogs. For simplicity, the design used a simple concatenation catalogs. For simplicity, the design used a simple concatenation
mechanism, but we could instead use a keyed-hash message mechanism, but we could instead use a keyed-hash message
authentication code (HMAC, [RFC2104], [RFC6151]), using the shared authentication code (HMAC [RFC2104], [RFC6151]), using the shared
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 is often argued that pairing could be performed in a safe place, It is often argued that pairing could be performed in a safe place,
from which adversaries are assumed absent, but experience shows that from which adversaries are assumed absent, but experience shows that
such assumptions are often misguided. It is much safer to such assumptions are often misguided. It is much safer to
acknowledge the privacy issues and design the pairing process acknowledge the 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 the 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 "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 random names in public places. using random names in public places.
skipping to change at page 11, line 44 skipping to change at page 12, line 4
SAS options in the common TLS packages. SAS options in the common TLS packages.
In our design, we will choose the middle ground option -- use TLS for In our design, we will choose the middle ground option -- use TLS for
[EC]DH, and implement the SAS verification as part of the pairing [EC]DH, and implement the SAS verification as part of the pairing
application. This minimizes dependencies on TLS packages to the application. This minimizes dependencies on TLS packages to the
availability of a key export API following [RFC5705]. We will need availability of a key export API following [RFC5705]. We will need
to specify the hash algorithm used for the SAS computation and to specify the hash algorithm used for the SAS computation and
validation, which carries some of the issues associated with validation, which carries some of the issues associated with
"designing our own crypto". One solution would be to use the same "designing our own crypto". One solution would be to use the same
hash algorithm negotiated by the TLS connection, but common TLS hash algorithm negotiated by the TLS connection, but common TLS
packages do not not always make this algorithm identifier available packages do not always make this algorithm identifier available
through standard APIs. A fallback solution is to specify a state of through standard APIs. A fallback solution is to specify a state of
the art keyed MAC algorithm. the art keyed MAC algorithm.
2.7. QR codes 2.7. QR codes
In Section 2.3.3, we reviewed a number of short range communication In Section 2.3.3, we reviewed a number of short range communication
systems that can be used to facilitate pairing. Out of these, QR systems that can be used to facilitate pairing. Out of these, QR
codes stand aside because most devices that can display a short codes stand aside because most devices that can display a short
string can also display the image of a QR code, and because many string can also display the image of a QR code, and because many
pairing scenarios involve cell phones equipped with cameras capable pairing scenarios involve cell phones equipped with cameras capable
of reading a QR code. of reading a QR code.
QR codes could be particularly useful when starting discovery. QR QR codes are displayed as images. An adversary equipped with
codes can encode an alphanumeric string, which could for example powerful cameras could read the QR code just as well as the pairing
encode the selected name of the pairing service. This would enable parties. If the pairing protocol design embedded passwords or pins
automatic discovery, and would be easier to use than reading the in the QR code, adversaries could access these data and compromise
random name of the day and matching it against the results of DNS-SD. the protocol. On the other hand, there are ways to use QR codes even
without assuming secrecy.
In addition to the instance name, a QR code could also be leveraged QR codes could be used at two of the three stages of pairing:
for authentication. It could encode an SAS or even a longer Discovering the peer device, and authenticating the shared secret.
authentication string. Transmitting the output of a cryptographic Using QR codes provide advantages in both phases:
hash function or HMAC via the OOB channel would make an offline
combinatorial search attack infeasible and thus allow to not sent the
commitment discussed in Section 2.4 saving a message. Further, if a
single device created both QR codes for discovery and verifcation,
respecitvely, and the other device scans these, the users could just
wait while both QRs are scanned subsequently as no user interaction
is necessary between these two scans (but it needs a QR scanner (app)
that support this). This could make the process feel like a single
user interaction.
But still, from a users point of view, scanning QR codes may not be o Typical network based discovery involves interaction with two
more efficient than visual verification of a short string. The user devices. The device to be discovered is placed in "server" mode,
has to take a picture of the QR code, which is arguably not simpler and waits for requests from the network. The device performing
than just "look at the number on the screen and tell me whether it is the discovery retrieves a list of candidates from the network.
the same as yours". When there is more than one such candidate, the device user is
expected to select the desired target from a list. In QR code
mode, the discovered device will display a QR code, which the user
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
service. The connection will be automatic, without relying on the
network discovery. This is arguably less error-prone and safer
than selecting from a network provided list.
In the case of a man-in-the-middle attack, the evaluation of the QR o SAS based agreement involves displaying a short string on each
code will fail. The "client" that took the picture will know that, device's display, and asking the user to verify that both devices
but the "server" will not. The user will still need to click some display the same string. In QR code mode, one device could
"Cancel" button on the server, which means that the process will not display a QR code containing this short string. The other device
be completely automated. could scan it and compare it to the locally computed version.
Because the procedure is automated, there is no dependency on the
user diligence at comparing the short strings.
Offering QR codes as an alternative to discovery and agreement is
straightforward. If QR codes are used, the pairing program on the
server side might display something like:
Please connect to "Bob's phone 359"
or scan the following QR code:
mmmmmmm m m mmmmmmm
# mmm # ## "m # mmm #
# ### # m" #" # ### #
#mmmmm# # m m #mmmmm#
mm m mm"## m mmm mm
" ##"mm m"# ####"m""#
#"mmm mm# m"# ""m" "m
mmmmmmm #mmm###mm# m
# mmm # m "mm " " "
# ### # " m # "## "#
#mmmmm# ### m"m m m
If Alice's device is capable of reading the QR code, it will just
scan it, establishes a connection, and run the pairing protocol.
After the protocol messages have been exchanged, Bob's device will
display a new QR code, encoding the hash code that should be matched.
The UI might look like this:
Please scan the following QR code,
or verify that your device displays
the number: 388125
mmmmmmm mmm mmmmmmm
# mmm # ""#m# # mmm #
# ### # "# # # ### #
#mmmmm# # m"m #mmmmm#
mmmmm mmm" m m m m m
#"m mmm#"#"#"#m m#m
""mmmmm"m#""#""m # m
mmmmmmm # "m"m "m"#"m
# mmm # mmmm m "# #"
# ### # #mm"#"#m "
#mmmmm# #mm"#""m "m"
Did the number match (Yes/No)?
With the use of QR code, the pairing is established with little
reliance on user judgment, which is arguably safer.
2.8. Intra User Pairing and Transitive Pairing
There are two usage modes for pairing: inter-users, and intra-user.
Users have multiple devices. The simplest design is to not
distinguish between pairing devices belonging to two users, e.g.,
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
work, but it raises the problem of transitivity. If Bob needs to
interact with Alice, should he install just one pairing for "Alice
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
new phone?
One tempting response is to devise a synchronization mechanism that
will let devices belonging to the same user share their pairings with
other users. But it is fairly obvious that such service will have to
be designed cautiously. The pairing system relies on shared secrets.
It is much easier to understand how to manage secrets shared between
exactly two parties than secrets shared with an unspecified set of
devices.
Transitive pairing raises similar issues. Suppose that a group of
users wants to collaborate. Will they need to set up a fully
connected graph of pairings using the simple peer-to-peer mechanism,
or could they use some transitive set, so that if Alice is connected
with Bob and Bob with Carol, Alice automatically gets connected with
Carol? Such transitive mechanisms could be designed, e.g. using a
variation of Needham-Scroeder symmetric key protocol [NS1978], but it
will require some extensive work. Groups can of course use simpler
solution, e.g., build some star topology.
Given the time required, intra-user pairing synchronization
mechanisms and transitive pairing mechanisms are left for further
study.
3. Design of the Pairing Mechanism 3. Design of the Pairing Mechanism
In this section we discuss the design of pairing protocols that use In this section we discuss the design of pairing protocols that use
manually verified short authentication strings (SAS), considering manually verified short authentication strings (SAS), considering
both security and user experience. both security and user experience.
We divide pairing in three parts: discovery, agreement, and We divide pairing in three parts: discovery, agreement, and
authentication, detailed in the following subsections. authentication, detailed in the following subsections.
3.1. Discovery 3.1. Discovery
The goal of the discovery phase is establishing a connection, which The goal of the discovery phase is establishing a connection, which
is later used to exchange the pairing data, between the two devices is later used to exchange the pairing data, between the two devices
that are about to be paired in an IP network without any a priori that are about to be paired in an IP network without any prior
knowledge and without publishing any private information. In knowledge and without publishing any private information. In
accordance with TLS, we refer to the device initiating the accordance with TLS, we refer to the device initiating the
cryptographic protocol as client, and to the other device as server; cryptographic protocol as client, and to the other device as server;
the server has to be discoverable by the client. the server has to be discoverable by the client.
Granting privacy during the discovery phase without relying on a Granting privacy during the discovery phase without relying on prior
priori knowledge demands another user interaction (besides the SAS knowledge demands another user interaction (besides the SAS
verification during the authentication phase). There are two verification during the authentication phase). There are two
possible ways of realizing this user interaction depending on whether possible ways of realizing this user interaction depending on whether
QR codes are supported or not. If QR codes are supported, the QR codes are supported or not. If QR codes are supported, the
discovery process can be independent of DNS-SD, because QR codes discovery process can be independent of DNS-SD, because QR codes
allow the transmission of a sufficient amount of data. Leveraging QR allow the transmission of a sufficient amount of data. Leveraging QR
codes, the discovery proceeds as follows. codes, the discovery proceeds as follows.
1. The server displays a QR code containing the clients A and AAAA 1. The server displays a QR code containing the instance name, the
resource records, and further the SRV resource record IPv4 or IPv6 address, and the port number of the service/
corresponding to the pairing service instance. A privacy
preserving instance name is not necessary, because this instance
is never published via an unsecured network.
2. The client scans the QR code retrieving the necessary information 2. The client scans the QR code retrieving the necessary information
for establishing a connection to the server. for establishing a connection to the server.
If QR codes are not supported, the discovery proceeds as follows. If QR codes are not supported, the discovery proceeds as follows.
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 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
selected instance, select one of the document servers, 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 14, line 23 skipping to change at page 16, line 13
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. Intra User Pairing 3.4. Public Authentication Keys
Users can pair their own devices in secure (home) networks without
any interaction using a special DNS-SD pairing service. Verification
methods where a single user holds both devices, e.g. synchronously
pressing buttons on both devices a few times, are also suitable.
Further, a secure OOB could be established by connecting two devices
with an USB channel. Pairing via an USB connection is also used by
some Bluetooth devices, e.g. when pairing a controller with a gaming
console.
[[TODO: elaborate]]
3.5. Pairing Data Synchronization
To make it sufficient for users to pair only one of their devices to
one of their friends devices while still being able to engage in
later communication with all of this friend's devices using any of
the own devices, we offer the possibility to synchronize pairing data
among devices of the same user. Pairing data synchronization is
performed via a special DNS-SD service (_pdsync._tls).
[[TODO: elaborate]]
3.6. Public Authentication Keys
[[TODO: Should we discuss public authentication keys whose [[TODO: Should we discuss public authentication keys whose
fingerprints are verified during pairing?]] fingerprints are verified during pairing?]]
4. Solution 4. Solution
[[TODO: elaborate on all subsections]]
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 OOB channel, the discovery data
is directly transmitted via QR codes instead of DNS-SD over mDNS. is directly transmitted via QR codes instead of DNS-SD over mDNS.
The QR data contains connection data otherwise found in the SRV and A
or AAAA records: IPv4 or IPv6 address, port number, 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
uses the presentation language defined in section 4 of [RFC5246]. uses the presentation language defined in section 4 of [RFC5246].
skipping to change at page 15, line 46 skipping to change at page 17, line 14
enum { enum {
ClientHash(1), ClientHash(1),
ServerRandom(2), ServerRandom(2),
ClientRandom(3), ClientRandom(3),
ServerSuccess(4), ServerSuccess(4),
ClientSuccess(5) ClientSuccess(5)
} PairingMessageType; } PairingMessageType;
Devices implementing the service MUST support TLS 1.2 [RFC5246], and Devices implementing the service MUST support TLS 1.2 [RFC5246], and
SHOULD support TLS 1.3 as soon as it becomes available. When using MAY negotiate TLS 1.3 when it becomes available. When using TLS, the
TLS, the client and server MUST negotiate a ciphersuite providing client and server MUST negotiate a ciphersuite providing forward
forward secrecy (PFS), and strong encryption (256 bits symmetric secrecy (PFS), and strong encryption (256 bits symmetric key). All
key). All implementations using TLS 1.2 SHOULD be able to negotiate implementations using TLS 1.2 MUST be able to negotiate the cipher
the cipher suite TLS_DH_anon_WITH_AES_256_CBC_SHA256. suite TLS_DH_anon_WITH_AES_256_CBC_SHA256.
Once the TLS connection has been established, each party extracts the Once the TLS connection has been established, each party extracts the
pairing secret S_p from the connection context per [RFC5705], using pairing secret S_p from the connection context per [RFC5705], using
the following parameters: the following parameters:
Disambiguating label string: "PAIRING SECRET" Disambiguating label string: "PAIRING SECRET"
Context value: empty. Context value: empty.
Length value: 32 bytes (256 bits). Length value: 32 bytes (256 bits).
skipping to change at page 17, line 40 skipping to change at page 19, line 6
At this stage, both client and server can compute the short hash SAS At this stage, both client and server can compute the short hash SAS
as: as:
SAS = first 20 bits of HMAC_hash(S_p, R_c + R_s) SAS = first 20 bits of HMAC_hash(S_p, R_c + R_s)
Where "HMAC_hash" is the HMAC function constructed with the hash Where "HMAC_hash" is the HMAC function constructed with the hash
algorithm selected by the client in the ClientHashMessage. algorithm selected by the client in the ClientHashMessage.
Both client and server display the SAS as a decimal integer, and ask Both client and server display the SAS as a decimal integer, and ask
the user to compare the values. If the values do not match, the user the user to compare the values. If the server supports QR codes, the
cancels the pairing. Otherwise, the protocol continues with the server displays a QR code encoding the decimal string representation
exchange of names, both server and client announcing their own of the SAS. If the client is capable of scanning QR codes, it may
preferred name in a Success message scan the value and compare it to the locally computed value.
If the values do not match, the user cancels the pairing. Otherwise,
the protocol continues with the exchange of names, both server and
client announcing their own preferred name in a Success message
struct { struct {
PairingMessageType messageType; PairingMessageType messageType;
uint8 nameLength; uint8 nameLength;
opaque name[nameLength]; opaque name[nameLength];
} ClientSuccessMessage; } ClientSuccessMessage;
messageType Set to "ClientSuccess" if transmitted by the client, messageType Set to "ClientSuccess" if transmitted by the client,
"ServerSuccess" if by the server. "ServerSuccess" if by the server.
skipping to change at page 18, line 25 skipping to change at page 19, line 44
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. specifically designed to mitigate such attacks, assuming that the
client and user are in close, physical proximity and thus a human
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
mitigate such attacks, nodes MUST store the secret safely, and MUST mitigate such attacks, nodes MUST store the secret safely, and MUST
be able to quickly revoke a compromised pairing. This is however not be able to quickly revoke a compromised pairing. This is however not
sufficient, as the compromise of the pairing key could remain sufficient, as the compromise of the pairing key could remain
undetected for a long time. For further safety, nodes SHOULD assign undetected for a long time. For further safety, nodes SHOULD assign
a time limit to the validity of pairings, discard the corresponding a time limit to the validity of pairings, discard the corresponding
keys when the time has passed, and establish new pairings. keys when the time has passed, and establish new pairings.
6. IANA Considerations 6. IANA Considerations
This draft does not require any IANA action. This draft does not require any IANA action.
7. Acknowledgments 7. Acknowledgments
TODO We would like to thank Steve Kent for a detailed early review of this
document.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 19, line 45 skipping to change at page 21, line 15
[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-00 (work in progress),
October 2016. October 2016.
[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, "Authentication [KFR09] Kainda, R., Flechais, I., and A. Roscoe, "Usability and
protocols based on low-bandwidth unspoofable channels: a Security of Out-Of-Band Channels in Secure Device Pairing
comparative survey", 2009. Protocols", DOI: 10.1145/1572532.1572547, SOUPS
09, Proceedings of the 5th Symposium on Usable Privacy and
Security, Mountain View, CA, January 2009.
[NR11] Nguyen, L. and A. Roscoe, "Authentication protocols based [NR11] Nguyen, L. and A. Roscoe, "Authentication protocols based
on low-bandwidth unspoofable channels: a comparative on low-bandwidth unspoofable channels: a comparative
survey", 2011. survey", DOI: 10.3233/JCS-2010-0403, Journal of Computer
Security, Volume 19 Issue 1, Pages 139-201, January 2011.
[NS1978] Needham, R. and M. Schroeder, ". Using encryption for
authentication in large networks of computers",
Communications of the ACM 21 (12): 993-999,
DOI: 10.1145/359657.359659, December 1978.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<http://www.rfc-editor.org/info/rfc2104>. <http://www.rfc-editor.org/info/rfc2104>.
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
for the MD5 Message-Digest and the HMAC-MD5 Algorithms", for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
RFC 6151, DOI 10.17487/RFC6151, March 2011, RFC 6151, DOI 10.17487/RFC6151, March 2011,
<http://www.rfc-editor.org/info/rfc6151>. <http://www.rfc-editor.org/info/rfc6151>.
[RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: [RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP:
Media Path Key Agreement for Unicast Secure RTP", Media Path Key Agreement for Unicast Secure RTP",
RFC 6189, DOI 10.17487/RFC6189, April 2011, RFC 6189, DOI 10.17487/RFC6189, April 2011,
<http://www.rfc-editor.org/info/rfc6189>. <http://www.rfc-editor.org/info/rfc6189>.
[USK11] Uzun, E., Saxena, N., and A. Kumar, ". Pairing devices for [USK11] Uzun, E., Saxena, N., and A. Kumar, "Pairing devices for
social interactions: a comparative usability evaluation", social interactions: a comparative usability evaluation",
2009. DOI: 10.1145/1978942.1979282, Proceedings of the
International Conference on Human Factors in Computing
Systems, CHI 2011, Vancouver, BC, Canada, May 2011.
[WPS] Wi-Fi Alliance, "Wi-Fi Protected Setup", 2016, [WPS] Wi-Fi Alliance, "Wi-Fi Protected Setup", 2016,
<http://www.wi-fi.org/discover-wi-fi/ <http://www.wi-fi.org/discover-wi-fi/
wi-fi-protected-setup>. wi-fi-protected-setup>.
[XKCD936] Munroe, R., "XKCD: Password Strength", 2011, [XKCD936] Munroe, R., "XKCD: Password Strength", 2011,
<https://www.xkcd.com/936/>. <https://www.xkcd.com/936/>.
Authors' Addresses Authors' Addresses
Christian Huitema Christian Huitema
Private Octopus Inc.
Friday Harbor, WA 98250 Friday Harbor, WA 98250
U.S.A. U.S.A.
Email: huitema@huitema.net Email: huitema@huitema.net
Daniel Kaiser Daniel Kaiser
University of Konstanz University of Konstanz
Konstanz 78457 Konstanz 78457
Germany Germany
 End of changes. 46 change blocks. 
141 lines changed or deleted 241 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/