On Nov 18, 2022, at 8:50 AM, Heikki Vatiainen <[email protected]> wrote:
>
> Please find below some fixes and suggestions for
> draft-ietf-emu-tls-eap-types-09
>
> Apart from the first item (TEAP label), which could also be considered a
> typo, I think these are clarifications, not functional changes.
I agree.
>
> Labels used with TEAP
> ++++++++++++++++++++
> Section 2.2 says:
>
> session_key_seed = TLS-Exporter("EXPORTER: session key seed", Type, 40)
>
> This is missing 'teap ' and should be:
> session_key_seed = TLS-Exporter("EXPORTER: teap session key seed", Type, 40)
Fixed, thanks. This aligns the document with RFC 7170.
> TLS Finished
> ++++++++++++
> Search for 'finished' shows that TLS Finished message is written, and
> sometimes used, in different ways. My suggestion is to replace the variations
> with: Finished message
>
> 'Finished message' is what the TLSv1.3 RFC mostly uses too. This draft
> already uses, for example, 'NewSessionTicket message' therefore 'Finished
> message' would be a good match.
Fixed.
> Other Finished message / CONNECTED state notes
> ----------------------------------------------
> The first paragraph in section "3. Application Data" currently says:
> Some implementations use a "TLS finished" determination as an indication
> ...
>
> This might be better written as:
> Some implementations use receipt of Finished message as an indication ...
I think that's good.
> The second paragraph in section 3. says:
> ... a transition to "TLS finished" also meant that there was no
> application data available ...
>
> Because there's no such TLS state, a fix could be:
> ... a receipt of Finished message also meant that there was no application
> data available ...
That's good.
> The first sentence in the second paragraph of section 3. says '"TLS finished"
> method' which is one case where simple 'Finished message' would work.
Fixed.
> Indication vs indicator
> ++++++++++++++++++++++
> EAP-TLSv1.3 RFC 9190 does not use 'indicator', it only uses 'indication'.
> This draft uses the both, mostly indicator, but it might be clearer to use
> 'indication' to match RFC 9190.
Fixed, thanks.
> Spelling of CHAP variations
> +++++++++++++++++++++++++++
> Suggestion: Search for 'CHAP' and ensure that only 'CHAP', 'MS-CHAP-V1' and
> 'MS-CHAP-V2' are used for the non-EAP variations.
Fixed.
> Section 6.1., inner tunnel replacements
> +++++++++++++++++++++++++++++++++++++++
> Paragraph starting with 'It is RECOMMENDED ...' does not suggest using
> MS-CHAP-V2 or EAP-MSCHAPv2 as a replacements for MS-CHAP-V1. Adding this
> would match the previous paragraph.
I agree. I've fixed it.
>
> Other minor suggestions and fixes
> +++++++++++++++++++++++++++++++++
> EAP-Response/Identity could be used as the common notation for the two uses
> in section 3.1.
Fixed.
> Section 6.1 has '... do not provided ...'. Remove 'ed'.
Fixed.
> Section 7 has a typo: tje
Fixed.
Thanks for the comments. Hopefully we can get an IETF last call soon.
Alan DeKok.
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
