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]
