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

[Karen Moore <[e-mail]>]

Hi Alan,

Thank you for your reply; we have updated our files accordingly.  Please see a few notes below.

1) FYI - For clarity, we updated the document title per your suggestion (i.e., "TLS-Based Extensible Authentication Protocol (EAP) Types for Use with TLS 1.3”). We also updated the short title that spans the header of the PDF (i.e., TLS-Based EAP Types for Use with TLS 1.3).

2) We updated the lines that were too long in Section 2.2 per your suggestion; please review the format in one of the output files and let us know if any further changes are needed.

> <!-- [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",
> -->

FILES:
The updated XML file is here:
 https://www.rfc-editor.org/authors/rfc9427.xml

The updated output files are here:
 https://www.rfc-editor.org/authors/rfc9427.txt
 https://www.rfc-editor.org/authors/rfc9427.pdf
 https://www.rfc-editor.org/authors/rfc9427.html

This diff file shows all changes made during AUTH48:
 https://www.rfc-editor.org/authors/rfc9427-auth48diff.html

This diff file shows all changes made to date:
 https://www.rfc-editor.org/authors/rfc9427-diff.html

Note that it may be necessary for you to refresh your browser to view the most recent version. Please review the document carefully to ensure satisfaction as we do not make changes once it has been published as an RFC.

Please contact us with any further updates or with your approval of the document in its current form.  We will await approval prior to moving forward in the publication process.

For the AUTH48 status of this document, please see:
 https://www.rfc-editor.org/auth48/rfc9427

Thank you,

RFC Editor/kc


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