8 Jun 2011 21:50
Re: [Ietf-krb-wg] Channel bindings -- interop issue with GSS_C_AF_*
Martin Rex <mrex <at> sap.com>
2011-06-08 19:50:46 GMT
2011-06-08 19:50:46 GMT
Sam Hartman wrote: > > 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. 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
RSS Feed