Re: [auth48] AUTH48: RFC-to-be 9427 <draft-ietf-emu-tls-eap-types-13> for your review

[Alan DeKok <[e-mail]>]

On Jun 9, 2023, at 2:02 PM, [e-mail] wrote:
> 
> Authors,
> 
> While reviewing this document during AUTH48, please resolve (as necessary) 
> the following questions, which are also in the XML file.
> 
> 1) <!-- [rfced] Please note that the title of the document has been updated 
> as follows: abbreviations have been expanded per Section 3.6 of RFC 7322 
> ("RFC Style Guide"). Please review.
> 
> Also, should "and" be "for", since the text says that the methods described 
> in this document are to be used with TLS 1.3?

  I believe "and" is acceptable.  Either that, or "for use with TLS 1.3".

  i.e. we are not modifying TLS 1.3, we are describing how the EAP protocols can use TLS 1.3.

  Using "for TLS 1.3" implies to me that we are modifying TLS 1.3, which is not the case.

  Either "and" or "for use with" would be fine by me here.  I have no strong preference.

> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the 
> title) for use on https://www.rfc-editor.org/search. -->

  TTLS, PEAP. FAST, TEAP

 Not much else comes to mind.

> 3) <!-- [rfced] Should the following sentence in the Abstract be updated
> to include the mention of "PEAP" in order to make the content in
> the Abstract parallel to the Introduction? 

  Yes.  The change is fine.

> 4) <!-- [rfced] May we update the following sentence in the Introduction 
> for easy readability?

  Yes.

> 5) <!-- [rfced] Please review each artwork element in the xml file. 
> Specifically, should any artwork element be tagged as sourcecode or another 
> element?
> -->

  I don't think any artwork element should be tagged.  Some of the ASCII art is pseudocode, but that is not in any particular programming language.

> 6) <!-- [rfced] May we change "TLS-Exporter" to "TLS-Exporter function" 
> since the latter appears consistently throughout the document?

  Yes.

> 7) <!-- [rfced] In Section 2.2, the following line is one character over 
> the limit for the text output (note that there is a 72-character limit for 
> artwork). Please let us know how to update so that the artwork will fit.
> 
> Original:
>   EMSK = TLS-Exporter("EXPORTER: Extended Session Key Generating Function",
> -->

  Perhaps just add a line break after the bracket:

MSK  = TLS-Exporter(
             "EXPORTER: Session Key Generating Function",
              S-IMCK[n], 64)

EMSK = TLS-Exporter(
              "EXPORTER: Extended Session Key Generating Function",
               S-IMCK[n], 64)

> 8) <!-- [rfced] Should we rephrase the following sentence to avoid
> repetition of "MAC"?

  I think the repetition is fine.  It was added as a direct result of confusion raised in the WG reviews.

> 9) <!-- [rfced] FYI - We are unable to locate and verify the direct quote
> provided below in Section 7.6 of RFC 7170. However, we do see this quote
> in Section 7.6 of RFC 5281. We have updated the citation to "Section 7.6
> of [RFC5281]" from "[RFC7170] Section 7.6". Please let us know if this
> change is incorrect.

  That's fine.

> 10) <!-- [rfced] The reference associated with the citation tag [PEAP-PRF]
> in the text below does not display the direct quote listed in
> this section. However, the reference associated with the citation
> tag [PEAP-TK] contains this direct quote. We have updated the
> text as follows to accurately reflect the correct citation. 
> Please let us know if this change is incorrect.

  That's fine.

> 11) <!-- [rfced] May we rephrase this sentence as follows for an improved 
> flow of the text?

  The original phrasing is preferred.  The inner identity here could be something other than a "fully qualified" name.  As such, there has to be a clear separation between inner identities which are fully qualified, and ones which are not.

  As a result, the example of "user name plus realm" is best associated with the "fully qualified" phrase, and not with the "inner identity" phrase.

> 12) <!-- [rfced] In Section 3.1, may we introduce the second sentence as 
> follows to avoid repetition of "For example..." from the paragraph before?

  Yes.

> 13)  <!--[rfced] Would you like to include another example in addition to
> "identities" so that there is a list two items followed by
> "etc."?  If you would only like to list "identities",
> may we rephrase the text as follows? Please let us know your
> preference.

  Perhaps:

 The requirements on identities, use of TLS cipher suites, resumption, etc. remain unchanged from that
  document.

> 14) <!--[rfced] Please clarify the following sentence. Should "by" be
> "for", or should the text be rephrased for clarity as follows? 
> Please let us know your preference.

  The intent is to say "this document also has makes of the same requirements as RFC 9190 Section 5".

  So I think "by reference" is correct here.

> 15) <!-- [rfced] We believe that the citation [RFC84346] is a typo, so we 
> have updated it to [RFC8446]. Please let us know if this change is
> incorrect. Additionally, we have updated "allows that" to "states" for
> improved readability.

  The change is fine.

> 16) <!-- [rfced] FYI - We have updated the titles of the reference entries
> below to match what appears at the landing page of their
> corresponding URLs.

  That's fine.

> 17) <!-- [rfced] Please review the "Inclusive Language" portion of the 
> online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
> and let us know if any changes are needed. For example, please consider 
> whether the term "master" should be updated. -->

  The use of that term is taken from previous specifications, which have not (at this time) been updated.  So the term is normative, and needs to remain in order for the text to be comprehensible.

  Alan DeKok.