[19190] in Kerberos_V5_Development
Re: Suppressing conf/integ flags in krb5 GSS tokens
daemon@ATHENA.MIT.EDU (Benjamin Kaduk)
Mon Jun 1 13:04:33 2015
Date: Mon, 1 Jun 2015 13:04:22 -0400 (EDT)
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: heimdal-discuss@sics.se, Nico Williams <nico@cryptonector.com>
In-Reply-To: <20150601040317.GA600@localhost>
Message-ID: <alpine.GSO.1.10.1506011257160.22210@multics.mit.edu>
MIME-Version: 1.0
Cc: krbdev@MIT.EDU
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@MIT.EDU
On Mon, 1 Jun 2015, 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.
It's not clear how generic that assumption is, because...
> 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.
That seems correct. Section 1.2.2:
GSS-API callers desiring per-message security services should check
the values of these flags at context establishment time, and must be
aware that a returned FALSE value for integ_avail means that
invocation of GSS_GetMIC() or GSS_Wrap() primitives on the associated
context will apply no cryptographic protection to user data messages.
Note that this seems to imply that you can generate a MIC which provides
no integrity benefit, calling the above assumption into question.
-Ben
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
