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