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

From: Roman Danyliw <[email-masked]>
Date: Wed, 13 May 2020 20:25:49 +0000

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.

(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.

(3) Section 2.2.  Editorial.

OLD
Similarly for EAP-SIM, it says:
NEW
Similarly, for EAP-SIM, [RFC5247] Appendix A says:

(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  ...

(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."

(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."

Regards,
Roman

---

From: Alan DeKok <[email-masked]>
Date: Wed, 13 May 2020 17:12:22 -0400

> 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…

  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.

> Similarly, for EAP-SIM, [RFC5247] Appendix A says:

  Fixed.

> EAP-SIM is defined in [RFC4186].  When using full authentication, the EAP-SIM Session-Id is the  ...

 Fixed.
 
> "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.

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 14 May 2020 00:09:06 +0000

Hi Alan!

Thanks for the quick response.  Since these are minor, I already started the IETF LC.  Nevertheless, having an updated draft with these changes is even better.

More inline ...

> -----Original Message-----
> From: Alan DeKok <[email-masked]>
> Sent: Wednesday, May 13, 2020 5:12 PM
> To: Roman Danyliw <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Emu] AD Review of draft-ietf-emu-eap-session-id-02
> 
> > 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 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.

The above text works for me.

> > (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.
> 

Much appreciated!

Thanks,
Roman