draft-ietf-dnssd-pairing-info-00.txt   draft-ietf-dnssd-pairing-info-01.txt 
Network Working Group D. Kaiser Network Working Group D. Kaiser
Internet-Draft University of Konstanz Internet-Draft
Intended status: Informational C. Huitema Intended status: Informational C. Huitema
Expires: March 7, 2018 Private Octopus Inc. Expires: October 22, 2018 Private Octopus Inc.
September 3, 2017 April 20, 2018
Device Pairing Design Issues Device Pairing Design Issues
draft-ietf-dnssd-pairing-info-00 draft-ietf-dnssd-pairing-info-01
Abstract Abstract
This document discusses issues and problems occuring in the design of This document discusses issues and problems occuring in the design of
device pairing mechanism. It presents experience with existing device pairing mechanism. It presents experience with existing
pairing systems and general user interaction requirements to make the pairing systems and general user interaction requirements to make the
case for "short authentication strings". It then reviews the design case for "short authentication strings". It then reviews the design
of cryptographic algorithms designed to maximise the robustness of of cryptographic algorithms designed to maximise the robustness of
the short authentication string mechanisms, as well as implementation the short authentication string mechanisms, as well as implementation
considerations such as integration with TLS. considerations such as integration with TLS.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 7, 2018. This Internet-Draft will expire on October 22, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Document Organization . . . . . . . . . . . . . . . . . . 3 1.1. Document Organization . . . . . . . . . . . . . . . . . . 3
2. Secure Pairing Over Internet Connections . . . . . . . . . . 3 2. Protocol Independent Secure Pairing . . . . . . . . . . . . . 3
3. Identity Assurance . . . . . . . . . . . . . . . . . . . . . 3 3. Identity Assurance . . . . . . . . . . . . . . . . . . . . . 4
4. Manual Authentication . . . . . . . . . . . . . . . . . . . . 4 4. Manual Authentication . . . . . . . . . . . . . . . . . . . . 4
4.1. Short PIN Proved Inadequate . . . . . . . . . . . . . . . 4 4.1. Short PIN Proved Inadequate . . . . . . . . . . . . . . . 4
4.2. Push Buttons Just Work, But Are Insecure . . . . . . . . 5 4.2. Push Buttons Just Work, But Are Insecure . . . . . . . . 5
4.3. Short Range Communication . . . . . . . . . . . . . . . . 5 4.3. Short Range Communication . . . . . . . . . . . . . . . . 5
4.4. Short Authentication Strings . . . . . . . . . . . . . . 6 4.4. Short Authentication Strings . . . . . . . . . . . . . . 6
5. Resist Cryptographic Attacks . . . . . . . . . . . . . . . . 7 4.5. Revisiting the PIN versus SAS discussion . . . . . . . . 7
6. Privacy Requirements . . . . . . . . . . . . . . . . . . . . 9 5. Resist Cryptographic Attacks . . . . . . . . . . . . . . . . 8
7. Using TLS . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Privacy Requirements . . . . . . . . . . . . . . . . . . . . 10
8. QR codes . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Using TLS . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Intra User Pairing and Transitive Pairing . . . . . . . . . . 13 8. QR codes . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. Intra User Pairing and Transitive Pairing . . . . . . . . . . 14
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
13. Informative References . . . . . . . . . . . . . . . . . . . 14 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 13. Informative References . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
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 24 skipping to change at page 3, line 24
In his early review, Steve Kent observed that the style of the first In his early review, Steve Kent observed that the style of the first
part seems inappropriate for a standards track document, and part seems inappropriate for a standards track document, and
suggested that the two parts should be split into two documents, the suggested that the two parts should be split into two documents, the
first part becoming an informational document, and the second first part becoming an informational document, and the second
focusing on standard track specification of the protocol, making focusing on standard track specification of the protocol, making
reference to the informational document as appropriate. reference to the informational document as appropriate.
The working group approved this split. The working group approved this split.
2. Secure Pairing Over Internet Connections 2. Protocol Independent Secure Pairing
Many pairing protocols have already been developed, in particular for Many pairing protocols have already been developed, in particular for
the pairing of devices over specific wireless networks. For example, the pairing of devices over specific wireless networks. For example,
the current Bluetooth specifications include a pairing protocol that the current Bluetooth specifications include a pairing protocol that
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 In this document we provide background and discuss the design of a
the underlying technology. We simply make the hypothesis that the manually authenticated pairing protocol that is independent of the
two parties engaged in the pairing can discover each other and then underlying network protocol stack. We discuss (1) means allowing the
establish connections over IP in order to agree on a shared secret. two parties engaged in the pairing to discover each other in an
existing unsecured network -- e.g. means for learning about the
network parameters of the respective other device -- which allows
them to establish a connection; (2) agreeing on a shared secret via
this connection; and (3) manually authenticating this secret. For
our discussion and our secure pairing protocol specification
[I-D.ietf-dnssd-pairing], we assume an IP based unsecured network.
With little adaption, this pairing mechanism can be used on other
protocol stacks as well.
[[TODO: Should we support certificates besides a shared secret?]] We limit the goal of the protocol to the establishment of a shared
secret between two parties. Once that secret has been established,
it can trivially be used to secure the exchange of other
informations, such as for example public keys and certificates.
3. Identity Assurance 3. 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
protocol and the user interface (UI) with care. protocol and the user interface (UI) with care.
skipping to change at page 4, line 17 skipping to change at page 4, line 26
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.
4. Manual Authentication 4. 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. Because of this, the protocol
the protocol to detect Man-in-the-Middle attacks, and if possible requires specific features to detect Man-in-the-Middle attacks, and
resist them. if possible resist them.
This section discusses existing techniques that are used in practice, This section discusses existing techniques that are used in practice
and Section 5 provides a layman description of the MiTM problem and for manually authenticating a Diffie-Hellman key exchange, and
Section 5 provides a layman description of the MiTM problem and
countermeasures. A more in depth exploration of manually countermeasures. A more in depth exploration of manually
authenticated pairing protocols may be found in [NR11] and [thesis authenticated pairing protocols may be found in [NR11] and [K17].
kaiserd].
4.1. Short PIN Proved Inadequate 4.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 read that PIN
that PIN and provide it to the other device. The PIN would then be and provided it to the other device. The PIN was then used in a
used in a Password Authenticated Key Exchange. Wi-Fi Protected Setup Password Authenticated Key Exchange. Wi-Fi Protected Setup [WPS]
[WPS] offered a similar option. There were various attacks against offered a similar option. There were various attacks against the
the actual protocol; some of the problems were caused by issues in actual protocol; some of the problems were caused by issues in the
the protocol, but most were tied to the usage of short PINs. protocol, but most were tied to the usage of short PINs.
In the reference implementation, the PIN is picked at random by the In the reference implementation, the PIN is picked at random by the
paired device before the beginning of the exchange. But this paired device before the beginning of the exchange. But this
requires that the paired device is capable of generating and requires that the paired device is capable of generating and
displaying a four digit number. It turns out that many devices displaying a four digit number. It turns out that many devices
cannot do that. For example, an audio headset does not have any cannot do that. For example, an audio headset does not have any
display capability. These limited devices ended up using static display capability. These limited devices ended up using static
PINs, with fixed values like "0000" or "0001". PINs, with fixed values like "0000" or "0001".
Even when the paired device could display a random PIN, that PIN will Even when the paired device could display a random PIN, that PIN had
have to be copied by the user on the pairing device. It turns out to be copied by the user on the pairing device. It turns out that
that users do not like copying long series of numbers, and the users do not like copying long series of numbers, and the usability
usability thus dictated that the PINs be short -- four digits in thus dictated that the PINs be short -- four digits in practice. But
practice. But there is only so much assurance as can be derived from there is only so much assurance as can be derived from a four digit
a four digit key. key.
It is interesting to note that the latest revisions of the Bluetooth The latest revisions of the Bluetooth Pairing protocol [BTLEPairing]
Pairing protocol [BTLEPairing] do not include the short PIN option do not include the short PIN option anymore. The PIN entry methods
anymore. The PIN entry methods have been superseded by the simple have been superseded by the simple "just works" method for devices
"just works" method for devices without displays, and by a procedure without displays, and by a procedure based on an SAS (short
based on an SAS (short authentication string) when displays are 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.
4.2. Push Buttons Just Work, But Are Insecure 4.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
skipping to change at page 6, line 23 skipping to change at page 6, line 29
microphones might pick the sounds. However, a property that all of microphones might pick the sounds. However, a property that all of
these channels share is authenticity, i.e. an assurance that the data these channels share is authenticity, i.e. an assurance that the data
obtained over the out-of-band channel actually comes from the other obtained over the out-of-band channel actually comes from the other
party. This is because these out-of-band channels involve the user party. This is because these out-of-band channels involve the user
transmitting information from one device to the other. We will transmitting information from one device to the other. We will
discuss the specific case of QR codes in Section 8. discuss the specific case of QR codes in Section 8.
4.4. Short Authentication Strings 4.4. Short Authentication Strings
The evolving pairing protocols seem to converge towards using Short The evolving pairing protocols seem to converge towards using Short
Authentication Strins and verifying them via the "compare and Authentication Strings and verifying them via the "compare and
confirm" method. This is in line with academic studies, such as confirm" method. This is in line with academic studies, such as
[KFR09] or [USK11], and, from the users' perspective, results in a [KFR09] or [USK11], and, from the users' perspective, results in a
very simple interaction: very simple interaction:
1. Alice and Bob compare displayed strings that represent a 1. Alice and Bob compare displayed strings that represent a
fingerprint of the afore exchanged pairing key. fingerprint of the afore exchanged pairing key.
2. 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 number. Usability studies show that this method gives
gives good results, with little risk that users mistakenly accept two 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
list of common words, and the process to go from a binary fingerprint list of common words, and the process to go from a binary fingerprint
to a set of words. We would need to be concerned with to a set of words. We would need to be concerned with
internationalization issues, such as using different lists of words internationalization issues, such as using different lists of words
in German and in English. This could require the negotiation of word in German and in English. This could require the negotiation of word
lists or languages 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".
4.5. Revisiting the PIN versus SAS discussion
In section Section 4.1 we presented the drawbacks of using short
pins. One could object that many of the technical issues could be
overcome by use of better PAKE algorithms, or by supporting longer
PIN. And one could also argue that if PIN based pairing algorithms
suffer from failure modes such as static PIN configuration, SAS based
protocols are vulnerable to SAS bypass.
The SAS bypass argument is rooted in the psychology of users. In
practice, pairing processes can be stressful. The user has to
discover on each device the proper combination of key entries that
brings up the required pairing UI, will be anxious and eager to
complete the procedure, and may well be predisposed to click "OK" in
the final stage of the algorithm without actually verifying the SAS.
Some users may bypass the required comparison step, because they just
want to be done with the pairing.
An advantage of PIN based processes is that they cannot be bypassed.
The user must enter the PIN before continuing. Also, once the PIN is
entered, everything is automatic. The user does not need to input
more data, or press any additional button. PIN based protocols would
be a great fit for the QR-code based interaction. One device would
display a QR code that contains the PIN. Once the QR code is scanned
by the other device, the process is automated.
QR based PIN entry may be user friendly, but one of the arguments
developed in Section 4.1 still holds. Let's assume that an adversary
somehow obtains the PIN, maybe by scanning the QR code at a distance.
That adversary could mount MITM or impersonation attacks, and
compromise the pairing process. It is thus very important to ensure
that the PIN is only readable by the user doing the pairing.
We could also argue that the SAS bypass failure mode may be mitigated
by specific user designs. For example, instead of just clicking OK,
the user could be required to enter the SAS displayed by the other
device. This requires about the same interactions as a PIN based
process, and it would be slightly safer because the SAS does not have
to be kept secret once the keys have been exchanged.
If we summarize the debate, we see that both SAS and PIN based
solutions have failure modes depending on implementations. In the
SAS mode, the failure happens when the UI does not force the user to
copy the PIN and relies on a simple "OK to continue" dialog. In the
PIN mode, the failure happens when the device fails to generate a
random PIN for each session, and comes pre-programmed with a simple
static PIN of "0000" or "0001".
5. Resist Cryptographic Attacks 5. 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
(1) exchange two nonces, (2) hash the concatenation of these nonces (1) exchange two nonces, (2) hash the concatenation of these nonces
with the shared secret that is about to be established, (3) display a with the shared secret that is about to be established, (3) display a
short authentication string composed of a short version of that hash short authentication string composed of a short version of that hash
on each device, and (4) verify that the two values match. This naive on each device, and (4) verify that the two values match. This naive
approach might yield the following sequence of messages: approach might yield the following sequence of messages:
skipping to change at page 8, line 52 skipping to change at page 9, line 52
<-- nB <-- nB
nA --> nA -->
verifies h_a == hash(s|nA) verifies h_a == hash(s|nA)
Computes Computes Computes Computes
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
Alice will only disclose nA after having confirmation from Bob that Alice will only disclose nA after having confirmation from Bob that
hash(nA) has been received. At that point, Eve has a problem. She hash(nA) has been received. At that point, Eve has a problem. She
can still forge the values of the nonces but she needs to pick the can still forge the values of the nonces, but she needs to pick the
nonce nA' before the actual value of nA has been disclosed. Eve nonce nA' before the actual value of nA has been disclosed. Eve
would still have a random chance of fooling Alice and Bob, but it would still have a random chance of fooling Alice and Bob, but it
will be a very small chance: one in a million if the short will be a very small chance: one in a million if the short
authentication string is made of 6 digits, even fewer if that string authentication string is made of 6 digits, even fewer if that string
is longer. is longer.
Nguyen et al. [NR11] survey these protocols and compare them with Nguyen et al. [NR11] survey these protocols and compare them with
respect to the amount of necessary user interaction and the respect to the amount of necessary user interaction and the
computation time needed on the devices. The authors state that such computation time needed on the devices. The authors state that such
a protocol is optimal with respect to user interaction if it suffices a protocol is optimal with respect to user interaction if it suffices
skipping to change at page 14, line 23 skipping to change at page 15, line 23
13. Informative References 13. Informative References
[BTLEPairing] [BTLEPairing]
Bluetooth SIG, "Bluetooth Low Energy Security Overview", Bluetooth SIG, "Bluetooth Low Energy Security Overview",
2016, 2016,
<https://developer.bluetooth.org/TechnologyOverview/Pages/ <https://developer.bluetooth.org/TechnologyOverview/Pages/
LE-Security.aspx>. LE-Security.aspx>.
[I-D.ietf-dnssd-pairing] [I-D.ietf-dnssd-pairing]
Huitema, C. and D. Kaiser, "Device Pairing Using Short Huitema, C. and D. Kaiser, "Device Pairing Using Short
Authentication Strings", draft-ietf-dnssd-pairing-02 (work Authentication Strings", draft-ietf-dnssd-pairing-03 (work
in progress), July 2017. in progress), September 2017.
[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-02 (work in progress), July SD", draft-ietf-dnssd-privacy-04 (work in progress), April
2017. 2018.
[I-D.miers-tls-sas] [I-D.miers-tls-sas]
Miers, I., Green, M., and E. Rescorla, "Short Miers, I., Green, M., and E. Rescorla, "Short
Authentication Strings for TLS", draft-miers-tls-sas-00 Authentication Strings for TLS", draft-miers-tls-sas-00
(work in progress), February 2014. (work in progress), February 2014.
[K17] Kaiser, D., "Efficient Privacy-Preserving
Configurationless Service Discovery Supporting Multi-Link
Networks", 2017,
<http://nbn-resolving.de/urn:nbn:de:bsz:352-0-422757>.
[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
Security, Mountain View, CA, January 2009. 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", DOI: 10.3233/JCS-2010-0403, Journal of Computer survey", DOI: 10.3233/JCS-2010-0403, Journal of Computer
Security, Volume 19 Issue 1, Pages 139-201, January 2011. Security, Volume 19 Issue 1, Pages 139-201, January 2011.
[NS1978] Needham, R. and M. Schroeder, ". Using encryption for [NS1978] Needham, R. and M. Schroeder, ". Using encryption for
authentication in large networks of computers", authentication in large networks of computers",
Communications of the ACM 21 (12): 993-999, Communications of the ACM 21 (12): 993-999,
DOI: 10.1145/359657.359659, December 1978. 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, <https://www.rfc- DOI 10.17487/RFC2104, February 1997,
editor.org/info/rfc2104>. <https://www.rfc-editor.org/info/rfc2104>.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport [RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
March 2010, <https://www.rfc-editor.org/info/rfc5705>. March 2010, <https://www.rfc-editor.org/info/rfc5705>.
[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,
<https://www.rfc-editor.org/info/rfc6151>. <https://www.rfc-editor.org/info/rfc6151>.
skipping to change at page 15, line 40 skipping to change at page 16, line 45
[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
Daniel Kaiser Daniel Kaiser
University of Konstanz Esch-sur-Alzette 4360
Konstanz 78457 Luxembourg
Germany
Email: daniel.kaiser@uni-konstanz.de
Email: daniel@kais3r.de
Christian Huitema Christian Huitema
Private Octopus Inc. 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
 End of changes. 28 change blocks. 
66 lines changed or deleted 128 lines changed or added

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