Is GSS_C_INTEG_FLAG required for calling gss_wrap/unwrap
According to RFC 2274, GSS_C_INTEG_FLAG:
True - Integrity service may be invoked by calling either gss_get_mic
or gss_wrap routines.
But per my testing even with GSS_KRB5_CRED_NO_CI_FLAGS_X and not
asking for GSS_C_INTEG_FLAG (integ/conf are false in ap-req), both
parties are able to call gss_wrap/unwrap (windows server), is that
Re: Is GSS_C_INTEG_FLAG required for calling gss_wrap/unwrap
On Fri, Jun 26, 2020 at 1:57 PM Isaac Boukris <[hidden email]> wrote:
> According to RFC 2274, GSS_C_INTEG_FLAG:
> True - Integrity service may be invoked by calling either gss_get_mic
> or gss_wrap routines.
> But per my testing even with GSS_KRB5_CRED_NO_CI_FLAGS_X and not
> asking for GSS_C_INTEG_FLAG (integ/conf are false in ap-req), both
> parties are able to call gss_wrap/unwrap (windows server), is that
For more context, and to correct some of what I said in the
channel-bindings discussion; I was trying to test if an intercepted
token from a clear-text ldap connection could be used over TLS, and it
looks like it could not, if the client requested the integ flag.
As I see it, with GSS-SPNEGO sasl mech the security layers are derived
from the GSS flags so when the integ flag is set in the ap-request the
bind is not accepted when over TLS (so that is why we need
On the other hand with the GSSAPI sasl mech (rfc4752), the integ flag
is always requested in the GSS level (so Windows allows ap-req with
integ flag over TLS), and the sasl security layers (even 0) are
negotiated after the GSS context is established, by exchanging more
sasl tokens protected by gss_wrap/unwrap.
krbdev mailing list [hidden email] https://mailman.mit.edu/mailman/listinfo/krbdev