[cifs-protocol] [REG:116031113818575] GSSAPI context establishment Confidentiality/Integrity protection levels

[Obaid Farooqi]

Hi Simo:
My investigation reveal that the issue you are encountering is not in the GSS API implementation of Microsoft (SSPI). It is due to a wrong assumption in the implementation of NNS protocol. As a matter of fact, the code is public so you can see for yourself at the following link:
http://referencesource.microsoft.com/#System/net/System/Net/_NTAuthentication.cs,f5122807ad1e911b

In method Decrypt, the following check is made

if (IsConfidentialityFlag)
            {
                errorCode = SSPIWrapper.DecryptMessage(GlobalSSPI.SSPIAuth, m_SecurityContext, securityBuffer, expectedSeqNumber);
            }
            else
            {
                errorCode = SSPIWrapper.VerifySignature(GlobalSSPI.SSPIAuth, m_SecurityContext, securityBuffer, expectedSeqNumber);
            }

And on the same link, IsConfidentialityFlag is defined as:

internal bool IsConfidentialityFlag {
            get {
                return (m_ContextFlags & ContextFlags.Confidentiality) != 0;
            }

And m_ContextFlags is returned from the calls to IntializeSecurityContext and AcceptSecurityContext.

So, it is the NNS protocol that requires that if the conf_avail flag is set, it means that every message must be encrypted (and signed). I have filed a bug against the document to make it explicit. 

The document MS-NNS already alludes to that in section " 2.2.2	Data Message ":

".... Thus, if the negotiated security context in the handshake phase results in a context that does not support message confidentiality or integrity, then the data transferred is not framed, and does not follow the format specified in this section (that is, application-supplied data is written directly to the underlying TCP stream)."

I agree that it is not crisp and rigorous. But it makes it clear that if signing and sealing is not required, the protocol would not even do the framing i.e. might as well just use TCP without this protocol.

To do the signing only, the above code suggest that you just need to clear the confidentiality flag and signing will be assumed.

Please let me know if it does not answer your question.




Regards,
Obaid Farooqi
Escalation Engineer | Microsoft

Exceeding your expectations is my highest priority.  If you would like to provide feedback on your case you may contact my manager at nkang at Microsoft dot com

-----Original Message-----
From: "Obaid Farooqi" <obaidf at microsoft.com> 
Sent: Friday, March 11, 2016 11:50 AM
To: "Simo" <simo at samba.org>
Cc: "cifs-protocol" <cifs-protocol at samba.org>; "MSSolve Case Email" <casemail at microsoft.com>
Subject: [REG:116031113818575] GSSAPI context establishment Confidentiality/Integrity protection levels

Hi Simo: 
Thanks for contacting Microsoft. I have created a case to track this issue. I'll help you with this issue and will be in touch as soon as I have an answer.

Regards,
Obaid Farooqi
Escalation Engineer | Microsoft 

Exceeding your expectations is my highest priority.  If you would like to provide feedback on your case you may contact my manager at nkang at Microsoft dot com


-----Original Message-----
From: idra at samba.org [mailto:idra at samba.org] On Behalf Of Simo
Sent: Friday, March 11, 2016 11:30 AM
To: Interoperability Documentation Help <dochelp at microsoft.com>
Cc: cifs-protocol <cifs-protocol at samba.org>
Subject: GSSAPI context establishment Confidentiality/Integrity protection levels 

Dear dochelp,
I am look at an interoperability issue between MIT client and Windows Servers when it comes to GSSAPi/SSPI based/using protocols.

[cifs-protocol in CC because it may affect that crowd too] 

At least for some protocols it appears as Microsoft Servers assume that the flags negotiated during context establishment directly indicate what is the minimum protection level that the server should expect.

To be more concrete, it appears that if a client negotiates the GSS_C_CONF_FLAG then the server seem to expect that the client will always use confidentiality protected packets and not allow integrity protected only packets, by returning an error if such a packet is sent by the client.

We've seen this behavior in 2 distinct cases, one less clear with SASL, where the negotiated flags are also used in lieu of the normal SASL SSF negotiation.

The other protocol where we encountered this is MS-NNS, the document seem to implicitly indicate that by calling the flags by the name "negotiated protection level".

Now the rub of the problem here is that RFC 2743 seem to take a completely different stance on the meaning of the negotiate flags.

In "RFC 2743 1.2.2 Per-Message Security Service Availability" the document describe the returned flags with the name conf_avail and integ_avail and the document is quite clear that their meaning is just that the confidentiality and integrity service are available. That is a missinf conf_avail flag would mean the confidentiality services are not available but its presence doesn't mean confidentiality is required.

For this reason the MIT GSSAPI krb5 mechanism, always forcibly sets the GSS_C_CONF_FLAG and the GSS_S_INTEG_FLAG in the context request, to indicate that the client does support both.

However it appears that by doing so we have an interpo issue where MIT GSSAPI clients are unable to negotiate a context where confidentiality can be used but is only optional.

We've been able to interoperate in the relevant cases by adding a way to turn off the forceful setting of those flags during client context establishment.

Now the question is whether Windows SSPI services always unconditionally treat the negotiated flags as the required negotiated protection level for a GSSAPI negotiated context or if this enforcement is instead a matter of the specific protocol/application using SSPI/GSSAPI on a Windows Server.

The documentation I was able to find so far is not very clear on this issue and it would be nice to have it documented in MS-KILE if Windows Kerberos mechanisms enforce different rules on confidentiality/integrity context establishment than what is indicated in RFC 2743.

Thanks,
Simo.