Re: AD Review for draft-ietf-sasl-gssapi-xx.txt

[Sam Hartman <hartmans-ietf@xxxxxxx>]

So, this is a bit complicated and perhaps the best thing is to decide
that we just don't care about mechansims without integ_avail.

RFC 4422 only requires us to integrity protect the security layer
exchange if the underlying mechanism has integrity protection.  It is
quite clear that we cannot do channel binding exchange without
integrity protection.

I'm assuming that gssapi mechanisms protect their negotiation enough
that if integrity is requested that the mechanism prevents downgrade
attacks and either gives you integrity or only fails to give you
integrity if one end doesn't support it or required credentials are
missing.  If you are concerned that is not actually required by 2743
I'd be happy to see if we can get kitten to specify that.

I don't think it makes any sense at all to return prot_ready without
integrity being available so aborting if somehow you get prot_ready
but later not integ_avail seems fine.  (Alternatively we could require
that integ_avail is set at the same time as prot_ready)

The only important thing seems to be not to negotiate a security layer
or pass channel bindings if integ_avail is not set.