Re: [Emu] Benjamin Kaduk's Discuss on draft-ietf-emu-eap-noob-04: (with DISCUSS and COMMENT)

[Mohit Sethi M <[e-mail]>]

Hi Ben,

Thank you for your usual detailed review. We have uploaded a new version 
of the draft: https://tools.ietf.org/html/draft-ietf-emu-eap-noob-05. 
Here is the diff for your convenience: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-noob-05.

Answers inline.

--Mohit

On 4/22/21 7:26 AM, Benjamin Kaduk via Datatracker wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-emu-eap-noob-04: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer tohttps://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> The example JWK for cryptosuite 1 in §5.1 is not well-formed.  RFC 8037
> key-exchange uses a crv of "X25519" and a kty of "OKP".
> (See COMMENT for more quibbles with §5.1.)
> I think Appendix E is also using the wrong "kty" for X25519 (but is
> properly using "X25519" as the "crv").

Good catch. This is now fixed in the script used to generate the test 
vectors: 
https://github.com/tuomaura/eap-noob/commit/a9e8da4ec227b4afe8fb04feb71d76265396882b. 
The example messages in the draft are not yet updated (pending your 
feedback on our proposal below).

>
> I'd also like to discuss our treatment of channel binding, as the
> current mention seems dangerously incomplete.  I don't remember if there
> is generic discussion of channel binding in the core EAP RFCs (if so, a
> specific reference would help), but otherwise if we're going to mention
> that protocol elements can be used for channel binding we should give
> some indication of how to actually do so in a secure manner (e.g., what
> protocol element needs to be verified against external channel
> information and what to do if they don't match).

We have added a section on channel binding which should address all the 
issues: 
https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-noob-05#section-7.7.

>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thanks for putting together this pretty comprehensive treatment of a
> topic that is simple to understand but has a lot of important details.
> (I do have some comments about a few of those details, just to check
> that we do have them right.)  I especially appreciate the strong feature
> set that's been assembled.
>
> In Section 3.5 we discuss a key derivation scheme and say to use the
> one-step KDF from NIST SP 800-56Ar3 §5.8.2.1.  In particular, this is
> not the two-step (extract-then-expand) KDF of the following section
> (§5.8.2.2).  Since the (EC)DH shared secret Z is not uniformly random,
> my understanding was that generally the two-step KDF was needed, since
> the one-step KDF assumes that the input key is uniformly selected.  I am
> not balloting Discuss for this point because I assume it was considered
> in the formal verification, but I would very much appreciate some
> additional insight into this selection.
We did not specifically model the security of the KDF itself. The NIST 
specification defines the one-step key derivation function for use with 
ECDH shared secrets (NIST calls it 'Z' a byte string that represents the 
shared secret). In fact RFC 7518 
(https://datatracker.ietf.org/doc/html/rfc7518#section-4.6.2) uses the 
same NIST KDF for deriving keys. The one-step may have stronger 
assumptions from the underlying hash function but we thought the hash 
functions currently specified in the draft are safe to use with a 
one-step function. In future, when we move to KMACs and SHA3 family, we 
would not need a two-step KDF.
> Section 3.1
>
>     The overall protocol starts with the Initial Exchange, which
>     comprises four EAP request-response pairs.  In the Initial Exchange,
>     the server allocates an identifier to the peer, and the server and
>
> Is this a DoS risk for state exhaustion on the server?
>
>     The server MUST NOT repeat a successful OOB Step with the same peer
>     except if the association with the peer is explicitly reset by the
>     user or lost due to failure of the persistent storage in the server.
>     More specifically, once the association has entered the Registered
>     state, the server MUST NOT delete the association or go back to the
>     ephemeral states 0..2 without explicit user approval.  [...]
>
> This also looks like a DoS risk, if a malicious device/user completes
> the OOB step then only deletes the association on the device (without
> telling the server), then re-registers, deletes again, etc.  The server
> is required to maintain state without bound.

We have added a section on Denial of service: 
https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-noob-05#section-7.8 
which discusses this and other sources of DoS identified by you.

>
>     However, it MUST NOT delete or merge redundant associations without
>     user or application approval because EAP-NOOB internally has no
>     secure way of verifying that the two peers are the same physical
>     device.  [...]
>
> No way other than the registered cryptographic key that's used to
> authenticate the Reconnect Exchange, that is?
Yes. That's true. The text is only meant to dissuade implementers from 
removing associations without user confirmation. For example, 
associations should not be removed automatically if there is a temporary 
failure in the communication between the server and the database which 
stores the association state, or if there is temporary DoS attacker on 
the channel.
>     A special feature of the EAP-NOOB method is that the server is not
>     assumed to have any a-priori knowledge of the peer.  Therefore, the
>     peer initially uses the generic identity string"[e-mail]"
>     as its network access identifier (NAI).  [...]
>
> This looks like codepoint squatting, since we haven't received an early
> allocation of this entry in .arpa.

We received an early review from Amanda Baber on 8th July 2020 
confirming that the IANA requests were acceptable. This can obviously be 
updated later on in the process.

> section 3.2.1
>
>     After receiving the EAP-Response/Identity message, the server sends
>     the first EAP-NOOB request (Type=1) to the peer, which responds with
>     the peer identifier (PeerId) and state (PeerState) in the range 0..3.
>     However, the peer SHOULD omit the PeerId from the response (Type=1)
>     when PeerState=0.  [...]
>
> Why only SHOULD and not MUST?

Including the PeerId does not result in any difference to the protocol 
execution. We did not want to completely exclude it in case an 
implementation wants to include the PeerId for logging at the server 
when debugging the implementation.

> Section 3.2.3
>
> Can we give any guidance for how to set OobRetries?

The value of OobRetries is heavily dependent on the OOB channel. For 
example, when the OOB channel is a QR code with error correction, the 
user can only be expected to the scan the QR code a few times and trying 
further will likely not solve the problem. If, on the other hand, the 
OOB channel is a blinking light or audio with no error detection or 
correction, it may make sense to allow higher number of OOB transfer 
attempts in fast succession. We have added to "Table 14: OOB channel 
characteristics" the following text: "When the OOB channel has error 
detection or correction, the RECOMMENDED value is 5.".

> Section 3.2.4
>
>                            In the request, the server sends the NoobId
>     value, which the peer uses to identify the exact OOB message received
>     by the server.  [...]
>
> This is the first time we mention the NoobId value, so some more
> explanation or forward-reference seems in order.

We have added a forward reference.

>     value.  The recipient of an unrecognized NoobId indicates this with
>     an error message (error code 2003, see Section 3.6.1), and the
>     Completion Exchange ends in EAP-Failure.  [...]
>
> I assume that the formal modeling has considered whether the specific
> "bad NoobId" error code leads to an attack.
We have added some text to the section on 'Denial of Service'. This was 
considered in the formal model and the protocol recovers when the DoS 
attacker goes away.
> Section 3.2.5
>
> SleepTime is sent in an unauthenticated EAP message, thus presents a DoS
> vector due to forged very large values.  In Section 3.3.2 we seem to
> place an upper limit of 3600 seconds, which could mitigate this DoS
> risk.  I suggest mentioning the upper limit here.
We wanted to avoid repetition so that it is easier for us to maintain 
consistency in the specification. Let us know if it is absolutely 
necessary to repeat it earlier in the text.
> Section 3.3.1
>
>                                   The peer sets the PeerId value in
>     response type 1 as follows.  When the peer is in the Unregistered (0)
>     state, it SHOULD omit the PeerId from response type 1.  [...]
>
> [if we change this SHOULD above, we have to change it here as well.  And
> arguably only put the normative requirement in one location.]

Same explanation as above for retaining the SHOULD. We have added a 
reference to the earlier normative text.

> Section 3.3.2
>
> Can we list the message Type in the table or otherwise indicate that the
> message type is passed as a regular member of the JSON object that is
> the message payload?  I had to consult the examples to figure this out
> otherwise...
The message Type is in the "Message data fields" table. We have now 
moved it up in the table, which is the more logical place for it.
>     | Dirs, Dirp       | The OOB channel directions supported by the    |
>     |                  | server and the directions selected by the      |
>     |                  | peer. The possible values are 1=peer-to-       |
>     |                  | server, 2=server-to-peer, 3=both directions.   |
>
> If a server supports both directions does it have to advertise [1,2,3]
> (the examples suggest "no")?
> What happens if it only advertises [3]?
Both Dirs and Dirp are integers, not arrays. We have updated the table. 
Thanks for noticing this source of potential confusion.
>     | Ns, Np           | 32-byte nonces for the Initial Exchange.       |
>     [...]
>     | Ns2, Np2         | 32-byte Nonces for the Reconnect Exchange.     |
>
> I see there is a note later about the nonce formatting, but I think it
> would be helpful to mention the base64url encoding and JSON string
> representation for transport.

We wanted to avoid repetition so that it is easier for us to maintain 
consistency in the specification. Let us know if it is absolutely 
necessary to repeat it earlier in the text. We have however clarified 
the text somewhat : "These values and the message authentication codes 
(MACs, MACp, MACs2, MACp2) MUST also be base64url encoded when they are 
sent as JSON strings in the in-band messages".

>     | PeerInfo         | This field contains information about the peer |
>     |                  | to be passed from the EAP method to the        |
>     |                  | application layer in the server. The           |
>     |                  | information is specific to the application or  |
>     |                  | to the OOB channel and it is encoded as a JSON |
>     |                  | object of at most 500 bytes. It could include, |
>     |                  | for example, the peer brand, model and serial  |
>     |                  | number, which help the user to distinguish     |
>     |                  | between devices and to deliver the OOB message |
>     |                  | to the correct peer through the out-of-band    |
>     |                  | channel.                                       |
>
> It seems like there are some potential privacy considerations to sending
> this information to an unauthenticated server.  Section 7.5 covers some
> of this, but we might benefit from specifically using the phrase
> "privacy considerations" and perhaps expounding slightly more.

We did somewhat discuss these concerns in the "Identity protection" 
section. We have now moved the text to a separate section on Privacy 
Considerations: 
https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-noob-05#section-7.10.

>     The inputs for computing the fingerprint and message authentication
>     codes are the following:
>     [...]
>
> Did the formal verification include modeling of scenarios where the
> initial NAI varied and NewNAI was not sent?
This is an excellent observation. The NAI which will be written to the 
persistent association must always be included in the fingerprint and 
message authentication codes, even if it was configured by the user. We 
have now updated the text. This is an error in the specification and 
thank you for catching it.
> Also, was consideration given to using a "raw" transcript hash that
> takes the literal messages exchanged, as opposed to subsetting certain
> fields?  This version seems to leave, e.g., SleepTime unprotected even
> by post-facto authentication.
The trade-off between authenticating the raw transcript hash vs. the end 
result is that the latter case will catch any inconsistencies in the 
implementation of the protocol logic between the two endpoints. The need 
to authenticate the agreed NAI rather than the NewNAI in the message 
above is a case in point. We also allow retires of the OOB message, 
Completion Exchange, and Reconnect Exchange, for example, in the case of 
a temporary on-path attacker, and defining the transcript for these 
retries of the exchanges would not be trivial. Moreover, the transcript 
cannot include only the current exchange because the security protocol 
spans multiple exchanges, i.e., multiple EAP conversations. The 
SleepTime is not protected because it is significant only before the 
authentication has taken place.
>     The nonces (Ns, Np, Ns2, Np2, Noob) and the hash value (NoobId) MUST
>     be base64url encoded [RFC4648] when they are used as input to the
>     cryptographic functions H or HMAC.  [...]
>
> This part is somewhat surprising to me; I would have only expected the
> base64url encoding to be used for in-band messages and not for
> cryptographic inputs, espcially if we are mixing use of en- and de-coded
> forms (the raw binary is used for the KDF procedure).
The reason is that we can copy the in-band messages verbatim to the 
cryptographic input. Otherwise, problems will arise with the ServerInfo 
and PeerInfo fields which are JSON objects and have no canonical form 
(at least not at the time when the specification was written). For this 
reason, we decided to treat all the data fields in the same way.
> Section 3.4.2
>
>     1.  The peer first compares the received MACs2 value with one it
>         computed using the Kz stored in the persistent EAP-NOOB
>
> I briefly attempted to think through some scenarios where a Kz is
> compromised (either from the peer or the server), as always checking the
> persistent Kz makes it easy for an attacker that knows Kz and has some
> on-path presence to get an exchange accepted when the peer recommences
> EAP.  But it seems that an attacker in that position would generally be
> able to impersonate the server regardless of what procedure we specify,
> since Kz is the main thing that authenticates the reconnect exchange
> anyway.  So I don't think that we need to consider (e.g.) attempting to
> confirm a new key prior to Kz, if one is present.
>
>     Exchange ends in EAP-Success.  When KeyingMode is 3, the server also
>     updates Cryptosuitep and Kz in the persistent EAP-NOOB association.
>     On the other hand, if the server finds that the values do not match,
>     it sends an error message (error code 4001), and the Reconnect
>     Exchange ends in EAP-Failure.
>
> It's surprising to me that Kz is only updated for keying mode 3 -- I
> would have expected it to always update.  IIUC doing so would provide a
> weak form of forward secrecy even for the non-ECDHE case, and my
> intuition is that it would extend the safe usable lifetime for the key
> material.

Some devices may not be able to update the persistent memory frequently, 
for example, flash or secure hardware module. We are worried that these 
updates can also be unreliable. For this reason, the specification 
allows the peer to avoid updates once the persistent association has 
been created.

> Section 3.4.3
>
>     the PeerId).  In this case, effort should be made to recover the
>     persistent server state, for example, from a backup storage -
>     especially if many peer devices are similarly affected.  If that is
>
> If we're going to mention the possibility of storing the server's
> persistent session state on backup storage we need to talk about the
> security considerations for protecting that backup storage.
Not sure if IETF specifications should make recommendations on server or 
data center security. The example of recovering the persistent state 
from a backup is mentioned only as an example of a temporary failure 
which the protocol is designed to withstand.
> Section 3.6.5
>
>     of peer connections with SleepTime after the above error.  Also,
>     there SHOULD be a way for the user to reset the peer to the
>     Unregistered state (0), so that the OOB Step can be repeated as the
>     last resort.
>
> Why is this only a SHOULD?

Some devices may not be reusable, or they maybe deployed in places where 
it is not possible for the user to reset them.

> Section 4
>
>     for EAP channel binding.  This section describes the initial data
>     fields for ServerInfo and PeerInfo registered by this specification.
>     Further specifications may request new application-specific
>     ServerInfo and PeerInfo data fields from IANA (see Section 5.4 and
>     Section 5.5).
>
> I might say something about how all of these are optional to use.
Added that they are optional.
>     | Type           | Type-tag string that can be used by the peer as  |
>     |                | a hint for how to interpret the ServerInfo       |
>     |                | contents.                                        |
>     [...]
>     | Type         | Type-tag string that can be used by the server as  |
>     |              | a hint for how to interpret the PeerInfo contents. |
>
> A little unfortunate to have "Type" as a JSON object member in both
> these and the toplevel message payloads but with different semantics,
> but I guess it is understandable.

We gave this a lot of thought earlier and found the current naming 
convention less confusing than the more verbose alternatives we considered.

> Section 4
>
>     | MACAddress   | Peer link-layer identifier (EUI-48) in the         |
>     |              | 12-digit base-16 form [EUI-48]. The string MAY be  |
>     |              | in upper or lower case and MAY include additional  |
>     |              | colon ':' or dash '-' characters that MUST be      |
>     |              | ignored by the server.                             |
>
> We traditionally include privacy considerations when we convey MAC
> address information in protocol fields.
We have added text to the Privacy Considerations section.
> Section 5.1
>
>     | 1           | ECDHE curve Curve25519 [RFC7748], public-key format |
>     |             | [RFC7517], hash function SHA-256 [RFC6234]          |
>     | 2           | ECDHE curve NIST P-256 [FIPS186-4], public-key      |
>     |             | format [RFC7517], hash function SHA-256 [RFC6234]   |
>
> I think we might need to give a slightly more detailed
> explanataion/reference for the public-key formats here.
>
> In particular, RFC 7517 is not really a good reference for Curve25519 in
> JWK; RFC 8037 is what defines X25519 for JOSE.  (Curve25519 itself is
> not yet registered, though there is some work underway in or adjacent to
> draft-ietf-lwig-curve-representations to define ECSDA and NIST cofactor
> ECDH on Curve25519.)
Done.
> Section 6.3
>
>     o  Coverage: This implementation is the most up-to-date.  The
>        [...]
>     o  Version compatibility: Version 02 of the working group adopted
>        draft is implemented
>
> It's hard to square "most up-to-date" with only implementing version 02
> (the other implementations claim 08 and 06)...though since this is
> getting removed anyway it's rather moot.
>
> Section 7.1
>
>     or API.  In this case, the server can reliably associate the peer
>     device with the user account.  Applications that make use of EAP-NOOB
>
> I'd suggest dropping "reliably" here; there are some attack scenarios
> that can arise when a registration is deliberately (or perhaps even as a
> confused deputy?) made under the "wrong" account.
Remove as suggested.
> Section 7.2
>
>     It is, however, not possible to exploit accidental delivery of the
>     OOB message to the wrong device when the user makes an unexpected
>     mistake.  This is because the wrong peer device would not have
>     prepared for the attack by performing the Initial Exchange with the
>     server.  [...]
>
> I'm not entirely sure that I understand what's being said here.  IIUC an
> attacker could well try to perform an initial exchange in parallel with
> the legitimate device, keyed on by perhaps some environmental factors,
> observing the user at another device, etc.  But the attack would only
> succeed if it was actively claiming the PeerId of the legitimate device,
> and the legitimate device would have some failed exchange(s) that might
> be able to detect the attack.  Just saying "would not have prepared"
> doesn't really help me understand how much (or how little) risk there
> is.
This section has been re-written. Looking at the diff will help.
>     After the device registration, an attacker could clone the device
>     identity by copying the keys from the persistent EAP-NOOB association
>     into another device.  The attacker can be an outsider who gains
>     access to the keys or the device owner who wants to have two devices
>     matching the same registration.  The cloning threats can be mitigated
>     by creating the cryptographic keys and storing the persistent EAP-
>     NOOB association on the peer device in a secure hardware component
>     such as a trusted execution environment (TEE).  Furthermore, remote
>     attestation on the application level could provide assurance to the
>     server that the device has not been cloned.
>
> Please mention that doing a KeyingMode-3 reconnect would drop any cloned
> devices from being able to associate as that identity.
Added: Reconnect Exchange with a new cryptosuite (KeyingMode=3) will 
also disconnect all but the first clone that performs the update.
> Section 7.4
>
>     EAP-NOOB.  The server SHOULD assign a random or pseudo-random PeerId
>     to each new peer.  It SHOULD NOT select the PeerId based on any peer
>     characteristics that it may know, such as the peer's link-layer
>     network address.
>
> Should we say anything to prevent the server from re-using a PeerId
> (which would be a natural thing to do if this SHOULD NOT is ignored)?

The server will not accidentally reuse a PeerID that is still in use 
with some other EAP-NOOB association. If the server reuses a PeerID from 
a past EAP-NOOB association, it doesn't compromise security. The new 
peer can use the assigned PeerId, while the old peer's attempts to 
reconnect will fail in any case.

> Section 7.6
>
>     As an additional precaution, the EAP server and peer MUST check for
>     downgrading attacks in the Reconnect Exchange as follows.  As long as
>     the server or peer saves any information about the other endpoint, it
>     MUST also remember the previously negotiated cryptosuite and MUST NOT
>     accept renegotiation of any cryptosuite that is known to be weaker
>     than the previous one, such as a deprecated cryptosuite.  Determining
>     the relative strength of the cryptosuites is out of scope and may be
>     managed by implementations or by local policies at the peer and
>     server.
>
> There is no fundamental guarantee that the peer and server will use the
> same ordering for relative strength of ciphersuites.  This could in
> theory lead to a situation where any attempt to change ciphersuite is
> rejected by the other party, and the participants are stuck on a single
> ciphersuite.  However, it's not really clear that there would be
> significant practical consequences if that actually happened.
Agreed. In practice, we would expect the IETF to deprecate the old 
clearly less secure ciphersuite.
> Section 7.9
>
> Looking through the security claims, it seems pretty clear that the
> mutual nonces give replay protection for the Initial and Reconnect
> exchanges, but I didn't immediately see what provided replay protection
> for the Completion exchange.  I suspect it's just the local state on
> both parties that would not produce a state transition on the basis of a
> replayed exchange, but please confirm.  (It might be worth a brief
> discussion in the document about how replay protection is attained,
> though I could pretty easily be convinced that it's not worth it.)
The Completion exchange always comes after an Initial Exchange and the 
nonces from the Initial Exchange provide the freshness. While we 
understand your question, we would prefer not to explain how freshness 
is achieved in the key exchange because a complete explanation could 
lead to a lengthy tutorial on security protocols.
> Section 8.2
>
> Since we use it to specify by reference the content of a protocol field,
> [EUI-48] may well be classified as normative.
We have made the reference normative.
> I also don't think that RFC 4266 is the right reference for URLs in
> general.
We have changed the reference to RFC 3986.
> Appendix A
>
> What do the asterisks in the middle column in Figure 12 indicate?
We have removed the stray asterisks.
> Appendix B
>
>     Alternatively, the device may provide some method for the user to
>     configure the NAI of the home network.  This is the user or
>
> Please reiterate here that there can be privacy considerations with
> doing the initial+completion exchange while roaming.
We have added a section on Privacy Considerations.
>     While roaming, the device needs to identify the networks where the
>     EAP-NOOB association can be used to gain network access.  For 802.11
>     access networks, the server MAY send a list of SSID strings in the
>     ServerInfo field called either SSIDList or Base64SSIDList.  The list
>
> [This ServerInfo usage is prior to the roaming event, right?]
That's true.
> Appendix D
>
>     server.  The URL MUST specify the https protocol, so that there is a
>     secure connection to the server and the on-path attacker cannot read
>     or modify the OOB message.
>
> I recognize that the intent is to ban unencrypted http (and support this
> goal), but as written this might prevent the use of other, equally
> secure, URL schemes.
We have now allowed the usage of other equally secure schemes.
>     The ServerInfo in this case includes a field called ServerUrl of the
>     following format with RECOMMENDED length of 60 characters or less:
>
>     https://<host>[:<port>]/[<path>]
>
>     To this, the peer appends the OOB message fields (PeerId, Noob, Hoob)
>     as a query string.  [...]
>
> To be honest, this feels like a great time to use POST rather than GET
> with query string
POST might be semantically a better match; however, QR code readers use GET.
> (side note) If I understand correctly, this would not have been
> compatible with the previous version of BCP 190, but a recent-ish update
> makes it okay.
>
> Appendix E
>
> These examples all have the "Type" field first in the JSON object, but
> generally the semantics of a JSON object are not dependent on the order
> in which fields appear.  Please consider mentioning in the main text
> something about field order and/or showing the examples in a variety of
> orders.
That's true. The "Type" field does not have to be first in the JSON 
object. The only requirement we have is related to the inputs of the 
cryptographic functions. It is stated as "The array elements MUST be 
copied to the array verbatim from the sent and received in-band 
messages.  When the element is a JSON object, its members MUST NOT be 
reordered or re-encoded.".
> It would also be helpful to show some examples for the key derivation
> steps (IIUC we should the MAC plaintext inputs and the output but not
> the MAC keys).
>
>     These message examples show the case where the peer upgrades to
>     Cryptosuite 2 during the Reconnect Exchange.  The messages are
>     generated with NIST P-256 ECDHE test vectors specified in section 8.1
>     of [RFC5903] (server=responder, peer=initiator).
>
> Are we in a position to show the old/new Kz/etc.?
This is related to text above on why the example messages haven't been 
updated. The number of things in the appendix on example messages keeps 
growing over time. For example, Roman in his review had asked if we 
could show the inputs to the MACs, MACp, etc. calculation. While we do 
agree that such information is useful, it increases the length of the 
draft and adds potential sources of copy-paste errors. The authors have 
come to the conclusion that it is best to ask the RFC editor to remove 
the appendix in its entirety. Instead, we propose to add all the example 
messages to the EMU github page: https://github.com/emu-wg and simply 
reference them in the draft. The current example messages in the draft 
don't show all the error messages/scenarios. Moving the examples to 
github would allow us to more freely add more information and show 
input/output calculations. If, at a later stage, we find it useful to 
publish, we can do something similar to RFC 8448: 
https://datatracker.ietf.org/doc/html/rfc8448. We also plan on hiring an 
intern to help us create a website similar to the illustrated TLS 
connection: https://tls13.ulfheim.net/. That would take some time 
though. Would you (Ben and Roman) agree with our proposed way forward?
> NITS
>
> Section 1
>
>     o  input or output interface that may be capable of only one-
>        directional communication.
>
> Does this refer to the non-network interface?  Presumably the interface
> doing EAP can both send and receive...
Added non-network input or out interface.
>
>     The solution presented here is intended for devices that have either
>     an input or output interface, such as a camera, microphone, display
>
> Likewise, is this an "'out-of-band' input or output interface"?
Added non-network input or output interface.
>
>     This document describes a method for registration, authentication and
>     key derivation for network-connected ubiquitous computing devices,
>
> If devices are truly "ubiquitous", a manual OOB step will not scale and
> fully automated mechanisms like BRSKI will be needed.  Perhaps a
> different word than "ubiquitous" could be used?
Changed to smart devices.
>
>     registration codes.  One reason for requiring dynamic OOB messages is
>     that the receipt of the OOB message authorizes the server to take
>     ownership of the device.  This is more secure than a static printed
>     code, which could be leaked and later misused.
>
> I think we should not use the pronoun "this", since it could be misread
> as referring to the act of having the OOB message authorize the server
> to take over the device (vs the intended "using dynamic OOB messages").
Good point. Updated to : "Dynamic OOB messages are more secure.."
>
> Section 3.2.2
>
>     versions and cryptosuites.  The peer sends a response (Type=2) with
>     the selected protocol version (Verp), the received PeerId, the
>     selected cryptosuite (Cryptosuitep), an indicator of the OOB channel
>     directions selected by the peer (Dirp), and a PeerInfo object.  In
>
> "directions" plural are selected?  Perhaps "direction(s)"?
Fixed.
>
> Section 3.2.3
>
>     The OOB receiver MUST compare the received value of the fingerprint
>     Hoob (see Section 3.3.2) with a value that it computes locally for
>
> Maybe s/computes/computed/?  It seems like it would be more natural to
> digest things and only save the (PeerId, Noob, Hoob) state rather than
> the entire transcript and key-share, which implies that the value is
> computed before the OOB message arrives.
Changed.
>
>     message to the user.  The receiver SHOULD reject invalid OOB messages
>     without changing its state, until an application-specific number of
>     invalid messages (OobRetries) has been reached, after which the
>
> (pedantic nit) tracking the number of invalid messages inherently
> requires "changing its state".
We made it more precise by saying "without changing its state in the 
association state machine,..."
>
> Section 3.2.4
>
>                                                                     Also,
>     if both sides support the server-to-peer direction of the OOB
>     exchange and the peer receives the OOB message, it SHOULD initiate
>     the EAP-NOOB method immediately.  [...]
>
> Both sides support, or the peer selects to use?
Fixed to : If the OOB channel directions selected by the peer include 
the server-to-peer direction and the peer receives the OOB message, ...
>
> Section 3.3.1
>
>     server sent a NewNAI in the latest Initial Exchange, the peer MUST
>     use this serve-assigned NAI.  When the peer moves to the Registered
>
> s/serve-/server-/
Fixed.
>
> Section 7.1
>
>     passphrase that is shared by all the network stations.  The advantage
>     of an EAP-based solution, including EAP-NOOB, is that it establishes
>     a different master secret for each peer device, which makes the
>
> I suggest using a different term than "master secret", perhaps just
> "shared secret".
Changed to shared secret.
>
>     Forward secrecy during fast reconnect in EAP-NOOB is optional.  The
>     Reconnect Exchange in EAP-NOOB provides forward secrecy only if both
>     the server and peer send their fresh ECDHE keys.  This allows both
>     the server and the peer to limit the frequency of the costly
>     computation that is required for forward secrecy.  [...]
>
> We should say something about the case where the peer reuses its ECDH
> share but the server generates a fresh one.  (Also, as mentioned
> previously, the hash-forward scheme can provide some forward secrecy
> without an ECDH exchange.)

Added a para: Another way in which some servers may control their 
computational load is to reuse the same ECDHE key for all peers over a 
short server-specific time window.  In that case, forward secrecy will 
be achieved only after the server updates its ECDHE key, which may be a 
reasonable trade-off between security and performance.  However, the 
server MUST NOT reuse the same ECDHE key with the same peer when 
rekeying with ECDHE (KeyingMode=2 or KeyingMode=3).  Instead, it can 
simply not send an ECDHE key (KeyingMode=1).

> Section 7.4
>
>     User reset or failure in the OOB Step can cause the peer to perform
>     many Initial Exchanges with the server, to allocate many PeerId
>     values, and to store the ephemeral protocol state for them.  The peer
>     will typically only remember the latest one.  EAP-NOOB leaves it to
>
> I think we want to s/to store/the server to store/
Updated as suggested.
>
> Appendix D
>
>     server.  The URL MUST specify the https protocol, so that there is a
>     secure connection to the server and the on-path attacker cannot read
>     or modify the OOB message.
>
> s/protocol/scheme/
Updated as suggested.
>
>
>
> _______________________________________________
> Emu mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/emu