Last Call Review of draft-ietf-emu-eap-session-id-04
review-ietf-emu-eap-session-id-04-genart-lc-yee-2020-06-03-00

Request Review of draft-ietf-emu-eap-session-id
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2020-05-27
Requested 2020-05-13
Authors Alan DeKok
Draft last updated 2020-06-03
Completed reviews Secdir Last Call review of -03 by Mališa Vučinić (diff)
Genart Last Call review of -04 by Peter Yee (diff)
Opsdir Last Call review of -03 by Menachem Dodge (diff)
Assignment Reviewer Peter Yee 
State Completed
Review review-ietf-emu-eap-session-id-04-genart-lc-yee-2020-06-03
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/sSAgPG9GiTwfcVqFQ04qdeAfes0
Reviewed rev. 04 (document currently at 07)
Review result Ready with Issues
Review completed: 2020-06-03

Review
review-ietf-emu-eap-session-id-04-genart-lc-yee-2020-06-03

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-emu-eap-session-id-04
Reviewer: Peter Yee
Review Date: 2020-06-03
IETF LC End Date: 2020-05-27
IESG Telechat date: 2020-06-11

Summary: This draft adds the definition of EAP Session-ID for EAP-SIM and EAP-AKA when using fast re-authentication. Those changes look fine, but one other change should be better highlighted. [Ready with Issues]

Major issues: None

Minor issues:

Page 4, Section 1, 3rd paragraph. Aside from correcting the deficiencies in the fast re-authentication cases, you also have updated the EAP-SIM full authentication Session-ID derivation as well. This really ought to be mentioned here in the introduction because that change goes beyond the purported scope of the document (dealing with fast re-authentication). I believe the change you have made (substituting the RAND values from the first two authentication triplets for the RAND in AT_RAND) is fine, although I dislike RAND1 and RAND2 which are not specified in RFC 4186 (or in this draft) except by usage in an example in the test vectors annex. While that's not really your problem, it would be good if it were there were prescriptive text that explain what RAND1 and RAND2 mean.

Nits/editorial comments:

Page 4, 2nd paragraph, 1st sentence: change "is defining" to "has defined". IEEE 802.11ai completed the FILS specification several years ago.

Page 7, Section 3, 1st paragraph, 1st sentence: change "define" to "provide a", just so we aren't defining a definition.