Subject: Re: [kitten] [Ietf-krb-wg] Channel bindings -- interop issue with GSS_C_AF_*

From: Sam Hartman <[email-masked]>
Date: Wed, 08 Jun 2011 12:57:07 -0400

I think RFC 2744 chose the wrong constant for nulladdr; it should have
been 0 not 255.  I think we need to update RFC 2744 and 5554.
I believe that

1) Mechanism implementations should collapse unspecified address with no
actual data and null address together

2) The Kerberos mechanism should do so in a manner compatible with
Microsoft

3) We need to explicitly specify what applications should do here.

If someone argues that we cannot make incompatible changes to 2744, I
respond that compatibility with the implementations we know about is
more important to me than compatibility with the spec and if forced to
choose I will choose the implementations.

---

From: Nico Williams <[email-masked]>
Date: Wed, 8 Jun 2011 12:05:28 -0500

> been 0 not 255.  I think we need to update RFC 2744 and 5554.

I'm agnostic as to that.  I don't mind saying "must use
GSS_C_AF_UNSPEC and null addresses" and leaving RFC2744 alone.

> 2) The Kerberos mechanism should do so in a manner compatible with

Agreed, though (2) subsumes (1).

> choose I will choose the implementations.

+1

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 8 Jun 2011 12:16:30 -0500

Another possibility is that we fix only RFC5554 to say that when null
addresses are provided then the address families must be a specific
one and that mechanisms must coerce those to that one specific family
if the application supplied the wrong one.  We then need only
determine which one Windows is using now.

Nico
--

---

From: Thomas Maslen <[email-masked]>
Date: Wed, 8 Jun 2011 17:38:36 +0000

Nico Williams wrote:
>
> [...] We then need only determine which one Windows is using now.

My understanding -- based both on some Microsoft documentation and on
tweaking our implementation to validate a CB hash generated by a Windows
HTTPS-SPNEGO client -- is that Microsoft does exactly the same thing that
you specified in RFC5801:  set the address-type to zero (and of course the
address-length is also zero).

And I agree with Sam + you:  we shouldn't break Microsoft's implementation,
nor should we break RFC5801.  Instead we should update RFC2744 /
RFC5554 / whatever to use 0, not 255, as the address-type for omitted addresses.

---

From: Nico Williams <[email-masked]>
Date: Wed, 8 Jun 2011 12:44:23 -0500

> address-length is also zero).

Thanks, this is great information.

> RFC5554 / whatever to use 0, not 255, as the address-type for omitted addresses.

RFC5554 is basically an update to RFC2743 adding to the abstract API
what RFC2744 had effectively done.  So I think an update or erratum to
RFC5554 will suffice.  An erratum to RFC2744 would not hurt though.

---

From: Martin Rex <[email-masked]>
Date: Wed, 8 Jun 2011 21:50:46 +0200 (MEST)

> choose I will choose the implementations.

In case I my messages were conceived as ambiguous:

I'm OK with updating the relevant specs to formally allow _and_ document
what the current installed base is doing, for all of the specs that
we know about.

Changing rfc2744 in a backwards incompatible fashion would be a bad idea,
but I don't think that is necessary.  Relaxing rfc-2744 should be
sufficient.

Two things should go into rfc-2744.

- We need to allow taggging an absent address
  (i.e. OctetString of size zero) with GSS_C_AF_UNSPEC(0).
  The current wording of rfc-2744 implies that absent address data
  needs to be tagged with GSS_C_AF_NULLADDR(255).

- We need to document which specs are going to require
  GSS_C_AF_UNSPEC(0) with absent network addresses and
  non-empty application_data channel bindings to match actual
  implementation practice and for interoperability with the
  installed base of that specs.

-Martin