Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the source file.
1) <!-- [rfced] FYI: We have updated the short title of this document, which appears in the running header in the PDF output, as follows. Please let us know any objections. Original: TEAP Current: TEAP Version 1 --> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 3) <!-- [rfced] Please review whether any of the notes in this document should be in the <aside> element. It is defined as "a container for content that is semantically less important or tangential to the content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside). --> 4) <!-- [rfced] Should "functionality" be plural in this sentence? Original: The implementations are interoperable, but only for a subset of the functionality described in [RFC7170]. Perhaps: The implementations are interoperable but only for a subset of the functionalities described in [RFC7170]. --> 5) <!-- [rfced] Section 4.3 of [RFC9325] states the following: "This document does not specify any cipher suites for TLS 1.3. Readers are referred to Section 9.1 of [RFC8446] for cipher suite recommendations." It may be more helpful to the reader to clarify that Section 4.3 of [RFC9325] points to Section 9.1 of [RFC8446]. Or perhaps this sentence should simply point to Section 9.1 of [RFC8446]? Current: Implementations MUST implement the recommended cipher suites in [RFC9325], Section 4.2 for TLS 1.2, and in [RFC9325], Section 4.3 for TLS 1.3. Perhaps: Implementations MUST implement the recommended cipher suites in [RFC9325], Section 4.2 for TLS 1.2 and in [RFC8446], Section 9.1 for TLS 1.3. --> 6) <!-- [rfced] Please review the following sentence. RFC 5280 doesn't use the term "ExtendedKeyUsage" but does use "anyExtendedKeyUsage" and "Extended Key Usage". Let us know if the text below should be clarified. Current: The ExtendedKeyUsage extensions defined in [RFC5280] MAY also be included, but their use is discouraged. --> 7) <!-- [rfced] FYI: For the following sentence, we note that RFC 9525 does not have a Section 6.2.1, but a list of reference identifiers is provided in Section 6.1.2 of RFC 9525; therefore, we have updated the citation accordingly. Please review and let us know of any objections. Original: The realm is used both to construct the list of reference identifiers as defined in [RFC9525], Section 6.2.1, and as the "source domain" field of that same section. Current: The realm is used both to construct the list of reference identifiers as defined in [RFC9525], Section 6.1.2, and as the "source domain" field of that same section. --> 8) <!-- [rfced] Should "passwords" be plural in this instance? Original: Implementations SHOULD support both EAP and basic password for inner methods. Perhaps: Implementations SHOULD support both EAP and basic passwords for inner methods. --> 9) <!-- [rfced] May we rephrase the following sentence for improved readability? Original: The peer MUST respond to the Intermediate-Result TLV indicating its own result and similarly on success MUST accompany the TLV with it's own Crypto-Binding TLV. Perhaps: The peer MUST respond to the Intermediate-Result TLV indicating its own result. Similarly, upon success, the peer MUST accompany the TLV with its own Crypto-Binding TLV. --> 10) <!--[rfced] To clarify the usage of RFC 2119/8174 key words, may we add "MUST" in the sentence below? Original: If the peer receives subsequent Basic-Password-Auth-Req TLVs in the same authentication session, it MUST NOT prompt for a Username, and instead allow the user to enter only a password. Perhaps: If the peer receives subsequent Basic-Password-Auth-Req TLVs in the same authentication session, it MUST NOT prompt for a username and MUST instead allow the user to enter only a password. --> 11) <!-- [rfced] May we rephrase the following sentence? In particular, "...authenticate the server, and fail the current authentication session fails if the server..." seems difficult to parse. Original: Unless the peer requests server unauthenticated provisioning, it MUST authenticate the server, and fail the current authentication session fails if the server cannot be authenticated. Perhaps: Unless the peer requests server unauthenticated provisioning, it MUST authenticate the server and fail the current authentication session. The authentication session fails if the server cannot be authenticated. --> 12) <!-- [rfced] We note that RFC 2986 uses "CertificationRequest" rather than "CertificateRequest". Should "CertificateRequest" be updated in the sentence below to match RFC 2986? Current: A peer sends the Simple PKI Request using a PKCS#10 CertificateRequest [RFC2986] encoded into the body of a PKCS#10 TLV (see Section 4.2.17). Perhaps: A peer sends the Simple PKI Request using a PKCS#10 CertificationRequest [RFC2986] encoded into the body of a PKCS#10 TLV (see Section 4.2.17). --> 13) <!-- [rfced] Please review the following text. RFC 7299 does not contain the term "Extended Key Usage" except for a reference to RFC 5294. Are any updates needed? Current: Another method of limiting the uses of a certificate is to provision it with an appropriate value for the Extended Key Usage field [RFC7299]. --> 14) <!--[rfced] As it is stated that all three items are TLVS, may we update the listed items to avoid redundancy? Original: A Result TLV indicating Failure MUST NOT be accompanied by the following TLVs: NAK, EAP-Payload TLV, or Crypto-Binding TLV. Perhaps: A Result TLV indicating failure MUST NOT be accompanied by the following TLVs: NAK, EAP-Payload, or Crypto-Binding. --> 15) <!-- [rfced] For Sections 4.2.14 through 4.2.20, may we update the TLV definitions to start on a new line to match the convention throughout the rest of the document? See below for an example. Current: M Mandatory, set to one (1) Perhaps: M Mandatory, set to one (1) --> 16) <!-- [rfced] We believe that parentheses were intended in the following list item (we also note that this is the only occurrence of "Identity-Request"). If this is not the case, please let us know. Original: 5. EAP-Payload TLV[Identity-Request] or Basic-Password-Auth-Req TLV Current: 5. EAP-Payload TLV (Identity-Request) or Basic-Password-Auth-Req TLV --> 17) <!-- [rfced] In RFC 7170, we note that the following instances of text nearly match each other with a few exceptions, including "in" before "which kind of packets". Should "in" be removed from the second instance in Section 4.3.2, should "in" be added before "which" in Section 4.3.1, or should the text be left as is? Original (4.3.1): The following table provides a guide to which TLVs may be included in the TEAP packet outside the TLS channel, which kind of packets, and in what quantity: Original (4.3.2): The following table provides a guide to which Inner TLVs may be encapsulated in TLS in TEAP Phase 2, in which kind of packets, and in what quantity. --> 18) <!-- [rfced] May we rephrase the following text for improved readability? Original: The known authenticator implementations support this client, but any other combination of inner methods was not tested. The result is that due to both the complexity of the cryptographic derivations and the lack of interoperability testing, each authenticator implemented entirely different deriviations of the EMSK Compound-MAC field of the Crypto-Binding TLV. Perhaps: The known authenticator implementations support this client, but any other combination of inner methods was not tested. As a result, each authenticator implemented entirely different derivations of the EMSK Compound-MAC field of the Crypto-Binding TLV due to both the complexity of the cryptographic derivations and the lack of interoperability testing. --> 19) <!-- [rfced] We believe that "implement" should be "implementation". Is this correct? Original: In practice, the requirement to use either MSK or EMSK means that an implement MUST track two independent derivations of IMCK[j], one which depends on the MSK, and another which depends on EMSK. Perhaps: In practice, the requirement to use either MSK or EMSK means that an implementation MUST track two independent derivations of IMCK[j], one that depends on the MSK and another that depends on EMSK. --> 20) <!--[rfced] To clarify "(or not)", may we rephrase this sentence as follows? Original: We presume that each of the peer and server have site policies which require (or not) the use of the MSK Compound-MAC and/or the EMSK Compound-MAC. Perhaps: We presume that each peer and server have site policies that may or may not require the use of the MSK Compound-MAC and/or the EMSK Compound-MAC. --> 21) <!--[rfced] To clarify that "earlier versions" is referring to "TEAPv1", may we update "document" to "specification" at the end of this sentence? Original: For this document, we can only ensure that the behavior of TEAPv1 is fully documented, even if that behavior was an unintended consequence of unclear text in earlier versions of this document. Perhaps: For this document, we can only ensure that the behavior of TEAPv1 is fully documented, even if that behavior was an unintended consequence of unclear text in earlier versions of this specification. --> 22) <!-- [rfced] Please review the following text. We note that the abbreviation "CMK" follows "Compound Session Key" even though "CMK" is the abbreviation for "Compound MAC key". Please let us know how this sentence should be updated. Current: After each successful inner EAP authentication, EAP EMSK and/or MSKs are cryptographically combined with key material from TEAP Phase 1 to generate a Compound Session Key (CMK). Perhaps (Compound Session key): After each successful inner EAP authentication, EAP EMSK and/or MSKs are cryptographically combined with key material from TEAP Phase 1 to generate a Compound Session Key. Or: (CMK with no expansion): After each successful inner EAP authentication, EAP EMSK and/or MSKs are cryptographically combined with key material from TEAP Phase 1 to generate a CMK. --> 23) <!-- [rfced] Should this citation be to BCP26 or RFC 8126? Current: This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the TEAP protocol, in accordance with BCP 26 [RFC8126]. --> 24) <!-- [rfced] Should "EAP method" be plural? Current: Protected inner method negotiation, including EAP method Perhaps: Protected inner method negotiation, including EAP methods --> 25) <!-- [rfced] Should this citation be to BCP 86 or RFC 3766? Current: Note 1. BCP 86 [RFC3766] offers advice on appropriate key sizes. The National Institute for Standards and Technology (NIST) also offers advice on appropriate key sizes in [NIST-SP-800-57]. --> 26) <!-- [rfced] It is unclear to us if the citations in the following sentence are meant to point to Section 6 of RFC 3766 or to both RFC 3766 and Section 6 of this document (current). We have left the citations as is. Please review and let us know how the citations may be updated for clarity. Current: [RFC3766], Section 6 advises use of the following required RSA or DH (Diffie-Hellman) module and DSA (Digital Signature Algorithm) subgroup size in bits for a given level of attack resistance in bits. --> 27) <!-- [rfced] May we move the "Changes from RFC 7170" section to the Appendix? --> 28) <!-- [rfced] May we update the following text for conciseness? Original: The document was converted to Markdown, from the [RFC7170] text output. Any formatting changes mostly result from differences between using Markdown versus XML for source. Perhaps: Any formatting changes from [RFC7170] may have resulted from changing from XML to Markdown as the source file when editing the draft --> 29) <!-- [rfced] References a) FYI: We've added URLs for the following references and updated them accordingly. Please review and let us know if you have any objections. [IEEE.802-1X.2020] IEEE, "IEEE Standard for Local and Metropolitan Area Networks - Port-Based Network Access Control", IEEE Std 802.1X-2020, DOI 10.1109/IEEESTD.2020.9018454, February 2020, <https://doi.org/10.1109/IEEESTD.2020.9018454>. [KAMATH] Kamath, V. and A. Palekar, "Microsoft EAP CHAP Extensions", Work in Progress, Internet-Draft, draft- kamath-pppext-eap-mschapv2-02, 19 June 2007, <https://datatracker.ietf.org/doc/html/draft-kamath- pppext-eap-mschapv2-02>. [PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible Authentication Protocol (PEAP)", 24 June 2021, <https://learn.microsoft.com/en- us/openspecs/windows_protocols/ms-peap/5308642b-90c9-4cc4- beec-fb367325c0f9>. b) FYI: We've updated these reference to their most current versions. Please review and let us know if you have any objections. [NIST-SP-800-57] Barker, E., "Recommendation for Key Management: Part 1 - General", NIST SP 800-57 Part 1 Rev. 5, DOI 10.6028/NIST.SP.800-57pt1r5, May 2020, <https://doi.org/10.6028/NIST.SP.800-57pt1r5>. [PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible Authentication Protocol (PEAP)", 24 June 2021, <https://learn.microsoft.com/en- us/openspecs/windows_protocols/ms-peap/5308642b-90c9-4cc4- beec-fb367325c0f9>. [X.690] ITU-T, "Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", February 2021, <https://www.itu.int/rec/T-REC-X.690>. c) RFCs 5077, 5246, and 6961 have been obsoleted by RFC 8446. May we replace them with RFC 8446? If they must be referenced, we suggest mentioning RFC 8446 (e.g., RFC 6961 has been obsoleted by RFC 8446). See Section 4.8.6 in the RFC Style Guide (RFC 7322). --> 30) <!-- [rfced] Please review all verified errata reports for this document and ensure that all relevant errata have been addressed. See https://www.rfc-editor.org/errata/rfc7170. --> 31) <!--[rfced] Citations It appears that the section citations in the following sentences weren't properly converted from Markdown. We have updated the citations based on the anchor tags. Please review and let us know if any further updates are needed. a) {#key-derivations} appears to be a broken citation to Section 6.1 (TEAP Authentication Phase 1: Key Derivations). Original: Implementations also need to implement the inner method ordering described in {#key-derivations}, below, in order to fully prevent on- path attacks. Current: Implementations also need to implement the inner method ordering described in Section 6.1 in order to fully prevent on-path attacks b) {#cert-provisioning} appears to be a broken citation to Section 3.11.1 (Certificate Provisioning Within the Tunnel). Original: When the server cannot be authenticated, the peer MUST NOT request any services such as certificate provisioning ({#cert- provisioning}) from it. Current: When the server cannot be authenticated, the peer MUST NOT request any services such as certificate provisioning (Section 3.11.1) from it c) {#separation-p1-p2} appears to a broken citation to Section 8.3 (Separation of Phase 1 and Phase 2 Servers). Original: Note that using an MSK of all zeroes opens up TEAP to on-path attacks, as discussed below in {#separation-p1-p2}. Current: Note that using an MSK of all zeroes opens up TEAP to on-path attacks as discussed in Section 8.3. --> 32) <!-- [rfced] Abbreviations a) FYI: Expansions appear for abbreviations upon first use per Section 3.6 of RFC 7322 ("RFC Style Guide") and abbreviations are used after introduction. Please review each expansion in the document carefully to ensure correctness. b) Should instances of "TEAP protocol" and "EAP protocol" be updated to simply read "TEAP" and "EAP" to avoid redundancy (if expanded, "TEAP protocol" would read "Tunnel Extensible Authentication Protocol protocol" and "EAP protocol" would read "Extensible Authentication Protocol"). Please review and let us know if any updates are needed. --> 33) <!-- [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. Updates of this nature typically result in more precise language, which is helpful for readers. For example, please consider if "master" or "deficiency" should be updated. --> 34) <!-- [rfced] Terminology a) Please review the following terms and let us know how we should update for consistency. Compound MAC vs. Compound-MAC vs. compound MAC crypto-binding vs. crypto binding Inner Method vs. inner method b) Per usage in RFC 7170, may we update all instances of "outer TLV" to "Outer TLV" for consistency? --> Thank you. Madison Church and Alanna Paloma RFC Production Center On Feb 4, 2026, at 3:38 PM, [email protected] wrote: *****IMPORTANT***** Updated 2026/02/04 RFC Author(s): -------------- Instructions for Completing AUTH48 Your document has now entered AUTH48. Once it has been reviewed and approved by you and all coauthors, it will be published as an RFC. If an author is no longer available, there are several remedies available as listed in the FAQ (https://www.rfc-editor.org/faq/). You and you coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval. Planning your review --------------------- Please review the following aspects of your document: * RFC Editor questions Please review and resolve any questions raised by the RFC Editor that have been included in the XML file as comments marked as follows: <!-- [rfced] ... --> These questions will also be sent in a subsequent email. * Changes submitted by coauthors Please ensure that you review any changes submitted by your coauthors. We assume that if you do not speak up that you agree to changes submitted by your coauthors. * Content Please review the full content of the document, as this cannot change once the RFC is published. Please pay particular attention to: - IANA considerations updates (if applicable) - contact information - references * Copyright notices and legends Please review the copyright notice and legends as defined in RFC 5378 and the Trust Legal Provisions (TLP – https://trustee.ietf.org/license-info). * Semantic markup Please review the markup in the XML file to ensure that elements of content are correctly tagged. For example, ensure that <sourcecode> and <artwork> are set correctly. See details at <https://authors.ietf.org/rfcxml-vocabulary>. * Formatted output Please review the PDF, HTML, and TXT files to ensure that the formatted output, as generated from the markup in the XML file, is reasonable. Please note that the TXT will have formatting limitations compared to the PDF and HTML. Submitting changes ------------------ To submit changes, please reply to this email using ‘REPLY ALL’ as all the parties CCed on this message need to see your changes. The parties include: * your coauthors * [email protected] (the RPC team) * other document participants, depending on the stream (e.g., IETF Stream participants are your working group chairs, the responsible ADs, and the document shepherd). * [email protected], which is a new archival mailing list to preserve AUTH48 conversations; it is not an active discussion list: * More info: https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc * The archive itself: https://mailarchive.ietf.org/arch/browse/auth48archive/ * Note: If only absolutely necessary, you may temporarily opt out of the archiving of messages (e.g., to discuss a sensitive matter). If needed, please add a note at the top of the message that you have dropped the address. When the discussion is concluded, [email protected] will be re-added to the CC list and its addition will be noted at the top of the message. You may submit your changes in one of two ways: An update to the provided XML file — OR — An explicit list of changes in this format Section # (or indicate Global) OLD: old text NEW: new text You do not need to reply with both an updated XML file and an explicit list of changes, as either form is sufficient. We will ask a stream manager to review and approve any changes that seem beyond editorial in nature, e.g., addition of new text, deletion of text, and technical changes. Information about stream managers can be found in the FAQ. Editorial changes do not require approval from a stream manager. Approving for publication -------------------------- To approve your RFC for publication, please reply to this email stating that you approve this RFC for publication. Please use ‘REPLY ALL’, as all the parties CCed on this message need to see your approval. Files ----- The files are available here: https://www.rfc-editor.org/authors/rfc9930.xml https://www.rfc-editor.org/authors/rfc9930.html https://www.rfc-editor.org/authors/rfc9930.pdf https://www.rfc-editor.org/authors/rfc9930.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9930-diff.html https://www.rfc-editor.org/authors/rfc9930-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9930-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9930 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9930 (draft-ietf-emu-rfc7170bis-22) Title : Tunnel Extensible Authentication Protocol (TEAP) Version 1 Author(s) : A. DeKok WG Chair(s) : Joseph A. Salowey, Peter E. Yee Area Director(s) : Deb Cooley, Paul Wouters -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
