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 ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Simo Sorce]

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

[Nico Williams]

Post by Greg Hudson
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

[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

[Simo Sorce]

Post by Nico Williams

Post by Greg Hudson
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).

Post by Nico Williams
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]

Post by Simo Sorce

Post by Nico Williams

Post by Greg Hudson
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).

Post by Nico Williams
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.

[Nico Williams]

Post by Simo Sorce

Post by Nico Williams

Post by Greg Hudson
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).

Post by Nico Williams
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

[Simo Sorce]

Post by Nico Williams

Post by Simo Sorce

Post by Nico Williams

Post by Greg Hudson
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).

Post by Nico Williams
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.

[Benjamin Kaduk]

Post by Nico Williams

Post by Greg Hudson
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...

Post by Nico Williams
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 ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Nico Williams]

Post by Benjamin Kaduk
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