Subject: [Emu] Review of draft-aura-eap-noob-08

From: Max Crone <[email-masked]>
Date: Thu, 9 Apr 2020 16:13:19 +0300

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