fix: properly map SSPI flags to Kerberos GSSAPI flags

[irvingoujAtDevolution]

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.

This change is critical for LDAPs, as Active Directory does not accept Kerberos with sign and seal flags.

This implementation requires reviewers attention, in particular, at line 408 of src/kerberos/client/generators.rs. Where windows never specified how these flags map to the GSS checksum flags. This is purely guessed from their Kerberos documentation at section 3.2.5.2. and the SSPI documentation .

Whether this implementation is correct or not, we need a way for caller to change that flag.

[awakecoding]

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

[CBenoit]

Thank you for that! I left a few comments for improvements, but I didn’t spot any significant issue just by looking at the code in isolation. Let’s test this more thoroughly (via FreeRDP, IronRDP, etc) once merged.
Feel free to address the comments (or not), and merge yourself.

PS: I’ll rename the PR title to better reflect the changes, and keep consistency with other commits (although casing for commit type is not imposed by conventional commit specification).

[irvingoujAtDevolution]

@awakecoding , one thing to notice is that, this flag should also has an effect when encrypt/decrypt payloads. For example, if sign is on and seal is off, the message should comes with a signature but with unencrypted payload. I'll open a issue to track it

[irvingoujAtDevolution]

For future reference.

here is a screenshot that it works no sign, no seal, plain TCP connection

here is another that works with no sign, no seal, tls connection but decrypted using @awakecoding TLS decryption script

[TheBestTvarynka]

LGTM 👍

[jborean93]

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.

[pauldumais]

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.

LDAPS does not allow sealing since the connection is already encrypted.

[jborean93]

Only when using GSS-SPNEGO because it uses the negotiated context flags to determine if signing/sealing was applied by the auth context. The GSSAPI SASL is fine with this as it negotiates the signing/sealed after the auth with another round trip of tokens. My comment was around not always having integrity and confidentiality by default and opting out of it with the NO_INTEGRITY flag. I.e. both SSPI and GSSAPI always negotiate integrity and confidentiality with Kerberos unless the relevant NO_INTEGIRTY flag is specified.

[pauldumais]

Yes agreed we will make sure to fix this.

[irvingoujAtDevolution]

@jborean93 added new issue #198 according to the thread.