On Feb 4, 2026, at 6:40 PM, [email protected] wrote: > 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 > -->
Yes, this is fine. > 2) <!-- [rfced] Please insert any keywords (beyond those that appear in > the title) for use on https://www.rfc-editor.org/search. --> Nothing to add here. > 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). > --> No changes here. > > 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]. > --> Sure, that's fine. > 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. > --> Yes, that's fine. > 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. > --> Changing to "Extended Key Usage" is OK. > 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. > --> I think just using Section 6 as a reference is better. Section 6.1.2 shows examples, and doesn't define any rules. > > 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. > --> It should be "basic password authentication" as per other uses in the document. > 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. > --> Yes. > 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. > --> Yes. > 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. > --> Yes. > 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). > --> Yes. > 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]. > --> This should be "Extended Key Purpose", which is in 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. > --> Yes. > 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) > --> Yes. > 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 > --> Yes, that's fine. > 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. > --> Both should use "in which kind of packets". > 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. > --> Yes. > 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. > --> Yes. > 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. > --> Yes. > 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. > --> Yes. > 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. > --> The last paragraph is best. > 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]. > --> BCP 26. > 24) <!-- [rfced] Should "EAP method" be plural? > > Current: > Protected inner method negotiation, including EAP method > > Perhaps: > Protected inner method negotiation, including EAP methods > --> Plural is fine. > 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]. > --> BCP 86. > 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. > --> It should point to Section 6 of RFC 3766. > 27) <!-- [rfced] May we move the "Changes from RFC 7170" section to the > Appendix? > --> Yes. > > 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 > --> Yes. > 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. That's fie. > [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. That's fine. > [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). > --> Updating the references is fine. > 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. > --> They have all been addressed. > 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. Those changes are fine. > 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. > --> Yes. Just using "TEAP" and "EAP" is fine. > > 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. --> No changes need to be made here. > 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 They should all be: Compound MAC crypto-binding Inner Method > b) Per usage in RFC 7170, may we update all instances of "outer TLV" to > "Outer TLV" for consistency? > --> Yes. > > 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 > >
signature.asc
Description: Message signed with OpenPGP
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
