Document: draft-ietf-emu-bootstrapped-tls
Title: Bootstrapped TLS Authentication with Proof of Knowledge (TLS-POK)
Reviewer: Marc Blanchet
Review result: Ready with Nits
Hello,
I've been asked to provide a review of draft-ietf-emu-bootstrapped-tls
>From the ART directorate. I'm no security expert. During that review,
I did not follow the references, nor verified the test vectors.
---------------------------
---------------------------
Substantive comments
- I'm no security expert, so the following comment may be irrelevant.
Section 3.1 says to use SHA-256 hash algo: "of the BSK public key using
[RFC5869] with the SHA-256 hash algorithm
[sha2]" ...
I did not see a way to specify another hash algorithm
for crypto algorithm agility. It may not be relevant here,
But should the hash algorithm be specified somewhere so that
It could be replaced another one later. Or maybe I missed it.
Just asking.
- Figure 1 handshake description contains the last line as "Application Data".
{Finished} -------->
[Application Data] <-------> [Application Data]
Maybe it is obvious for people in the field, but I thought from reading that
after the authentication handshake, nothing else will happen with the server
and the client as the client now has access to the network. Therefore, I'm not
sure what would be the application data between the client and server after
the handshake. Maybe it is obvious. If it is not, then maybe either remove
or explain a bit more what that application data is, since it is not defined
or referenced anywhere else in the draft.
- again, I'm no security expert, so the following comment may be irrelevant.
In section 7. Security Considerations, I was expecting (and even within the
draft Itself) some discussion on DOS on the server by sending a lot of queries
by one or Many devices on the network. Should rate-limiting be used, and if
yes, what is the Right values, and maybe by device identified by their mac
addresss?
Moreover, I was expecting some discussion or recommendation that the device
manufacturers should not use the same keypair for all (or more than one)
device. That may look obvious to a security person, but given manufacturing
context, it creates more work, so costs, so unwillingness to have specific
keypairs for each device.
---------------------------
---------------------------
English/nits/improvements
caveat: English is not my first language,
so maybe some comments related to language are actually not right.
- general comment: there is a bit of repetition about the general
description of the mechanism in too many sections (abstract, intro, section 2,
... Some could be cut to make the draft smaller and to the point.
- "knows the private key. The mechanism leverages existing DPP and TLS"
s/knows/has|owns|possesses/ ?
In my book, knows does not mean it has it.
- "On-boarding of devices with no, or limited, user interface can be
s/On-boarding of devices/On-boarding devices/
- "difficult. Typically, a credential is needed to access the network,"
I find "Typically" here too strong. At least, that is not my personal
Experience in the context of this draft (aka EAP/...).
S/Typically/Sometimes/
- "Thus, the intention is that DPP is the
RECOMMENDED mechanism for bootstrapping against Wi-Fi networks, and
TLS-POK is the RECOMMENDED mechanism for bootstrapping against wired
networks."
s/.../Thus, DPP SHOULD be used for bootstrapping against Wi-Fi networks, and
TLS-POK SHOULD be used for bootstrapping against wired
networks
- "The following terminology is used throughout this document."
Suggestion: add "NAI" as it is not expanded but used later.
- "into a Certification Authority to allow them to authenticate using"
s/into/with/ ?
- "This document defines a boostrapping mechanism that results in a"
S/boostrapping mechanism that results/booTstrapping mechanism resulting/
- "subsequent network access. Therefore, an EAP method that supports"
S/that supports/supporting the/
- "used with TEAP, including defining a suitable NAI."
Either expand here (on first use) or put it in the terminology section,
As suggested above.
- "If future EAP methods are defined that support certificate"
s/that support/supporting/
- "provisioning, then TLS-POK could potentially be used with those"
s/could potentially be used/may be used/
- "The mechanism for on-boarding of devices defined in this document"
s/on-boarding of devices/device on-boarding/
- "The definition of the BSK public key aligns with that given in [DPP].
s/that given in//
- "A performance versus storage tradeoff a server can choose is to
precompute the identity of every bootstrapped key with every hash"
I find this sentence a bit difficult to parse. It took me to repeat
it two times until I got it.
Maybe: s/.../A server can choose a tradeoff between performance and storage
by precomputing the .../
- "algorithm that it uses in TLS and use that to quickly lookup the"
s/that is uses in/used/
s/use that to quickly/use it/
- "handshake with an alert. If the server found the matching BSK public"
s/found/finds/
- "ServerHello and verified the TLS key schedule. The PSK proof has
completed at this stage,"
a/has completed/is completed/
- "When the server processes the client's Certificate it MUST ensure"
s/Certificate/Certificate,/
- "An attack on the bootstrapping method which substitutes the public
key of a corrupted device for the public key of an honest device can
result in the TLS sever on-boarding and trusting the corrupted
device."
Is "corrupted" the right word here? Corrupted means to me that the device
Internal filesystem is broken for example.
S/corrupted/tampered/?
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
