Re: [Emu] Working Group Last Call for TLS-based EAP types and TLS 1.3

[Alan DeKok <[e-mail]>]

On Feb 19, 2022, at 3:44 AM, John Mattsson <john.mattsson=[e-mail]> wrote:
> Comments:
>  
> - The MAC function in section 2.2 is not defined. I assume it should be HMAC. Suggestion:
>  
>   OLD
>      For TLS 1.3, the hash function used is the same as the
>      ciphersuite hash function negotiated for HKDF in the key schedule, as
>      per section 7.1 of RFC 8446.
>   NEW
>      For TLS 1.3, MAC is HMAC using the ciphersuite hash function negotiated for
>      HKDF in the key schedule, as per section 7.1 of RFC 8446.

  It's good to define "MAC" here.  The construct "MAC is HMAC" sounds awkward to me tho.  I'll try to come up with some phrasing.
>  
> - "As the outer identity is simply an anonymous routing identifier"
>   "The outer identity contains an NAI realm, which ensures that
>    the inner authentication method is routed to the correct destination."
>  
>    Is this section talking about two different "outer identifier"? The identity in the
>    identity response is a routing identifier. Security properties like "ensures" is
>    given be the identity in the TLS server certificate (to my understanding).

  The word "ensures" here is not a security property.  It is used more in the sense of "allows", or "makes sure that".

> Editorial comments:
>  
> - The RFC style guide RFC 7322 states that the abstract must not contain citations.
>  
> - draft-ietf-emu-eap-tls13 is now RFC 9190. Some text in abstract and intro should be updated from "is being updated" to "has been updated".
>  
> - Section 1 Introduction should say something like "This document updates those methods in order to use the new key derivation methods available in TLS 1.3." The current formulations are "we wish" and "it is necessary".
>  
> - "MSK and EMSK are then derived",
>   Suggestion "The outer MSK and EMSK are then derived"

  Fixed all of the above.

> - "Unlike previous TLS versions, TLS 1.3 can continue negotiation after the initial
>    TLS handshake has been completed"
>  
>   Previous TLS versions had renegotiation.

   Which is re-starting the TLS handshake in the middle of a session.  So far as I'm aware, no EAP client or server supports that functionality.  RFC 5216 (and now 9190) are entirely silent on this topic.  Which further says to me that no one uses it.

  The comment in the document is not about re-negotiation.  In TLS <1.3, when the application sees "TLS init finished", it means that no additional TLS handshake messages will be sent for the current session.  So the application can *implicitly* assume that any further TLS exchanges contain only application data.

  This assumption isn't true for TLS 1.3.  interoperability tests among implementors showed that most, if not all, implementations required updates to correct this wrong assumption.  As such, it's useful for the specification to warn implementors about common issues.

>  
> - OLD
>     but less interest in EAP-FAST and TTLS.
>   NEW
>     but less interest in EAP-FAST and TEAP.

  Fixed.

> - "do not provide for protected success and failure indicators as part of the
>    outer TLS exchange."
>  
>    Could be good to inform the reader that the TLS alerts are still sent (I assume)
>    but not used by EAP.

   I'm not sure why there's any need for a change here.  TLS-based EAP methods use all features of TLS, including alerts.  Those alerts don't signal any state changes in EAP, and thus aren't used by the EAP state machine.  However, they are used by implementors to inform end users about configuration / incompatibility issues.  RFC 9190 has a significant discussion of TLS alerts already, and this document just references that.

> - "concatetation" 
>   "cloude"
>   "changover"
>   "deriviation"
>   "authenticaton"
>   "succeeed"
>   "identies" (several places)
>   "ciphersuite" (TLS uses the spelling cipher suite)
>   "NewSessionTicketMessage" (NEW: NewSessionTicket message)

  Fixed, thanks.

  Alan DeKok.