[19186] in Kerberos_V5_Development
Re: Suppressing conf/integ flags in krb5 GSS tokens
daemon@ATHENA.MIT.EDU (Simo Sorce)
Mon Jun 1 09:52:11 2015
Message-ID: <1433166717.19096.250.camel@willson.usersys.redhat.com>
From: Simo Sorce <simo@redhat.com>
To: Nico Williams <nico@cryptonector.com>
Date: Mon, 01 Jun 2015 09:51:57 -0400
In-Reply-To: <20150601040317.GA600@localhost>
Mime-Version: 1.0
Cc: heimdal-discuss@sics.se, krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
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.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
