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")? _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
