Hi Alan, Now that IANA updates have been completed, we will move this document forward in the publication process.
Thank you! Madison Church RFC Production Center > On Feb 24, 2026, at 1:56 PM, Madison Church <[email protected]> > wrote: > > 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]
