> Note: This change might be breaking. Confidentiality and integrity is not implied anymore. User needs to actively specify these two flag to get sign and seal.
Don't you always want confidentiality and integrity by default, you should only not be setting it if the NO_INTEGRITY flag is specified.
It looks good to me, I'm surprised it has worked so far. We'll need to test that it doesn't break things for other protocols though
AFAIK LDAP (when using LDAPS or LDAP + StartTLS) is the only one that has needed this and specifically with the GSS-SPNEGO SASL. I've not encountered any other protocols so far that requires explicitly disabling integrity/confidentiality with the auth.
integrity should be implied while confidentiality is a choice (i.e when use without TLS). Also, these two flags should be effective while encrypt/decrypt the messages.
Don't you always want confidentiality and integrity by default, you should only not be setting it if the NO_INTEGRITY flag is specified.
AFAIK LDAP (when using LDAPS or LDAP + StartTLS) is the only one that has needed this and specifically with the
GSS-SPNEGO
SASL. I've not encountered any other protocols so far that requires explicitly disabling integrity/confidentiality with the auth.Originally posted by @jborean93 in https://github.com/Devolutions/sspi-rs/issues/189#issuecomment-1864992527
integrity should be implied while confidentiality is a choice (i.e when use without TLS). Also, these two flags should be effective while encrypt/decrypt the messages.