1

I've been doing some research on LDAP supportedSASLMechanisms and am trying to assert whether or not there is confidentiality protection in play when using GSS-SPNEGO.

My initial assessment is that additional configuration is required to achieve confidentiality because the following C# code (assume GSS-SPNEGO is selected) only shows SASL GSS-API Integrity in Wireshark, but no SASL GSS-API Privacy.

private static void Main()
{
  using (var ds = new DirectorySearcher())
  {
    ds.Filter = string.Format("(&(objectClass=user)(sAMAccountName={0}))", "jdoe");
    var result = ds.FindOne(); // Begin packet capture
    ...
  }
}

The following is a sample of packet captures:

client -> server: searchRequest(73) "<ROOT>" baseObject 
server <- client: searchResEntry(73) "<ROOT>" 
client -> server: bindRequest(75) "<ROOT>" sasl (SASL mechanism: GSS-SPNEGO)
server <- client: bindResponse(75) success 
client -> server: SASL GSS-API Integrity: searchRequest(9) "DC=com,DC=example" baseObject 

As you can start to see, the entire transaction (beginning with the outgoing searchRequest query and all subsequent transactions) are sent/received clear text. I do see in the SASL Buffer krb5_blob under the GSS-API section, albeit just above the GSS-API Payload section which also is clear text.

I guess my main questions are:

  1. Would a MITM still be able to see the same traffic I'm seeing in clear text and if so, what exactly is Kerberos' role with respect to confidentiality in these transactions (if any)?
  2. What would be the most preferred route for ensuring encrypted traffic (i.e. EXTERNAL, or SSL/TLS; this part I'm actually still researching implementation details for, specifically in C#, as in AuthenticationTypes.SecureSocketsLayer)?

Note: I have not checked "attempt to decrypt KRB5 traffic" nor specified a keytab file in Wireshark, so my initial impression is that the role of Kerberos is for signing/verification purposes only and as mentioned earlier, additional configuration (or coding) would be required to ensure traffic is encrypted.

Matt Borja
  • 267
  • 1
  • 10

1 Answers1

1

So the short answer is no, this is not negotiating SASL GSS-API Privacy and quite frankly I haven't explored this route any further (with exception to playing with LdapConnection).

The following psuedo-code establishes a TLS connection with the LDAP server, however (port number and bind credentials required):

var bindPath = "LDAP://dc.example.com:636";

...

if (!ValidUsername(samAccountName))
    throw new Exception("Invalid samAccountName");

using (var context = new DirectoryEntry(bindPath, bindUsername, bindPassword, AuthenticationTypes.SecureSocketsLayer))
using (var ds = new DirectorySearcher())
{
    ds.SearchRoot = context;
    ds.Filter = string.Format("(&(objectClass=user)(sAMAccountName={0}))", samAccountName);

    var sr = ds.FindOne();

    if (sr == null)
        throw new Exception("User [" + samAccountName + "] not found");

    return sr.GetDirectoryEntry();
}

For completeness, the following psuedo-code is also included for validating the samAccountName being queried:

public static bool ValidUsername(string username)
{
    // Must not be empty/null
    if (string.IsNullOrEmpty(username))
        return false;

    // Must not exceed max length expected
    if (username.Length > ValidUsernameMaxLength)
        return false;

    // Must only contain valid characters in whitelist
    if (!ValidUsernamePattern.IsMatch(username))
        return false;

    return true;
}

Props to Wireshark :)

Matt Borja
  • 267
  • 1
  • 10