Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Improve Kerberos SSPI and GSSAPI Related Issues #198

Open
irvingoujAtDevolution opened this issue Dec 20, 2023 · 1 comment
Open

Improve Kerberos SSPI and GSSAPI Related Issues #198

irvingoujAtDevolution opened this issue Dec 20, 2023 · 1 comment

Comments

@irvingoujAtDevolution
Copy link
Contributor 

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

Originally posted by @jborean93 in #189 (comment)

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.
Merged
@irvingoujAtDevolution
Copy link
Contributor Author

update:
Integrity is actually implied, but confidentiality is not

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@irvingoujAtDevolution