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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Tue, 09 Jun 2020 20:27:53 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-emu-eap-session-id-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 IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-session-id/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Should be a couple easy ones:

Section 2.2 discusses the "AT_MAC attribute from the
EAP-Request/AKA-Reauthentication" in the context of computing the
EAP-SIM Session-Id, but there is no such EAP-Request message for
EAP-SIM.  Presumably it should be "EAP-Request/SIM/Re-authentication",
and a similar change in Session 2.3 (which would need to cover both the
AKA and SIM cases)?

We need some kind of a reference for PEAP.  (Is
draft-josefsson-pppext-eap-tls-eap tolerable?)

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm pretty underwhelmed by the level of security analysis that this
document suggests has been done for these new Session-Id constructions.
That said, it's probably still worth publishing the document so that
everyone agrees on the same construction, and they seem to already be in
sufficiently wide use that we'll have a fire drill if there's a problem
with the construction, whether or not we hold up the document to get
more analysis.

RFC 5247 (and 3748) refer to a "fast reconnect" mechanism, not a "fast
re-authentication" mechanism as we discuss it here (though it does
discuss "fast EAP re-authentication").  Is there a consistent
terminology to settle on?

Also, some of the attributes we use for the fast re-authentication
Session-Id generation are encrypted for transit.  Should we say
something about the decrypted version being needed for producing the
right input?

I also want to mention an observation that I made (which may itself be
erroneous), and ask how that relates to the Session-Id usage: in
EAP-AKA, the full authentication's Session-Id construction uses just the
RAND and AUTN, which are server-generated and are related in a way that
can be validated using just(?) the peer's identity as additional input.
When we start pulling in AT_MAC for the fast re-authentication
Session-Id, the MAC can no longer be validated without the context of the
full EAP packet it was obtained from.  I don't know of any case where
there would be a need to do internal consistency checking on a
Session-Id in a way that's made difficult by using AT_MAC divorced from
the containing EAP packet, but it seemed worth checking.

I agree with the genart reviewer that the abstract+introduction should
mention that the definition of Session-Id for EAP-SIM full
authentication gets some additional clarification.

Section 1

   The IEEE is defining FILS authentication [FILS], which needs the EAP

nit: can we expand Fast Initial Link Setup here?

   Further, [RFC5247] did not define Session-Id for PEAP. We correct
   these deficiencies here by updating [RFC5247] with the Session-Id
   derivation during fast-authentication exchange for EAP-SIM and EAP-
   AKA; and defining Session-Id derivation for PEAP.

Perhaps note that this definition for PEAP is for both the
fast-authentication and full-authentication cases?

Section 2.2

It's not entirely clear that we need to expend the text to introduce the
"RAND1", "RAND2", "RAND3" terminology, that AFAICT is not defined in RFC
4186 itself (though it is used in one example).

Also, I'm not entirely sure why we copy the Peer-Id/Server-Id paragraph
unchanged and put the fast re-auth case after it for EAP-SIM, when we
ignored that paragraph for EAP-AKA.

Section 2.3

   re-authentication case. Based on [RFC4187] Section 5.2, and similar
   text in [RFC4186], NONCE_S corresponds to RAND and MAC in EAP-

The RFC 4186 text is its section 5.2 (as well), which might be worth
mentioning more clearly.

   Request/AKA-Reauthentication corresponds to AUTN. That would seem to
   imply that the Session-Id could be defined using NONCE_S and MAC
   instead of RAND and AUTN/NONCE_MT.

This "would seem to imply" language is not terribly confidence
inspiring.  Perhaps we want to talk about providing a random value
contributed by the server and a value derived from that random value
with inclusion of secret key material and the peer's identity, which
seem to be the relevant "corresponding properties" to this reader.  My
question above about independent validation still stands, though.

Section 3

   Protected EAP (PEAP).  For consistency with EAP-TLS the definition
   given in [RFC5216] Section 2.3, we define it as:

nit: the grammar here is a bit wonky, perhaps "consistency with the
definition given in [RFC5216] Section 2.3 for EAP-TLS"?

   This definition is already in wide-spread use in multiple PEAP
   implementations.

More details about these implementations (and, for that matter, the
EAP-AKA and EAP-SIM ones) in the shepherd writeup would have been
helpful.

   Note that this definition for Session-Id only applies when TLS 1.2 is
   used.  A different derivation is defined for TLS 1.3 in [TLS-EAP-

Is PEAP defined for use with TLS 1.1 or prior?  (I know that we're in
the process of deprecating TLS prior to 1.2, but that's not quite done
yet.)

Section 4

We probably want to say something about how these constructions are
unique per session and unforgeable+unguessable by an outside party.
(Section 5.10 of RFC 5247 implies a need for the unguessable property.)

"No known security issues" is a pretty low bar.  Who has looked (how
hard?) and what are their qualifications?

Section 6.1

I don't think RFC 6696 needs to be a normative reference.

Acknowledgments

I guess we should mark eid 5011 as "Hold For Document Update" before
this document gets published (it's currently just "Reported")?