Re: Suppressing conf/integ flags in krb5 GSS tokens

Simo Sorce <[email protected]>
Newsgroups gmane.comp.encryption.kerberos.devel,gmane.comp.encryption.kerberos.heimdal.general
Organization Red Hat, Inc.
Message-ID <[email protected]>
On Mon, 2015-06-01 at 09:51 -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.
> 
> Keep in mind we tested this, with the patch we sent Greg.
> It works with all flags turned off and no special handling for MIC,
> today.

I take this back, thinking again, the code where we exercised this uses
its own SPNEGO layer :/

Simo.

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

_______________________________________________
krbdev mailing list             [email protected]
https://mailman.mit.edu/mailman/listinfo/krbdev
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.