Hi Amanda, The updates look good. Thank you!
Madison Church RFC Production Center > On Feb 19, 2026, at 7:56 PM, Amanda Baber via RT <[email protected]> wrote: > > Hi, > > We've added the following entries to "TEAP Error TLV (value 5) Error Codes": > > 2003 The Crypto-Binding TLV is invalid (Version, or Received-Ver, or > Sub-Type) [RFC-ietf-emu-rfc7170bis-19] > 2004 The first Inner Method did not derive EMSK [RFC-ietf-emu-rfc7170bis-19] > 2005 The Crypto-Binding TLV did not include a required MSK Compound MAC > [RFC-ietf-emu-rfc7170bis-19] > 2006 The MSK Compound MAC fails verification [RFC-ietf-emu-rfc7170bis-19] > 2007 The Crypto-Binding TLV did not include a required EMSK Compound MAC > [RFC-ietf-emu-rfc7170bis-19] > 2008 The EMSK Compound MAC fails verification [RFC-ietf-emu-rfc7170bis-19] > 2009 The EMSK Compound MAC exists, but the Inner Method did not derive EMSK > [RFC-ietf-emu-rfc7170bis-19] > > Please see > https://www.iana.org/assignments/teap-parameters > > thanks, > Amanda > > On Thu Feb 19 22:10:24 2026, [email protected] wrote: >> IANA, >> >> To match the updated document, please add values 2003-2009 from Table >> 4 (Section 7.2) to the "TEAP Error TLV (value 5) Error Codes” >> registry. See https://www.rfc-editor.org/authors/rfc9930-IANA.txt. >> >> Thank you! >> >> Madison Church >> RFC Production Center >> >>> On Feb 19, 2026, at 3:07 PM, Madison Church <[email protected] >>> editor.org> wrote: >>> >>> Hi Alan, >>> >>> Thanks for your reply! We believe the reply you provided is your >>> approval of the document, and we have noted such on the AUTH48 status >>> page (see https://www.rfc-editor.org/auth48/rfc9930). If that is not >>> correct and you need more time for review, please let us know. >>> >>> In the meantime, we will proceed with IANA updates. >>> >>> Thank you! >>> >>> Madison Church >>> RFC Production Center >>> >>>> On Feb 19, 2026, at 9:57 AM, Alan DeKok <[email protected]> >>>> wrote: >>>> >>>> Those changes are fine, thanks. >>>> >>>>> On Feb 19, 2026, at 10:42 AM, Madison Church <[email protected] >>>>> editor.org> wrote: >>>>> >>>>> Hi Alan, >>>>> >>>>> Thank you for your quick reply! We have left the citations below as >>>>> is per your feedback. Two followup items are listed below. Aside >>>>> from these two items, we have no further comments or questions and >>>>> will wait for your approval before asking IANA to update their >>>>> registries. >>>>> >>>>> 1) For question 2c, we have left the citation tag as is. Please let >>>>> us know if this is correct. >>>>> >>>>> Original: >>>>> The challengePassword field is limited to 255 octets (Section 7.4.9 >>>>> of [RFC5246] indicates that no existing cipher suite would result >>>>> in an issue with this limitation). >>>>> >>>>> 2) The only notable citation update we have made in AUTH48 is shown >>>>> below. Please let us know if this is correct. >>>>> >>>>> Original: >>>>> The other TLS keying materials are derived and used as defined in >>>>> [RFC5246]. >>>>> >>>>> Current: >>>>> The other TLS keying materials are derived and used as defined in >>>>> [RFC8446]. >>>>> >>>>> The updated files have been posted here (please refresh): >>>>> https://www.rfc-editor.org/authors/rfc9930.txt >>>>> https://www.rfc-editor.org/authors/rfc9930.pdf >>>>> https://www.rfc-editor.org/authors/rfc9930.html >>>>> https://www.rfc-editor.org/authors/rfc9930.xml >>>>> https://www.rfc-editor.org/authors/rfc9930-diff.html >>>>> https://www.rfc-editor.org/authors/rfc9930-rfcdiff.html (side by >>>>> side) >>>>> https://www.rfc-editor.org/authors/rfc9930-auth48diff.html >>>>> https://www.rfc-editor.org/authors/rfc9930-auth48rfcdiff.html (side >>>>> by side) >>>>> https://www.rfc-editor.org/authors/rfc9930-lastdiff.html >>>>> https://www.rfc-editor.org/authors/rfc9930-lastrfcdiff.html (side >>>>> by side) >>>>> >>>>> AUTH48 status page: https://www.rfc-editor.org/auth48/rfc9930 >>>>> >>>>> Thank you! >>>>> Madison Church >>>>> RFC Production Center >>>>> >>>>>> On Feb 18, 2026, at 10:35 AM, Alan DeKok <[email protected]> >>>>>> wrote: >>>>>> >>>>>> On Feb 18, 2026, at 10:56 AM, Madison Church <[email protected] >>>>>> editor.org> wrote: >>>>>>>> 1) For #23 and #25, we have updated the corresponding text in >>>>>>>> the file when updating the BCP citations. Please review and let >>>>>>>> us know if the text appears as desired. >>>>>> >>>>>> The text is fine >>>>>> >>>>>>>> 2) Upon further review, we came across a few instances of text >>>>>>>> where we are unsure if updating to use RFC 8446 is correct. >>>>>>>> Please review each instance below and let us know how we should >>>>>>>> update. Note that we will continue to cite RFC 5246 where there >>>>>>>> is a direct mention of TLS 1.2. >>>>>>>> >>>>>>>> a) Original: >>>>>>>> TEAP is in full conformance with TLS ticket extension [RFC5077]. >>>>>>>> >>>>>>>> Separately, we note that this is the only mention of the term >>>>>>>> "TLS ticket extension", whereas "SessionTicket extension" is >>>>>>>> used multiple times in this document. Should the term be updated >>>>>>>> as follows? >>>>>>>> >>>>>>>> Perhaps: >>>>>>>> TEAP is in full conformance with the SessionTicket extension >>>>>>>> [RFC5077]. >>>>>> >>>>>> Yes. >>>>>> >>>>>>>> >>>>>>>> b) Original: >>>>>>>> It is REQUIRED that anonymous cipher suites such as >>>>>>>> TLS_DH_anon_WITH_AES_128_CBC_SHA [RFC5246] only be used in the >>>>>>>> case when the inner method provides mutual authentication, key >>>>>>>> generation, and resistance to on-path and dictionary attacks. >>>>>>>> >>>>>>>> (Note that TLS_DH_anon_WITH_AES_128_CBC_SHA does not appear in >>>>>>>> RFC 8446.) >>>>>> >>>>>> I think it's fine to leave that as a reference to RFC5246. >>>>>> >>>>>>>> c) The challengePassword field is limited to 255 octets (Section >>>>>>>> 7.4.9 of [RFC5246] indicates that no existing cipher suite would >>>>>>>> result in an issue with this limitation). >>>>>>>> >>>>>>>> >>>>>>>> d) The TLS-PRF is defined in [RFC5246] as: >>>>>>>> PRF(secret, label, seed) = P_<hash>(secret, label | seed) >>>>>>>> >>>>>>>> (Note that this definition does not appear in RFC 8446.) >>>>>> >>>>>> Leaving that as RFC5246 is OK. >>>>>> >>>>>>>> >>>>>>>> e) Original: >>>>>>>> The derivation of S-IMCK is as follows: >>>>>>>> >>>>>>>> S-IMCK[0] = session_key_seed >>>>>>>> For j = 1 to n-1 do >>>>>>>> IMCK[j] = the first 60 octets of TLS-PRF(S-IMCK[j-1], >>>>>>>> "Inner Methods Compound Keys", >>>>>>>> IMSK[j]) >>>>>>>> S-IMCK[j] = first 40 octets of IMCK[j] >>>>>>>> CMK[j] = last 20 octets of IMCK[j] >>>>>>>> >>>>>>>> where TLS-PRF is the PRF (described above) negotiated as part of >>>>>>>> TLS >>>>>>>> handshake [RFC5246]. >>>>>> >>>>>> Leaving that as RFC5246 is OK. >>>>>> >>>>>>>> >>>>>>>> f) For instance, the Certificate Status Request extension >>>>>>>> [RFC6066] and the >>>>>>>> Multiple Certificate Status Request extension [RFC6961] can be >>>>>>>> used >>>>>>>> to leverage a certificate-status protocol… >>>>>>>> >>>>>>>> (Note: No mention of Multiple Certificate Status Request >>>>>>>> extension in RFC 8446.) >>>>>> >>>>>> I think that text is fine as-is/ >>>>>> >>>>>>>> The files have been posted here (please refresh): >>>>>>>> https://www.rfc-editor.org/authors/rfc9930.txt >>>>>>>> https://www.rfc-editor.org/authors/rfc9930.pdf >>>>>>>> https://www.rfc-editor.org/authors/rfc9930.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9930.xml >>>>>>>> >>>>>>>> Diff files: >>>>>>>> https://www.rfc-editor.org/authors/rfc9930-diff.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9930-rfcdiff.html (side by >>>>>>>> side) >>>>>>>> https://www.rfc-editor.org/authors/rfc9930-auth48diff.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9930-auth48rfcdiff.html >>>>>>>> (side by side) >>>>>>>> https://www.rfc-editor.org/authors/rfc9930-alt-diff.html (shows >>>>>>>> moved text) >>>>>>>> >>>>>>>> AUTH48 status page: https://www.rfc-editor.org/auth48/rfc9930 >>>>>>>> >>>>>>>> Thank you! >>>>>>>> Madison Church >>>>>> >>>>> >>>> >>> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
