[DNSOP] Re: [dnsext] [Technical Errata Reported] RFC 3645 (8773)
"Eric Vyncke \(evyncke\)" <[email protected]> Thu, 26 Mar 2026 10:02:15 +0000
| Newsgroups | gmane.ietf.dnsop,gmane.ietf.dnsext |
|---|---|
| Message-ID | <PH0PR11MB496624C99CCDA5EC8D275CBFA956A@PH0PR11MB4966.namprd11.prod.outlook.com> |
--===============9172511590006177450== Content-Language: en-GB Content-Type: multipart/alternative; boundary="_000_PH0PR11MB496624C99CCDA5EC8D275CBFA956APH0PR11MB4966namp_" --_000_PH0PR11MB496624C99CCDA5EC8D275CBFA956APH0PR11MB4966namp_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable [Adding dnsop WG in the loop] From: Olafur Gudmundsson <[email protected]> Date: Wednesday, 25 March 2026 at 14:40 To: RFC Errata System <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <prae= [email protected]>, [email protected] <[email protected]>, levone@mi= crosoft.com <[email protected]>, [email protected] <randyhall@lucent.= com>, [email protected] <[email protected]>, [email protected] <ek.ie= [email protected]>, Eric Vyncke (evyncke) <[email protected]>, Andrew Sullivan <= [email protected]>, Ond=F8ej Sur=FD <[email protected]>, [email protected] = <[email protected]> Subject: Re: [dnsext] [Technical Errata Reported] RFC3645 (8773) This is a blast from the past. After re-reading RFC3645 a few times, I think this errata is valid My question to those who understand GSS-API better is if a warning should b= e added to section 4.x? as well but that may be an overkill. Other than the typo fix below I think it should be accepted. Olafur (DNSEXT chair when this RFC as worked on) > On Feb 20, 2026, at 04:30, RFC Errata System <[email protected]> = wrote: > > The following errata report has been submitted for RFC3645, > "Generic Security Service Algorithm for Secret Key Transaction Authentica= tion for DNS (GSS-TSIG)". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid8773 > > -------------------------------------- > Type: Technical > Reported by: Ond=F8ej Sur=FD <[email protected]> > > Section: 7 > > Original Text > ------------- > This document describes a protocol for DNS security using GSS-API. > The security provided by this protocol is only as effective as the > security provided by the underlying GSS mechanisms. > > All the security considerations from RFC 2845, RFC 2930 and RFC 2743 > apply to the protocol described in this document. > > Corrected Text > -------------- > This document describes a protocol for DNS security using GSS-API. > The security provided by this protocol is only as effective as the > security provided by the underlying GSS mechanisms. > > All the security considerations from RFC 2845, RFC 2930 and RFC 2743 > apply to the protocol described in this document. > > The mechanism in Section 4.1.1 effectively allows pre-authentication > oracle. This allow a pre-authentication information disclosure in s/allow/allows/ > GSS-API TKEY negotiation. An unauthenticated attacker can determine > which GSSAPI session keynames are currently active in the server's > dynamic keyring by observing differential error codes in TKEY responses= . > > Notes > ----- > The other angle would be to change the section 4.1.1 to disallow reportin= g the BADNAME error and handle everything uniformly. > > Instructions: > ------------- > This erratum is currently posted as "Reported". (If it is spam, it > will be removed shortly by the RFC Production Center.) Please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > will log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC3645 (draft-ietf-dnsext-gss-tsig-06) > -------------------------------------- > Title : Generic Security Service Algorithm for Secret Key T= ransaction Authentication for DNS (GSS-TSIG) > Publication Date : October 2003 > Author(s) : S. Kwan, P. Garg, J. Gilroy, L. Esibov, J. Westhead= , R. Hall > Category : PROPOSED STANDARD > Source : DNS Extensions > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > dnsext mailing list -- [email protected] > To unsubscribe send an email to [email protected] --_000_PH0PR11MB496624C99CCDA5EC8D275CBFA956APH0PR11MB4966namp_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 2"> </head> <body> <div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, sans-se= rif; font-size: 12pt; color: rgb(0, 0, 0);"> [Adding dnsop WG in the loop]</div> <div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, sans-se= rif; font-size: 12pt; color: rgb(0, 0, 0);"> <br> </div> <div id=3D"mail-editor-reference-message-container"> <div class=3D"ms-outlook-mobile-reference-message skipProofing"> <meta name=3D"Generator" content=3D"Microsoft Exchange Server"> </div> <div class=3D"ms-outlook-mobile-reference-message skipProofing" style=3D"te= xt-align: left; padding: 3pt 0in 0in; border-width: 1pt medium medium; bord= er-style: solid none none; border-color: rgb(181, 196, 223) currentcolor cu= rrentcolor; font-family: Aptos; font-size: 12pt; color: black;"> <b>From: </b>Olafur Gudmundsson <[email protected]><br> <b>Date: </b>Wednesday, 25 March 2026 at 14:40<br> <b>To: </b>RFC Errata System <[email protected]><br> <b>Cc: </b>[email protected] <[email protected]>, praeritg@micros= oft.com <[email protected]>, [email protected] <jamesg@mic= rosoft.com>, [email protected] <[email protected]>, randyhal= [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>,= Eric Vyncke (evyncke) <[email protected]>, Andrew Sullivan <ajs@a= nvilwalrusden.com>, Ond=F8ej Sur=FD <[email protected]>, dnsext@ietf.= org <[email protected]><br> <b>Subject: </b>Re: [dnsext] [Technical Errata Reported] RFC3645 (8773)<br> <br> </div> <div class=3D"PlainText" style=3D"font-size: 11pt;"><br> This is a blast from the past.<br> <br> After re-reading RFC3645 a few times, I think this errata is valid<br> My question to those who understand GSS-API better is if a warning should b= e added to section 4.x? as well but that may be an overkill.<br> <br> Other than the typo fix below I think it should be accepted.<br> <br> Olafur (DNSEXT chair when this RFC as worked on) <br> <br> <br> > On Feb 20, 2026, at 04:30, RFC Errata System <rfc-editor@rfc-editor= .org> wrote:<br> ><br> > The following errata report has been submitted for RFC3645,<br> > "Generic Security Service Algorithm for Secret Key Transaction Au= thentication for DNS (GSS-TSIG)".<br> ><br> > --------------------------------------<br> > You may review the report below and at:<br> > <a href=3D"https://www.rfc-editor.org/errata/eid8773" data-outlook-id= =3D"1b23855d-5c4e-44ec-a1da-990f942e117d"> https://www.rfc-editor.org/errata/eid8773</a><br> ><br> > --------------------------------------<br> > Type: Technical<br> > Reported by: Ond=F8ej Sur=FD <[email protected]><br> ><br> > Section: 7<br> ><br> > Original Text<br> > -------------<br> > This document describes a protocol for DNS security using = GSS-API.<br> > The security provided by this protocol is only as effectiv= e as the<br> > security provided by the underlying GSS mechanisms.<br> ><br> > All the security considerations from RFC 2845, RFC 2930 an= d RFC 2743<br> > apply to the protocol described in this document.<br> ><br> > Corrected Text<br> > --------------<br> > This document describes a protocol for DNS security using = GSS-API.<br> > The security provided by this protocol is only as effectiv= e as the<br> > security provided by the underlying GSS mechanisms.<br> ><br> > All the security considerations from RFC 2845, RFC 2930 an= d RFC 2743<br> > apply to the protocol described in this document.<br> ><br> > The mechanism in Section 4.1.1 effectively allows pre-auth= entication<br> > oracle. This allow a pre-authentication information = disclosure in<br> s/allow/allows/<br> > GSS-API TKEY negotiation. An unauthenticated attacke= r can determine<br> > which GSSAPI session keynames are currently active in the = server's<br> > dynamic keyring by observing differential error codes in T= KEY responses.<br> ><br> > Notes<br> > -----<br> > The other angle would be to change the section 4.1.1 to disallow repor= ting the BADNAME error and handle everything uniformly.<br> ><br> > Instructions:<br> > -------------<br> > This erratum is currently posted as "Reported". (If it is sp= am, it<br> > will be removed shortly by the RFC Production Center.) Please<br> > use "Reply All" to discuss whether it should be verified or<= br> > rejected. When a decision is reached, the verifying party <br> > will log in to change the status and edit the report, if necessary.<br= > ><br> > --------------------------------------<br> > RFC3645 (draft-ietf-dnsext-gss-tsig-06)<br> > --------------------------------------<br> > Title  = ; : Generic Security Service Algorithm for Secret Key Tra= nsaction Authentication for DNS (GSS-TSIG)<br> > Publication Date : October 2003<br> > Author(s) = : S. Kwan, P. Garg, J. Gilroy, L. Esibov, J. Westhead, R. Hall<br> > Category &n= bsp; : PROPOSED STANDARD<br> > Source &nbs= p; : DNS Extensions<br> > Stream &nbs= p; : IETF<br> > Verifying Party : IESG<br> ><br> > _______________________________________________<br> > dnsext mailing list -- [email protected]<br> > To unsubscribe send an email to [email protected]<br> <br> </div> </div> </body> </html> --_000_PH0PR11MB496624C99CCDA5EC8D275CBFA956APH0PR11MB4966namp_-- --===============9172511590006177450== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRE5TT1AgbWFp bGluZyBsaXN0IC0tIGRuc29wQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg dG8gZG5zb3AtbGVhdmVAaWV0Zi5vcmcK --===============9172511590006177450==--