[cifs-protocol] 115070812924583 No mention of deviation from MS-KILE regarding non-gssapi or absent checksums in AP-REQ

[Sreekanth Nadendla]

Hello Andrew,
I've verified this and we are adding the following text In MS-KILE section "3.4.5 Message Processing Events and Sequencing Rules", to explain the deviation you have reported.

When the checksum field is not present, the application server SHOULD process the requests as though none of the flags (RFC 4121 section 4.1.1.1) are set and SHOULD NOT check channel binding information (RFC 4121 section 4.1.2.1).


Regards,
Sreekanth Nadendla
Microsoft Windows Open Specifications

-----Original Message-----
From: Andrew Bartlett [mailto:abartlet at samba.org] 
Sent: Wednesday, July 8, 2015 5:10 PM
To: Interoperability Documentation Help
Cc: cifs-protocol at lists.samba.org
Subject: No mention of deviation from MS-KILE regarding non-gssapi or absent checksums in AP-REQ

RFC 4121 4.1.1 says that the checksum MUST be provided in the AP-REQ packet from the client to the application server in the initial GSSAPI exchange (eg, the input to accept_sec_context). 

"The authenticator in the KRB_AP_REQ message MUST include the optional  sequence number and the checksum field.  The checksum field is used  to convey service flags, channel bindings, and optional delegation  information."

In order for Samba to interoperate with a "Huawei Unified Storage System
S5500 V3" we found that we not only had to allow a krb5 checksum (that Samba erroneously produced for many years), but also no checksum entirely.

Tests (patches to Samba's own fake gssapi implementation) show that Windows also accepts this.

This deviation from RFC4121 isn't documented in MS-KILE.  Can you please explain what is going on here?

As context, allowing no checksum caused a DoS in MIT krb5 due to a NULL pointer de-reference in http://web.mit.edu/kerberos/advisories/MITKRB5-SA-2010-005.txt 

I don't see this as a security issue, as despite the name the checksum is being re-used simply as an opaque data field, in an authenticated packet. 

Thanks,

Andrew Bartlett
-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba