> On Jun 14, 2022, at 2:12 PM, Alan DeKok <al...@deployingradius.com> wrote:
>
> On Jun 13, 2022, at 3:57 PM, Russ Housley <hous...@vigilsec.com> 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
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
