On Jun 9, 2020, at 11:27 PM, Benjamin Kaduk via Datatracker <nore...@ietf.org> wrote: > 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)?
Yes, fixed. > We need some kind of a reference for PEAP. (Is > draft-josefsson-pppext-eap-tls-eap tolerable?) I'll add that, along with a link to the official Microsoft documentation for PEAP. > > 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? I'll use "fast reconnect" for consistency with the previous standards. However, some of the packet flows in those documents refer to "Reauthentication". I'll use that in this document, again for consistency. > 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 don't think so. The documents are all fairly clear that internal calculations of fields are done with the clear-text version, and not with the "on the wire" encrypted version. > 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 have fewer opinions about that. Perhaps someone else can chime in. > 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. Done. > Section 1 > > The IEEE is defining FILS authentication [FILS], which needs the EAP > > nit: can we expand Fast Initial Link Setup here? Done. > 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? Yes. > 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). I think it makes the definition of Session-Id clearer. I'm not sure what the alternative would be. > 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. Sure. I can delete that paragraph. > 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. Sure. > 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. I'll add some text. > 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"? Fixed. > 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. The PEAP Session-Id definition is used in all known PEAP implementations. I'm less sure about EAP-AKA / SIM implementations. I know hostap supports it. > 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.) Yes, PEAP is define for use with TLS 1.1. However, draft-ietf-tls-oldversions-deprecate deprecates everything before TLS 1.2 > 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.) Yes. I'll add some text. > "No known security issues" is a pretty low bar. Who has looked (how > hard?) and what are their qualifications? Perhaps it should say "little security analysis has been done" > Section 6.1 > > I don't think RFC 6696 needs to be a normative reference. Sure. > Acknowledgments > > I guess we should mark eid 5011 as "Hold For Document Update" before > this document gets published (it's currently just "Reported")? Yes. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
