CIFS Authentication Protocols Specification Paul J. Leach Microsoft Preliminary Draft - do not cite Author's draft: 4 This is a preliminary draft of a specification of a proposed new version of the CIFS authentication protocol. It is supplied here as a standalone document for ease of review; if accepted and implemented, it may be incorporated into a future release of the CIFS specification. (This specification may change without notice, and should not be construed as a product commitment from Microsoft Corporation.) There are two sections: one about the authentication protocols themselves; and one about how the protocol to use is negotiated and the protocol messages transported in CIFS requests and responses. 1. CIFS Authentication Protocols This section defines the CIFS session and message authentication protocols. Session authentication is done via a challenge response protocol based upon the shared knowledge of the user's password. Message authentication is done by attaching a message authentication code (MAC) to each message. 1.1 Overview There are several variations on one basic session authentication scheme: To gain authenticated access to server resources, the server sends a "challenge" to the client, which the client responds to in a way that proves it knows the client's password: a "response" is created from the challenge by encrypting it (and possibly a nonce of the client's choice) with a 168 bit "session key" computed from the user's password. The response, or a subset of it, and client nonce are then returned to the server, which can validate the response by performing the same computation. The client and server negotiate which variation to use by a mechanism described in the next section (being careful to not permit a downgrade attack). We describe the session authentication protocol as if the CIFS server keeps a client’s password, but an implementation might actually store the passwords on a key distribution server (KDS) and have servers use a protocol outside the scope of this specification to enable them to perform the steps required by this protocol. Once the session is authenticated, subsequent messages may be authenticated by computing a MAC for each message and attaching it to the message. The MAC used is a keyed MD5 construction similar to that used in IPSec [RFC 1828], using a "MAC key" computed from the session key, and the response to the server's challenge. The MAC is over both the message text and an implicit sequence number, to prevent replay. Paul Leach Page 1 03/25/97 Preliminary CIFS AuthenticationMay change without notice 1.2 Definitions Let E(K, D) denote the DES block mode encryption function [FIPS 81] , which accepts a seven byte key (K) and an eight byte data block (D) and produces an eight byte encrypted data block as its value. Ex(K,D) denote the extension of DES to longer keys and data blocks. If the data to be encrypted is longer than eight bytes, the encryption function is applied to each block of eight bytes in sequence and the results are concatenated together. If the key is longer than seven bytes, each 8 byte block of data is first completely encrypted using the first seven bytes of the key, then the second seven bytes, etc., appending the results each time. For example, to encrypt the 16 byte quantity D0D1 with the 14 byte key K0K1, Ex(K0K1,D0D1) = concat(E(K0,D0),E(K0,D1),E(K1,D0),E(K1,D1)) concat(A, B, …, Z) is the result of concatenating the byte strings A, B, … Z head(S, N) denote the first N bytes of the byte string S. swab(S) denote the byte string obtained by reversing the order of the bits in each byte of S, i.e., if S is byte string of length one, with the value 0x37 then swab(S) is 0xEC. zeros(N) denote a byte string of length N whose bytes all have value 0 (zero). ones(N) denote a byte string of length N whose bytes all have value 255. xor(A, B) denote a byte string formed by the bytewise logical "xor" of each of the bytes in A and B. and(A, B) denote a byte string formed by the bytewise logical "and" of each of the bytes in A and B. substr(S, A, B) denote a byte string of length N obtained by taking N bytes of S starting at byte A. The first byte is numbered zero. I.e., if S is the string "NONCE" then substr(S, 0, 2) is "NO". Paul Leach Page 2 03/25/97 Preliminary CIFS AuthenticationMay change without notice 1.3 Session Keys The session authentication protocol is the same for all dialects, but the computation of the session keys is different depending on the dialect and the authentication negotiation described below. 1.3.1 NT Session Key The session key S21 and partial MAC key S16 are computed as S16 = MD4(U(PN)) S21 = concat(S16, zeros(5)) where o PN is a string containing the user’s password in clear text, case sensitive, no maximum length o U(x) of an ASCII string "x" is that string converted to Unicode o MD4(x) of an byte string "x" is the 16 byte MD4 message digest [RFC 1320] of that string 1.3.2 LM Session Key The session key S21 and partial MAC key S16 are computed as S 16X = Ex(swab(P14),N8) S 21 = concat(S16X, zeros(5)) S 16 = concat(head(S16X, 8), zeros(8)) where o P14 is a 14 byte string containing the user’s password in clear text, upper cased, padded with spaces o N8 is an 8 byte string whose value is available from Microsoft upon request. 1.4 Session Authentication Protocol The session authentication protocol has the following steps: o The server chooses a unique 8 byte challenge C8 (a "nonce" that has never been used before and will not be reused) and sends it to the client o The client computes R N = Ex(S21,C8) Paul Leach Page 3 03/25/97 Preliminary CIFS AuthenticationMay change without notice o The client sends the 24 byte response RN to the server o The server computes RN as above and compares the received response with its computed value for RN; if equal, the client has authenticated. 1.6 Message authentication code The MAC is the keyed MD5 construction: M AC(K, text) = head(MD5(concat(K, text)), 8) Where: MD5 is the MD5 hash function; see RFC 1321 K is the key text is the message whose MAC is being computed See RFC 1828 for an example of Keyed-MD5 applied to IP security. If not used properly, keyed MD5 may have weaknesses as a MAC. Iterative hashes such as MD5 may be subject to message extension attacks and to cryptanalysis [Kal 95]. This construction is not subject to the problems identified there, because the text contains an explicit length, which prevents message extension attacks; and because there are always two iterations of the compression function, and only 64 bits of the hash are output, which prevents known cryptanalysis techniques. 1.7 MAC key The MAC key is computed as follows: K = concat(S16, RN) Where S16 and RN are as above. K is either 40 or 44 bytes long, depending on the length of RN. 1.8 Message Authentication Protocol Once the session has been authenticated, each message can be authenticated as well. This will prevent MITM attacks, replay attacks, and active message modification attacks. (See Security Considerations, below.) Let SN Paul Leach Page 4 03/25/97 Preliminary CIFS AuthenticationMay change without notice be a request sequence number, initially set to 0. Both client and server have one SN for each connection between them. RSN is the sequence number expected on the response to a request. req_msg be a request message rsp_msg be a response message The SN is logically contained in each message, as defined below in the section on authenticated message transport, and participates in the computation of the MAC, as defined in that section. Then for or each message sent in the session the following procedure is followed: · Client computes MAC(req_msg) using SN, and sends it to the server in the request message. If there are multiple messages in the request, each uses the same SN. If there are multiple requests in the message (using the "AndX" facility) , then the MAC is calculated as if it were a single large request. · Client increments its SN and saves it as RSN · Client increments its SN - this is the SN it will use in its next request · Server receives each req_msg, validates MAC(req_msg) using SN, and responds ACCESS_DENIED if invalid · Server increments its SN and saves it as RSN · Server increments its SN - this is the SN it will expect in the next request · For each response message for this request, computes MAC(rsp_msg) using RSN, and sends it to client in the response message. If there are multiple responses in the message (using the "AndX" facility) , then the MAC is calculated as if it were a single large response. · Client receives each rsp_msg, validates MAC(rsp_msg) using RSN, and discards the response message if invalid 2. Security Level and Authentication Protocol Negotiation The SMB_COM_NEGPROT response from a server has the following bits in its SecurityMode field: #define NEGOTIATE_SECURITY_USER_LEVEL 0x01 #define NEGOTIATE_SECURITY_CHALLENGE_RESPONSE 0x02 Paul Leach Page 5 03/25/97 Preliminary CIFS AuthenticationMay change without notice #define NEGOTIATE_SECURITY_SIGNATURES_ENABLED 0x04 #define NEGOTIATE_SECURITY_SIGNATURES_REQUIRED 0x08 If NEGOTIATE_SECURITY_USER_LEVEL is set, then "user level" security is in effect for all the shares on the server. This means that the client MUST establish a session (with SMB_COM_SESSION_SETUP_ANX) to authenticate the user before connecting to a share, and the password to use in the authentication protocol described above is the user's password. If NEGOTIATE_SECURITY_USER_LEVEL is clear, then "share level" security is in effect for all the shares in the server. This means that a session need not be established, and the password to use in the authentication protocol is a password for the share. If NEGOTIATE_SECURITY_CHALLENGE_RESPONSE is clear, then the server is requesting plaintext passwords. Clients MUST be able to be configured to refuse requests for plaintext passwords (in order to prevent downgrade attacks by rogue or spoofing servers); this SHOULD be the default. Servers MUST be able to be configured to refuse plaintext passwords (in order to make password guessing attacks harder). If NEGOTIATE_SECURITY_CHALLENGE_RESPONSE is set, then the server supports the challenge/response session authentication protocol described above, and clients SHOULD use it. Servers MAY refuse connections that do not use it, and MUST be able to be configured to do so. If the dialect is earlier than "NTLM 0.12" then the client computes the response using the "LM session key". If the dialect is "NTLM 0.12" then the client MAY compute the response either using the "LM session key", or the "NT session key", or both. The server MAY choose to refuse responses computed using the "LM session key", and MUST be able to be configured to do so (in order to protect against downgrade attacks). If NEGOTIATE_SECURITY_SIGNATURES_ENABLED is set, then the server supports the message authentication protocol described above, and the client MAY use it. This bit may only be set if NEGOTIATE_SECURITY_CHALLENGE_RESPONSE is set. Clients that support security signatures MUST be configurable to refuse to connect to servers that do not have NEGOTIATE_SECURITY_SIGNATURES_ENABLED set. Clients that are so configured MUST refuse to connect to servers that have NEGOTIATE_SECURITY_CHALLENGE_RESPONSE set and do not have NEGOTIATE_SECURITY_USER_LEVEL set (i.e., they must not use challenge/response authentication to a server using "share-level" security). If NEGOTIATE_SECURITY_SIGNATURES_REQUIRED is set, then the server requires the use of the message authentication protocol described above, and the client MUST use it. This bit may only be set if NEGOTIATE_SECURITY_SIGNATURES_ENABLED is set. This bit MUST NOT be set. if NEGOTIATE_SECURITY_USER_LEVEL is clear (i.e., for servers using "share level" security). The SMB_COM_SESSION_SETUP_ANDX request has the following bit in the Flags2 field: Paul Leach Page 6 03/25/97 Preliminary CIFS AuthenticationMay change without notice #define SMB_FLAGS2_SMB_SECURITY_SIGNATURE 0x0004 To use message authentication, the client sets SMB_FLAGS2_SMB_SECURITY_SIGNATURE in a SMB_COM_SESSION_SETUP_ANDX request to the server, and includes a MAC calculated as described above. If the resulting session is non-null and non-guest, then the SMB_COM_SESSION_SETUP_ANDX response and all subsequent SMB requests and responses MUST include a MAC calculated as described above. The first non-null, non-guest session determines the key to be used for the MAC for all subsequent sessions. Message authentication may only be requested when the "NTML 0.12" dialect has been negotiated. If message authentication is used, raw mode MUST not be used (because some raw mode messages have no headers in which to carry the MAC). No matter which authentication protocol is negotiated, servers MUST be able to be configured to "lock out" accounts that make too many failed authentication attempts, in order to foil brute force attacks on the protocol. 2.1 Plaintext password transport If plaintext password authentication was negotiated, clients send the plaintext password in the first SMB_COM_TREE_CONNECT, SMB_COM_TREE_CONNECT_ANDX, and/or SMB_COM_SESSION_SETUP_ANDX request which follows the SMB_COM_NEGPROT message exchange. The SMB field used to contain the response depends upon the request: · Password in SMB_COM_TREE_CONNECT · Password in SMB_COM_TREE_CONNECT_ANDX · AccountPassword in SMB_COM_SESSION_SETUP_ANDX in dialects prior to "NTLM 0.12" · CaseInsensitivePassword in SMB_COM_SESSION_SETUP_ANDX in the "NTLM 0.12" dialect · CaseSensitivePassword in SMB_COM_SESSION_SETUP_ANDX in the "NTLM 0.12" dialect 2.2 Challenge/response transport The challenge C8 from the server to the client is contained in the EncryptionKey field in the SMB_COM_NEGPROT response. (Note: the name "EncryptionKey" is historical -- it doesn't actually hold an encryption key.) Clients send the cleartext password, or the response to the challenge, in the first SMB_COM_TREE_CONNECT, SMB_COM_TREE_CONNECT_ANDX, and/or SMB_COM_SESSION_SETUP_ANDX request which follows the SMB_COM_NEGPROT Paul Leach Page 7 03/25/97 Preliminary CIFS AuthenticationMay change without notice message exchange. The SMB field used to contain the response depends upon the request: · Password in SMB_COM_TREE_CONNECT · Password in SMB_COM_TREE_CONNECT_ANDX · AccountPassword in SMB_COM_SESSION_SETUP_ANDX in dialects prior to "NTLM 0.12" · CaseInsensitivePassword in SMB_COM_SESSION_SETUP_ANDX for a response computed using the "LM session key" in the "NTLM 0.12" dialect · CaseSensitivePassword in SMB_COM_SESSION_SETUP_ANDX for a response computed using the "NT session key" in the "NTLM 0.12" dialect (Note: again, the names are historical, and do not reflect this usage.) 2.3 MAC transport In each message that contains a MAC, the following bit is set in the flags2 field: #define SMB_FLAGS2_SMB_SECURITY_SIGNATURES 0x0004 The SMB header has been modified to include a place for the MAC: typedef struct _SMB_HEADER { UCHAR Protocol[4]; // Contains 0xFF,'SMB' UCHAR Command; // Command code UCHAR ErrorClass; // Error class UCHAR Reserved; // Reserved for future use USHORT Error ; // Error code UCHAR Flags; // Flags USHORT Flags2 ; // More flags union { USHORT Reserved2[6]; // Reserved for future use struct { USHORT PidHigh; // High part of PID // Client must send the correct Signature // for this SMB to be accepted. UCHAR SecuritySignature[8]; }; }; .... } SMB_HEADER; The sender of a message inserts the sequence number SSN into the message by putting it into the first 4 bytes of the SecuritySignature field and zeroing the last 4 bytes, computes the MAC over the entire message, then puts the MAC in the field. The receiver of a message validates the MAC by extracting the value of the SecuritySignature field, putting its ESN Paul Leach Page 8 03/25/97 Preliminary CIFS AuthenticationMay change without notice into the first 4 bytes of the SecuritySignature field and zeroing the last 4 bytes, computing the MAC, and comparing it to the extracted value. Oplock break messages from the server to the client may not use message authentication, even if it has been negotiated. 3. Security considerations (These are already in the main CIFS spec, of which this will eventually become a part.) Relevant additions: Clients that require the use of message authentication will be protected against man-in-the-middle attacks and downgrade attacks by rogue or counterfeit servers. Servers that require the use of message authentication will be protected against man-in-the-middle attacks and downgrade attacks by rogue clients. 4. References [FIPS 81] DES, FIPS PUB xxx [RFC 1320] RFC 1320, R. Rivest, The MD4 Message-Digest Algorithm [RFC 1321] RFC 1321, R. Rivest, The MD5 Message-Digest Algorithm [RFC 1828] RFC 1828, P. Metzger, W. Simpson, "IP Authentication using Keyed MD5", August 1995 {Kal 95] B. Kaliski, M.Robshaw, "Message Authentication with MD5", CryptoBytes, Sping 1995, RSA Inc, (http://www.rsa.com/rsalabs/pubs/cryptobytes/spring95/md5.htm) Paul Leach Page 9 03/25/97