Re: [Emu] Review of draft-ietf-emu-eap-tls13

[Alan DeKok <[e-mail]>]

On Mar 30, 2021, at 1:01 AM, Joseph Salowey <[e-mail]> wrote:
> 
> I went through the review and created issues for the ones that were not covered by existing issues or PRs.  Some issues, such as Issue 58 on nits contain several of the comments below.  

  Thanks.

> Issues may be discussed on the list or in github issues, however resolutions for any normative or substantial text not discussed on the list are to be posted to the list before resolution.  Therefore it would be better to have substantial changes discussed on the mailing list.  

  OK.

> [Joe]  It seems it would be sufficient to just add "backwards compatible through TLS version negotiation. 

  Yes.  It would be good also to note that the changes in this document are only to be applied when TLS 1.3 is used.  This limitation means that the old TLS 1.2 state machines are not modified by this specification.

> [Joe] I think the best thing to do here is to say the key update MUST NOT be sent and SHOULD be ignored if it is received.  

  Yes.

> Section 2.1.9 says:
> 
>    Some EAP implementations and access networks may limit the number of
>    EAP packet exchanges that can be handled.
> 
> This is under-stating the issue rather severely.  We know with
> absolute certainty that most (if not all) EAP implementations and
> access networks limit the number of EAP packet exchanges.  Perhaps
> update the text to reference implementation and interoperability
> experience.
> 
> [Joe] what is the reference?

https://github.com/FreeRADIUS/freeradius-server/blob/release_3_0_21/src/modules/rlm_eap/mem.c#L449

https://w1.fi/cgit/hostap/tree/src/eap_peer/eap.c?h=hostap_2_9#n35

  Those are stable references to a particular release / tag.  So the code shouldn't change.  Both sets of code implement a limit on the maximum number of round trips they will support.  The limits noted here are both hard-coded to "50".  Later versions of hostap take that limit from a configuration parameter.  FreeRADIUS still hard-codes it to 50.  TBH, I don't really see a compelling reason to change that.

  Jouni Malinen also has a useful comment here:  http://lists.freeradius.org/pipermail/freeradius-users/2009-February/035654.html

... The main (well, more or less, the only) reason for that limit on
number of round trips is to work around issues where the EAP peer and
server ended up in an infinite loop ACKing their messages. ...

  Alan DeKok.