Re: [Emu] Working Group Last Call for draft-ietf-emu-tls-eap-types

[Alan DeKok <[e-mail]>]

On Jun 13, 2022, at 3:57 PM, Russ Housley <[e-mail]> wrote:
> 
> Major concerns:
> 
> Section 3, 3rd para: It is unclear to me what "relevant resumption and/or EAP type" means.  Please expand this discussion.

  In context:


As a result, implementations MUST check for application data once the
TLS session has been established.  This check MUST be performed before
proceeding with another round trip of TLS negotiation.  If application
data is available, it MUST be processed according to the relevant
resumption and/or EAP type.

  The intent here is to say "if there's application data, just use that".  I think the reference to "resumption" is superfluous, and can be removed or clarified.

  Perhaps:

As a result, implementations MUST check for application data once the
TLS session has been established.  This check MUST be performed before
proceeding with another round trip of TLS negotiation.  If application data is
received by the EAP peer, any session tickets offered by the supplicant
MUST be ignored, and resumption MUST NOT take place.

The interpretation and processing of application data is dependent on the EAP type
which has been negotiated.  On receiving application data, an EAP implementation
MUST follow the relevant specification (defined by the EAP type) for processing
that application data.

  We didn't need similar text for TTLS / PEAP / FAST, because application data was always interpreted as that particular EAP type.  We need some clarifying text here, because we're talking about TLS-based EAP types in general, and not any specific type.

  I'm not sure how to clarify this any more, otherwise than by deleting the text.

> Minor concerns:
> 
> Section 2 says:
> 
>    There remain some differences between EAP-TLS and other TLS-based EAP
>    methods which necessitates this document.  The main difference is
>    that [RFC9190] uses the EAP-TLS Type (value 0x0D) in a number of
>    calculations, whereas other method types will use their own Type
>    value instead of the EAP-TLS Type value.  This topic is discussed
>    further below in Section 2.
> 
> I assume this should be a forward pointer to Section 2.1.

  Sure.

> Section 2.1 uses || to indicate concatenation, but Section 2.2 uses |.  Please pick one.

  RFC 9190 uses ||, so we'll stick with that.  The text in Section 2.2 was lifted from RFC 7170, which uses |

> 
> Section 2.1 says:
> 
>    ...  There does not
>    appear to be compelling reasons to make the labels method-specific,
>    when they can just include the logical Type in the key derivation.
> 
> I think it would be more clear to say that the inclusion of the logical Type makes the result method-specific.

  OK.  I'll update the text.

> 
> Nit:  The author on the title page should be "A. DeKok"

  Fixed, thanks.

 Alan DeKok.