Re: [kitten] Fwd: [Technical Errata Reported] RFC5801 (2825)

Dusting off this pesky little issue (AF_UNSPEC vs AF_NULLADDR in channel-binding hash calculations)...

I don't want to waylay "Kerberos Version 5 GSS-API Channel Binding Hash Agility" on its way to PS (and of course I should have noticed this earlier), but:

Section 3.2 of draft-ietf-krb-wg-gss-cb-hash-agility-10.txt just says

      data-value

         The output obtained by applying the Kerberos V get_mic
         operation [RFC3961] with key usage number 43, to the channel
         binding data as described in [RFC4121], section 4.1.1.2

and RFC 4121 refers to RFC 2744, which still specifies 255 (AF_NULLADDR) for addressless channel bindings.

Since  "Kerberos Version 5 GSS-API Channel Binding Hash Agility" is all about generating (more secure) interoperable channel-binding hashes, and it is expected that addressless channel bindings will be the norm, would it behoove us to say "disregard the bit where RFC 2744 says to use 255;  real programmers use zero (AF_UNSPEC)"?

[draft-ietf-krb-wg-gss-cb-hash-agility is krb-wg, but rightly or wrongly I'm posting this to kitten].

----------------------------------------------------------------------

Message: 1
Date: Mon, 14 Nov 2011 17:12:31 +0100 (MET)
From: Martin Rex <mrex@sap.com>
To: stephen.farrell@cs.tcd.ie (Stephen Farrell)
Cc: kitten@ietf.org, simon@josefsson.org
Subject: Re: [kitten] Fwd: [Technical Errata Reported] RFC5801 (2825)
Message-ID: <201111141612.pAEGCVL0007860@fs4113.wdf.sap.corp>
Content-Type: text/plain; charset=ISO-8859-1

Stephen Farrell wrote:
>
> Not being on the top of anyone's list, this doesn't
> seem to have progressed since June.
>
> Can we resolve this on the list or at this week's
> meeting?

I think we stopped here:
http://www.ietf.org/mail-archive/web/kitten/current/msg02688.html

While GSS_C_AF_NULLADDR(255) would be undoubtedly the correct tag with
respect to the original GSS-API spec, we seem to have an installed
base which didn't follow the spec.

-Martin

> On 06/08/2011 11:02 AM, Stephen Farrell wrote:
> >
> >
> > On 08/06/11 09:02, Simon Josefsson wrote:
> >> Stephen Farrell<stephen.farrell@cs.tcd.ie>  writes:
> >>
> >>> Hi all,
> >>>
> >>> Can you confirm that this is correct, or not?
> >>
> >> I think we could use some more discussion before approving this -- for
> >> example, what impact does this have on existing implementations?
> >
> > Good point. I'm fine with waiting for the WG to give me the
> > answer that I'll cut'n'paste into the errata tool:-) Sooner
> > is of course better for that.
> >
> > Thanks,
> > S.
> >
> >>
> >> I will try to change my implementation to use 255 instead of 0 and see
> >> if it still works and inteoperates with my old version.  It would be
> >> useful if others could do similar experiments.  I don't expect serious
> >> problems, but I think we should consider the impact before approving
> >> this.
> >>
> >> I do agree it is a bug in the specification though.
> >>
> >> /Simon
> >>
> >>> Thanks,
> >>> S.
> >>>
> >>> -------- Original Message --------
> >>> Subject: [Technical Errata Reported] RFC5801 (2825)
> >>> Date: Tue,  7 Jun 2011 20:58:20 -0700 (PDT)
> >>> From: RFC Errata System<rfc-editor@rfc-editor.org>
> >>> To: simon@josefsson.org, Nicolas.Williams@oracle.com,
> >>> stephen.farrell@cs.tcd.ie, turners@ieca.com, tlyu@mit.edu,
> >>> kurt.zeilenga@isode.com
> >>> CC: thomas.maslen@quest.com, rfc-editor@rfc-editor.org
> >>>
> >>>
> >>> The following errata report has been submitted for RFC5801,
> >>> "Using Generic Security Service Application Program Interface (GSS-API)
> >>> Mechanisms in Simple Authentication and Security Layer (SASL): The GS2
> >>> Mechanism Family".
> >>>
> >>> --------------------------------------
> >>> You may review the report below and at:
> >>> http://www.rfc-editor.org/errata_search.php?rfc=5801&eid=2825
> >>>
> >>> --------------------------------------
> >>> Type: Technical
> >>> Reported by: Thomas Maslen<thomas.maslen@quest.com>
> >>>
> >>> Section: 5.1
> >>>
> >>> Original Text
> >>> -------------
> >>> The initiator-address-type and acceptor-address-type fields of the
> >>> GSS-CHANNEL-BINDINGS structure MUST be set to 0.
> >>>
> >>>
> >>> Corrected Text
> >>> --------------
> >>> The initiator-address-type and acceptor-address-type fields of the
> >>> GSS-CHANNEL-BINDINGS structure MUST be set to 255 (GSS_C_AF_NULLADDR).
> >>>
> >>>
> >>> Notes
> >>> -----
> >>> See RFC 2744, section 3.11, last paragraph:  "[...] or omit addressing
> >>> information, specifying GSS_C_AF_NULLADDR as the address-types".
> >>>
> >>> Appendix A of RFC 2744 specifies that the value of GSS_C_AF_NULLADDR is 255.
> >>>
> >>> Instructions:
> >>> -------------
> >>> This errata is currently posted as "Reported". If necessary, please
> >>> use "Reply All" to discuss whether it should be verified or
> >>> rejected. When a decision is reached, the verifying party (IESG)
> >>> can log in to change the status and edit the report, if necessary.
> >>>
> >>> --------------------------------------
> >>> RFC5801 (draft-ietf-sasl-gs2-20)
> >>> --------------------------------------
> >>> Title               : Using Generic Security Service Application Program
> >>> Interface (GSS-API) Mechanisms in Simple Authentication and Security
> >>> Layer (SASL): The GS2 Mechanism Family
> >>> Publication Date    : July 2010
> >>> Author(s)           : S. Josefsson, N. Williams
> >>> Category            : PROPOSED STANDARD
> >>> Source              : Simple Authentication and Security Layer
> >>> Area                : Security
> >>> Stream              : IETF
> >>> Verifying Party     : IESG
> >>
> > _______________________________________________
> > Kitten mailing list
> > Kitten@ietf.org
> > https://www.ietf.org/mailman/listinfo/kitten
> >
> _______________________________________________
> Kitten mailing list
> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten
>