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

Tue Apr 5 01:52:30 UTC 2016

Thanks Obaid,
crystal clear!

Simo.

On Tue, 2016-04-05 at 00:19 +0000, Obaid Farooqi wrote:
> 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/_NTAuthen
> tication.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. 
> 
> 
> _______________________________________________
> cifs-protocol mailing list
> cifs-protocol at lists.samba.org
> https://lists.samba.org/mailman/listinfo/cifs-protocol