Re: [Emu] AD Review of draft-ietf-emu-eap-session-id-02

[Alan DeKok <[e-mail]>]

On May 13, 2020, at 4:25 PM, Roman Danyliw <[e-mail]> wrote:
> 
> Hi!
> 
> I conducted my AD review of draft-ietf-emu-eap-session-id-02.  The document is in good shape.  I have largely editorial feedback below that can be handled with IETF LC input.
> 
> (1) Section 1.  Editorial.  COMMENTs often come up in IESG review the it isn't clear up front what exactly is being updated.  I recommend something like ...
> 
> OLD
> We correct that deficiency here.
> NEW
> 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.

  Fixed.

> (2) Section 1. Editorial.  Per ..., it would be important to get this resolved with a clearly defined and agreed derivation rules to allow fast re- authentication cases to be used to derive ERP key hierarchy", I'm not sure this additional explanation is needed and this is a run-on sentence from the previous text.

  How about:

The IEEE is defining FILS authentication [FILS], which needs the EAP
Session-Id in order for the EAP Re-authentication Protocol (ERP)
[RFC6696] to work.  It is therefore important to address the existing
deficiencies in the definition of EAP Session-Id.


> (3) Section 2.2.  Editorial.
> 
> OLD
> Similarly for EAP-SIM, it says:
> NEW
> Similarly, for EAP-SIM, [RFC5247] Appendix A says:

  Fixed.

> (4) Section 2.2.  Editorial.  Why not the explicit symmetry in language in EAP-SIM as was used in EAP AKA?
> 
> OLD
> EAP-SIM is defined in [RFC4186].  The EAP-SIM Session-Id is the  ...
> NEW
> EAP-SIM is defined in [RFC4186].  When using full authentication, the EAP-SIM Session-Id is the  ...

 Fixed.
 
> (5) Section 2.2.  Recommend defining RAND1, RAND2 and RAND3 explicitly since RFC4186 only has it in the test vector section.  Perhaps something like:
> 
> "RAND1, RAND2 and RAND3 correspond to the RAND value from the first, second and third GSM triplet respectively."

  Fixed.

> (6) Section 3.  It would be useful to describe the prior work in Security Considerations.  Specifically, "These updates to not modify the Security Considerations outlined in RFC5247."

  Fixed.

  I'll publish a new version shortly.

  Alan DeKok.