Hi all,
While reading through the entire EAP-NOOB draft version 8, I compiled a
list of mostly editorial corrections and suggestions. Feel free to use
whatever you deem fit. If anything remains unclear, I would be happy to
discuss further.
With kind regards,
~Max Crone
1. Introduction
Many proprietary OOB configuration methods exits [...]
Typographical error: exits -> exist
The device authentication relies on user having physical access
to the device, and the of the key exchange security is based on
[...]
on user -> on a user
and the of the key exchange security -> and the key exchange security
We follow he common approach taken in pairing protocols:
performing a Diffie-Hellman key exchange over the insecure
network and authenticating the established key with the help of
the OOB channel [...]
In order to stay consistent with the first part of this phrase, I would
suggest to change "with the help of" to "over".
3.1. Protocol overview
In that case, the only way to recover is that the user resets
also the peer.
the user resets also the peer -> the user also resets the peer
3.2. Protocol messages and sequences
Each exchange comprises multiple EAP requests-response pairs
[...]
requests-response pairs -> request-response pairs
3.2.1. Common handshake in all EAP-NOOB exchanges
If one of the peer and server is in the Unregistered (0) state
[...]
one of the peer and server -> either the peer or server
3.2.2. Initial Exchange
The server also sends in the request a list of [...]
As part of the request, the server also sends a list of [...]
[...] and cryptosuites (Cryptosuites) it supports, [...]
The name of the data field for server supported cryptosuites felt
confusing to me, because at first I read it as the plural form of
cryptosuite, without realizing the last "s" stands for server. When seen
in isolation, this is therefore slightly confusing. It is a relatively
small issue though, when one continues to read on and sees the
Cryptosuitep data field name.
3.2.3. OOB Step
However, the receiver MAY buffer redundant OOB messages in case
OOB message expiry or similar error detected in the Completion
Exchange causes it to return to the Waiting for OOB (1) state.
in case OOB message expiry -> in case an OOB message expiry
3.3.2. Message data fields
Both kinds of missing input values are are represented by [...]
are are -> are
3.4. Fast reconnect and rekeying
The failure would typically be detected by the peer or
authenticator when session keys no longer are accepted by the
other endpoint.
no longer are accepted -> are no longer accepted
Change in the supported cryptosuites in the EAP server or peer
may also cause the need for a new key exchange.
Change in -> Changes in
3.4.3. User reset
The server could detect that the peer is in the Registered or
Reconnecting state but the server itself is in one of the
ephemeral states 0..2 [...]
state but the server itself -> state, while the server itself
In those cases, the user could choose to merge new peer identity
with the old one in the server.
to merge new peer identity -> to merge the new peer identity
6.2. Identifying correct endpoints
OOB implementation with a dedicated app on a mobile device,
which communicates with a server API at a pre-configured URL,
can protect against such attacks.
Doesn't this go against the original motivation of the protocol, where
you set out to create an open and interoperable way for OOB
configuration of IoT devices? If every manufacturer still has to create
a separate app for their devices, the user experience will not improve
much compared to the current situation where there already exist many
such apps by different manufacturers. Of course, if they would all use
the EAP-NOOB protocol, it still is a general improvement in security.
As a point of discussion related to this; the required existence of
corporate specific EAP servers for authentication of IoT devices has as
a consequence that the interoperability of these devices does not
improve. Imagine a company decides to shut down a product line and all
its respective EAP authentication servers. All future authentication
requests will still fail, as there is no entity that can fill in the
vacuum left by the removal of authentication servers. IoT devices will
only have company specific addresses built in.
Or am I missing a piece in this scenario? It could of course also be
outside the scope of this protocol. In that case, my apologies for
discussing this here.
6.3. Trusted path issues and misbinding attacks
The wrong but uncompomised device's PeerInfo [...]
uncompomised -> uncompromised
6.6. Downgrading threats
As an additional precaution, the EAP server and peer MUST check
for downgrading attacks in the Reconnect Exchange af follows.
af -> as
7.1. Normative references
[NIST-DH] has been withdrawn; it is replaced by the third revision.
Appendix C. ServerInfo and PeerInfo contents
The ServerInfo and PeerInfo fields in the Initial Exchange and
Reconnect Exchange enable the server and peer, respectively,
send information about themselves to the other endpoint.
send -> to send
Appendix D. EAP-NOOB roaming
The list is formated as explained in Table 11.
formated -> formatted
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
