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

[Russ Housley <[e-mail]>]

> On Jun 14, 2022, at 2:12 PM, Alan DeKok <[e-mail]> wrote:
> 
> 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.

This is helpful.  Thanks.

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

I think you should just say that: TTLS, PEAP, and FAST each have method-specific application data.

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

Thanks.

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

Either one is fine with me.  Please be consistent.

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

Thanks.

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

Thanks.

This resolves all of my concerns.

Russ