Re: Suppressing conf/integ flags in krb5 GSS tokens

On Mon, 2015-06-01 at 10:33 -0500, Nico Williams wrote:
> On Mon, Jun 01, 2015 at 09:51:57AM -0400, Simo Sorce wrote:
> > On Sun, 2015-05-31 at 23:03 -0500, Nico Williams wrote:
> > > On Sun, May 31, 2015 at 01:59:24PM -0400, Greg Hudson wrote:
> > > > Comments?
> > > 
> > > Heimdal's SPNEGO implementation neither checks the the GSS_C_INTEG_FLAG
> > > ret_flag, nor requests it as a req_flag.  Heimdal's SPNEGO discovers
> > > integrity support by calling gss_get_mic(): if it returns GSS_S_UNAVAIL,
> > > then integrity support is not provided, otherwise it is.  Heimdal also
> > > assumes that if a MIC is received then integrity support must be
> > > available.
> > > 
> > > I believe calling GSS_GetMIC() and GSS_VerifyMIC() even when
> > > GSS_C_INTEG_FLAG is not set in ret_flags is perfectly permissible in
> > > RFC2743.
> > 
> > I think this is fine, and if you receive a MIC you have no other option
> > (well, except fail).
> > 
> > > Disabling the MIC in SPNEGO when GSS_C_INTEG_FLAG is not set in
> > > ret_flags, combined with the new cred options, is likely (I think) to
> > > fail to interop with Microsoft's SPNEGO when used in the application
> > > protocol in question.  It ought to fail to interop, but who know,
> > > perhaps MSFT's SPNEGO will not require the MIC in this protocol because
> > > it's running over TLS, but I'd not bet on it.  The Heimdal approach
> > > seems better.
> 
> Besides failing to interop, it's not secure.  That TLS might be
> involved is besides the point, since SPNEGO can't know that.

The application is explicitly asking to not do integrity or
confidentiality, of course it may be insecure ...

Simo.

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

_______________________________________________
krbdev mailing list             [email protected]
https://mailman.mit.edu/mailman/listinfo/krbdev