home *** CD-ROM | disk | FTP | other *** search
/ ftp.microsoft.com / 2002-07-02_ftp.microsoft.com.zip / developr / drg / CIFS / CIFS-Auth.txt < prev    next >
Text File  |  1997-03-28  |  11KB  |  310 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.                       CIFS Authentication Protocol
  9.  
  10.                              Paul J. Leach
  11.  
  12.                                Microsoft
  13.  
  14.                     Preliminary Draft - do not cite
  15.  
  16.                            Author's draft: 4
  17.  
  18. This is a preliminary draft of a portion of specification of a proposed
  19. new version of the CIFS authentication protocol. It is supplied here as
  20. a standalone document for ease of review; if accepted and implemented,
  21. it may be incorporated into a future release of the CIFS specification.
  22. (This specification is subject to change without notice and should not
  23. be construed as a product commitment from Microsoft Corporation.)
  24.  
  25. The original protocol from which this version descends was designed more
  26. than a decade ago; recently, quite a few weaknesses have been found in
  27. previous versions. This latest revision is an attempt to repair those
  28. weaknesses with as small a change to the protocol as possible, so that
  29. it can be incrementally and rapidly deployed. In particular, it must not
  30. be necessary for all users to change their passwords to deploy the
  31. upgraded protocol, or to deploy new key server software. Also,
  32. efficiency is an issue, so some more robust MAC schemes that could have
  33. been used weren't.
  34.  
  35. This portion of the specification describes the authentication protocol
  36. abstracted from the implementation details, in order to make scrutiny of
  37. its security properties easier. It also only describes the strongest of
  38. several variants of the authentication protocol; a brief summary of the
  39. other variants is at the end of the document, together with a
  40. description of how the real protocols vary from this abstraction. The
  41. full details of the protocol are in the companion CIFS Authentication
  42. Protocols Specification document; a broader discussion of the security
  43. properties, including other attacks, may be found in the CIFS Security
  44. Considerations document.
  45.  
  46.  
  47. 1.1 Overview
  48.  
  49. Session authentication is done via a challenge response protocol based
  50. upon the shared knowledge of the user's password. Message authentication
  51. is done by attaching a message authentication code (MAC) to each
  52. message.
  53.  
  54. The response is computed by DES encrypting a challenge (a nonce)
  55. selected by the server with three keys derived from the user's password.
  56.  
  57. The MAC is a keyed-MD5 construction (see [RFC 1828]), using a key
  58. derived from the user's password and the client and server nonces. Each
  59. message is either of known fixed length or contains an explicit length,
  60. and is longer than an MD5 block, which avoids the known weaknesses of
  61. MD5 as a MAC (see [Kal 95]).  Each message includes an implicit sequence
  62. number, to avoid replay.
  63.  
  64.  
  65.  
  66. Paul J. Leach, Microsoft  [Page 1]                  03/28/97
  67.  
  68.  
  69. Preliminary     CIFS Authentication ProtocolMay change without notice
  70.  
  71.  
  72. We describe the authentication protocols as if the CIFS server
  73. communicates over some secure (private, authenticated) channel to a key
  74. server (KS) which keeps a database of hashes of clients' passwords, but
  75. a server might actually store the hashed passwords itself and be its own
  76. KS. Also, either type of server could store the passwords instead of a
  77. hash of the passwords. We consider these topics to be outside the scope
  78. of this protocol. One of the design goals for this version of the
  79. protocol was to leave the server to key server protocol and the hashed
  80. password format unchanged from the previous version.
  81.  
  82.  
  83. 1.2 Definitions
  84.  
  85. Let
  86.  
  87. U         be the user's name, blank padded to 16 bytes
  88. P(U)      be U's password
  89. Ks, Ks'   be a 128 bit session key
  90. Ka, Ka'   be a 56 bit DES key extracted from the first seven bytes of Ks
  91. Kb, Kb'   be another 56 bit DES key extracted from the second seven
  92.           bytes of Ks
  93. Kc, Kc'   be another 56 bit DES key extracted from the last two bytes of
  94.           Ks, padded with zeros
  95. SN, SN'   be a 32 bit sequence number
  96. Km, Km'   be a 40 byte key for a keyed-MD5 MAC
  97. [s]<n:m>  be the "n" bytes of s starting at byte "m" (the first byte is
  98.           numbered 0).
  99. [s]<n>    be the first "n" bytes of s
  100. a,b,àz    be the concatenation of the byte strings a, b, à z
  101. { m }K    be the DES encryption [FIPS] of the byte string m with key K
  102. MD4(m)    be the MD4 message digest [RFC 1320] of the byte string m
  103. MD5(m)    be the MD5 message digest [RFC 1321] of the byte string m
  104. Z(n)      be a byte string of zeros of length n
  105.  
  106. CS        be an 8 byte nonce chosen by the server, used as a challenge
  107.  
  108.  
  109. 1.3 Application protocol messages
  110.  
  111. The application protocol being secured is a request/response protocol
  112. that has the following characteristics. Authentication is carried out in
  113. the process of setting up a session, during which session features are
  114. negotiated, the exact details of which do not affect the authentication
  115. protocol. Each of the elements of protocol messages is either a fixed
  116. length byte string, or contains an explicit length, and is at least 32
  117. bytes long;, and requests are guaranteed to be distinguishable from
  118. responses.
  119.  
  120. Mneg      be a session negotiation request containing supported features
  121. Mnegr     be a negotiation response indicating selected features
  122. Msess     be a  session request
  123. Msessr    be a session response
  124. Mreq      be a subsequent protocol request
  125. Mrsp      be a subsequent protocol response
  126.  
  127. Paul J. Leach, Microsoft  [Page 2]                  03/28/97
  128.  
  129.  
  130. Preliminary     CIFS Authentication ProtocolMay change without notice
  131.  
  132.  
  133.  
  134.  
  135. 1.4 Session authentication protocol
  136.  
  137. 1. The client computes the session keys from the user's password,
  138. initializes its sequence number, and sends a session negotiation request
  139. to the server.
  140.  
  141. C:        Ks  = MD4(P(U))
  142.           Ka = [Ks]<7>
  143.           Kb = [Ks]<7:7>
  144.           Kc = [Ks]<2:14>, Z(5)
  145.  
  146. C->S:     Mneg
  147.  
  148. 2. The server responds with the features negotiated, and a challenge:
  149.  
  150. S->C:     Mnegr, CS
  151.  
  152. 3. The client computes a response to the challenge. It computes the MAC
  153. key, and the MAC of the message, and  send the user name, challenge
  154. response, and session request parameters to the server.  Its message
  155. uses a sequence number of 0, and it expects a sequence number of 1 to be
  156. used in the response.
  157.  
  158. C:        R = {CS}Ka, {CS}Kb, {CS}Kc
  159.           Km = Ks, R
  160.           SN = 0
  161.           MC = [MD5(Km, SN, Msess, U, R)]<8>
  162.           SN = 1
  163.  
  164. C->S:     Msess, U, R, MC
  165.  
  166. 4. The server send the user's name, the challenge, and the response to a
  167. key server (KS) over a secure (private, authenticated) channel.
  168.  
  169. S->KS:    U, CS, R
  170.  
  171. 5. The key server looks up the session key by looking up the user's name
  172. in a database containing the MD4 hash of users' passwords, and from the
  173. key and the client's challenge, computes the expected response. If the
  174. expected response matches the actual response (R == R'), then it sends
  175. Ks' to the server, otherwise it tells the server to deny access.
  176.  
  177. KS:       Ks'  = MD4(P(U))
  178.           Ka' = [Ks']<7>
  179.           Kb' = [Ks']<7:7>
  180.           Kc' = [Ks']<2:14>, Z(5)
  181.           R'  = {CS}Ka', {CS}Kb', {CS}Kc'
  182.  
  183. KS->S:    Ks'
  184.  
  185. 6. The server computes the MAC key, and the MAC for the request. If MC'
  186. == MC, then the client has authenticated to the server. The server
  187.  
  188. Paul J. Leach, Microsoft  [Page 3]                  03/28/97
  189.  
  190.  
  191. Preliminary     CIFS Authentication ProtocolMay change without notice
  192.  
  193.  
  194. computes the MAC of its response, then sends the session acknowledgment
  195. message, then sets its sequence number to 2, the expected value in the
  196. next request.
  197.  
  198. S:        Km' = Ks', R
  199.           MC' = [MD5(Km, SN', Msess, U, R)]<8>
  200.           MS  = [MD5(Km', SN', Msessr)]<8>
  201.  
  202. S->C:     Msessr, MS
  203.  
  204. S:        SN' = 2
  205.  
  206. 7. The client checks if MS' == MS; if so,  then the server has
  207. authenticated to the client, and the client's sequence number is set to
  208. the value to be used in the next request.
  209.  
  210. C:        MS' = [MD5(Km, SN, Msessr)]<8>
  211.           SN  = 2
  212.  
  213.  
  214. 1.5 Message authentication protocol
  215.  
  216. For each request/response interaction thereafter the following procedure
  217. is used:
  218.  
  219. 1. The client send the request together with a MAC of the request
  220. computed using the current sequence number, then bumps its sequence
  221. number to the one expected in the response:
  222.  
  223. C->S:     Mreq, [MD5(Km, SN, Mreq)]<8>
  224. C:        SN = SN + 1
  225.  
  226. 2. The server checks the MAC, and if correct, sends the response with a
  227. sequence number one higher, then bumps its sequence number by 2 to the
  228. expected value in the next request:
  229.  
  230. S->C:     Mrsp, [MD5(Km', SN'+1, Mrsp)]<8>
  231.  
  232. S:        SN' = SN' + 2
  233.  
  234. 3. The client checks the MAC and if correct accepts the response and
  235. bumps its sequence number:
  236.  
  237. C:        SN  = SN  + 1
  238.  
  239.  
  240. 1.6 Summary of other variants and differences
  241.  
  242. There are variants of the authentication protocols; they exist for
  243. backwards compatibility. The variants are creating by taking certain
  244. allowed combinations of the following differences:
  245.  
  246. ╖ The session key Ks is computed differently.
  247.  
  248.  
  249. Paul J. Leach, Microsoft  [Page 4]                  03/28/97
  250.  
  251.  
  252. Preliminary     CIFS Authentication ProtocolMay change without notice
  253.  
  254.  
  255. ╖ The message authentication protocol is omitted.
  256.  
  257. ╖ A plaintext password may be sent
  258.  
  259. The feature negotiation step (the exchange of Mneg and Mnegr above)  is
  260. where the exact variant is selected. Both client and server can force
  261. the use of as strong a variant as they require to meet their security
  262. policy.
  263.  
  264. The actual authentication protocols differ from the one described in the
  265. following ways:
  266.  
  267. ╖ The order of fields in messages may be different
  268.  
  269. ╖ The MAC value is calculated by inserting the implicit sequence number
  270.   into a field of the message, and computing the MAC; then that field
  271.   is overwritten with the MAC value for transmission.
  272.  
  273. ╖ Multiple requests or responses may be "batched"  together into one
  274.   message; single requests or responses may be spread out over multiple
  275.   messages; and some requests have no response.
  276.  
  277. It is not believed that any of these differences affect the security of
  278. the protocol. The full details of the protocol are in the CIFS
  279. Authentication Specification document; a broader discussion of the
  280. security properties, including other attacks, may be found in the CIFS
  281. Security Considerations document.
  282.  
  283.  
  284. 1.7 References
  285.  
  286. [FIPS] DES, FIPS PUB 46-1, 1988.
  287.  
  288. [RFC 1320] RFC 1320, R. Rivest, The MD4 Message-Digest Algorithm
  289.  
  290. [RFC 1321] RFC 1321, R. Rivest, The MD5 Message-Digest Algorithm
  291.  
  292. [RFC 1828] RFC 1828, P. Metzger, W. Simpson, "IP Authentication using
  293. Keyed MD5", August 1995
  294.  
  295. [Kal 95] B. Kaliski, M.Robshaw,  "Message Authentication with MD5",
  296. CryptoBytes, Sping 1995, RSA Inc,
  297. (http://www.rsa.com/rsalabs/pubs/cryptobytes/spring95/md5.htm)
  298.  
  299.  
  300.  
  301.  
  302.  
  303.  
  304.  
  305.  
  306.  
  307.  
  308.  
  309.  
  310. Paul J. Leach, Microsoft  [Page 5]                  03/28/97