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

[Benjamin Kaduk via Datatracker <[e-mail]>]

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 to https://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").

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).


----------------------------------------------------------------------
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.

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.

   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?

   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.

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?

Section 3.2.3

Can we give any guidance for how to set OobRetries?

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.

   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.

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.

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.]

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...

   | 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]?

   | 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.

   | 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.

   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?

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 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).

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.

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.

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?

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.

   | 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.

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.

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.)

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.

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.

   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.

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)?

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.

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.)

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.

I also don't think that RFC 4266 is the right reference for URLs in
general.

Appendix A

What do the asterisks in the middle column in Figure 12 indicate?

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.

   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?]

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.

   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

(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.

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.?

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...

   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"?

   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?

   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").

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)"?

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.

   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".

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?

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-/

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".

   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.)

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/

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/