Suppressing conf/integ flags in krb5 GSS tokens

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Suppressing conf/integ flags in krb5 GSS tokens

Greg Hudson
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?
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Suppressing conf/integ flags in krb5 GSS tokens

Simo Sorce-3
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

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Suppressing conf/integ flags in krb5 GSS tokens

Nico Williams
In reply to this post by Greg Hudson
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.

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.

Nico
--
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Suppressing conf/integ flags in krb5 GSS tokens

Nico Williams

Greg objects to SPNEGO not requesting GSS_C_INTEG_FLAG, and I tend to
agree (since it's possible to design a mechanism that uses -say- bearer
tokens for authentication but does no key exchange unless requested).

To make that work we'd have to change GSS_KRB5_CRED_NO_CI_FLAGS_X to
unset the CI flags rather than not set them by default.

Nico
--
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Suppressing conf/integ flags in krb5 GSS tokens

Simo Sorce-3
In reply to this post by Nico Williams
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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Suppressing conf/integ flags in krb5 GSS tokens

Simo Sorce-3
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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Suppressing conf/integ flags in krb5 GSS tokens

Nico Williams
In reply to this post by Simo Sorce-3
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.

Nico
--
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Suppressing conf/integ flags in krb5 GSS tokens

Simo Sorce-3
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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Suppressing conf/integ flags in krb5 GSS tokens

Benjamin Kaduk-2
In reply to this post by Nico Williams
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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Suppressing conf/integ flags in krb5 GSS tokens

Nico Williams
On Mon, Jun 01, 2015 at 01:04:22PM -0400, Benjamin Kaduk wrote:

> 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.

Ugh.  That's like the GSS_Add_cred() text: broken and unmatched by
reality.

As to MIT Kerberos, you *of course* know what *it* does.

Nico
--
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev