Re: Last Call: 'The Kerberos V5 ("GSSAPI") SASL mechanism' to Proposed Standard (draft-ietf-sasl-gssapi)

[Mark Crispin <[e-mail]>]

On Mon, 28 Aug 2006, Nicolas Williams wrote:
> Since this is all specific to the Kerberos V GSS-API mechanism I think
> the value of this flag is irrelevant, so this change should not render
> any earlier implementations non-compliant in terms of their on-the-wire
> behaviour.

In that case, it's all the more reason to use SHOULD instead of MUST.

> (At least one implementation of the Kerberos V GSS mechanism used to
> leave out confidentiality protection, but none, to my knowledge, fails
> to provide MIC and/or wrap tokens when integ_req_flag == false in the
> call to GSS_Init_sec_context().)

However, a change in the GSSAPI shared library could, without change to 
the client code itself, render a client that fails to set integ_req_flag 
non-compliant over-the-wire.  So we shouldn't count upon this.

I just don't want a path where my old installed base is retroactively 
declared non-compliant, or a trap laid where external events could change 
that base to become non-compliant.  It's an entirely different matter if 
the old code is not "non-compliant" but has (potential) behavior that is 
"deprecated" in favor of the new code which follows the new rule.

> GSS_C_NO_CHANNEL_BINDINGS is only defined in the C bindings of the
> GSS-API (RFC2744), whereas the base GSS-API specification (RFC2743) uses
> "NULL" to mean "no channel bindings" (e.g., "...where NULL channel
> bindings..." and "[w]hen non-NULL channel bindings are provided").

OK, consider that one withdrawn.  Thanks.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

_______________________________________________
Kitten mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/kitten