Suppressing conf/integ flags in krb5 GSS tokens

[Simo Sorce]

On Sun, 2015-05-31 at 13:59 -0400, Greg Hudson wrote:
> MIT krb5 needs a way to suppress the confidentiality and integrity flags
> in krb5 GSS context initiator tokens in order to interoperate with some
> Microsoft servers.  The background is here:
> http://krbdev.mit.edu/rt/Ticket/Display.html?id=6938
> 
> My plan had been to implement Heimdal's GSS_KRB5_CRED_NO_CI_FLAGS_X cred
> option, with the same constant name and OID.  This option removes both
> the conf and integ flags from the initiator token (and from ret_flags on
> the initiator and acceptor), but the caller can still request them.
> 
> Unfortunately, those semantics don't play well with our SPNEGO mech,
> which requests integrity from the underlying mechanism.  There would be
> no way to actually suppress the integrity flag when going through
> SPNEGO.  I don't think we want to change that about our SPNEGO mech; the
> current behavior seems to match what RFC 4178 describes.
> 
> Taking that into account, I'm thinking we need to implement two cred
> options to separately suppress the confidentiality and integrity flags,
> even if the caller asks for them.  When used through SPNEGO, suppressing
> the integrity flag would have the effect of disabling the SPNEGO MIC.
> I'm a little concerned about that interaction, because Heimdal doesn't
> seem to check whether the negotiated mech when deciding whether to
> require a MIC.  But in general the other party will be a Microsoft
> server (or maybe Samba) when these flags are used.
> 
> Comments?

Integrity and Confidentiality flags are usually suppressed only when the
SASL exchange is being performed within a TLS channel as apparently
Windows Servers are wired to refuse service if "double encryption" is
requested. So integrity in this situation is not hugely important.
Our tests show that the GSS_KRB5_CRED_NO_CI_FLAGS_X works as expected
and establishing a context seem to work without issues.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York