rfc2433.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,124 行 · 第 1/3 页

         output by the NewPasswordEncryptedWithOldLmPasswordHash()
         routine described in section A.15, below.  Note, however, that
         the use of this field has been deprecated: peers SHOULD NOT
         generate it, and this field SHOULD be zero-filled.

      Old LM Hash Encrypted With New NT Hash
         This field contains the old LAN Manager password hash encrypted
         with the new Windows NT password hash, as output by the
         OldLmPasswordHashEncryptedWithNewNtPasswordHash() routine (see
         section A.16, below).  Note, however, that the use of this
         field has been deprecated: peers SHOULD NOT generate it, and
         this field SHOULD be zero-filled.






Zorn & Cobb                  Informational                      [Page 7]

RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998


      LAN Manager compatible challenge response
      Windows NT compatible challenge response
         The challenge response field (as described in the Response
         packet description), but calculated on the new password and the
         same challenge used in the last response.  Note that use of the
         LAN Manager compatible challenge response has been deprecated;
         peers SHOULD NOT generate it, and the field SHOULD be zero-
         filled.

      Flags
         This field is two octets in length.  It is a bit field of
         option flags where 0 is the least significant bit of the 16-bit
         quantity.  The format of this field is illustrated in the
         following diagram:

                   1
         5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                           | |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Bit 0
               The "use Windows NT compatible challenge response" flag
               as described in the Response packet.

            Bit 1
               Set (1) indicates that the "Password Encrypted with Old
               LM Hash" and "Old LM Hash Encrypted With New NT Hash"
               fields are valid and should be used.  Clear (0) indicates
               these fields are not valid.  This bit SHOULD always be
               clear (0).

            Bits 2-15
               Reserved, always clear (0).

11.  Security Considerations

   As an implementation detail, the authenticator SHOULD limit the
   number of password retries allowed to make brute-force password
   guessing attacks more difficult.

   Because the challenge value is encrypted using the password hash to
   form the response and the challenge is transmitted in clear-text
   form, both passive known-plaintext and active chosen-plaintext
   attacks against the password hash are possible.  Suitable precautions
   (i.e., frequent password changes) SHOULD be taken in environments
   where eavesdropping is likely.




Zorn & Cobb                  Informational                      [Page 8]

RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998


   The Change Password (version 1) packet is vulnerable to a passive
   eavesdropping attack which can easily reveal the new password hash.
   For this reason, it MUST NOT be sent if eavesdropping is possible.

12.  References

   [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
       1661, July 1994.

   [2] Simpson, W., "PPP Challenge Handshake Authentication Protocol
       (CHAP)", RFC 1994, August 1996.

   [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997.

   [4] "Data Encryption Standard (DES)", Federal Information Processing
       Standard Publication 46-2, National Institute of Standards and
       Technology, December 1993.

   [5] Rivest, R., "MD4 Message Digest Algorithm", RFC 1320, April 1992.

   [6] RC4 is a proprietary encryption algorithm available under license
       from RSA Data Security Inc.  For licensing information, contact:
       RSA Data Security, Inc.
       100 Marine Parkway
       Redwood City, CA 94065-1031

   [7] Eastlake, D., Crocker, S., and J. Schiller, "Randomness
       Recomnendations for Security", RFC 1750, December 1994.

   [8] "The Unicode Standard, Version 2.0", The Unicode Consortium,
       Addison-Wesley, 1996. ISBN 0-201-48345-9.

   [9] "DES Modes of Operation", Federal Information Processing
       Standards Publication 81, National Institute of Standards and
       Technology, December 1980

13.  Acknowledgements

   Thanks (in no particular order) to Jeff Haag ([e-mail]),
   Bill Palter ([e-mail]), Bruce Johnson
   ([e-mail]), Tony Bell ([e-mail]), Benoit
   Martin ([e-mail]), and Joe Davies ([e-mail])
   for useful suggestions and feedback.







Zorn & Cobb                  Informational                      [Page 9]

RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998


14.  Chair's Address

   The PPP Extensions Working Group can be contacted via the current
   chair:

   Karl Fox
   Ascend Communications
   3518 Riverside Drive
   Suite 101
   Columbus, OH 43221

   Phone: [phone]
   EMail: [e-mail]

15.  Authors' Addresses

   Questions about this memo can also be directed to:

   Glen Zorn
   Microsoft Corporation
   One Microsoft Way
   Redmond, Washington 98052

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]


   Steve Cobb
   Microsoft Corporation
   One Microsoft Way
   Redmond, Washington 98052

   EMail: [e-mail]

















Zorn & Cobb                  Informational                     [Page 10]

RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998


Appendix A - Pseudocode

   The routines mentioned in the text are described in pseudocode below.

A.1 LmChallengeResponse()

   LmChallengeResponse(
   IN  8-octet          Challenge,
   IN  0-to-14-oem-char Password,
   OUT 24-octet         Response )
   {
      LmPasswordHash( Password, giving PasswordHash )
      ChallengeResponse( Challenge, PasswordHash, giving Response )
   }


A.2 LmPasswordHash()

   LmPasswordHash(
   IN  0-to-14-oem-char Password,
   OUT 16-octet         PasswordHash )
   {
      Set UcasePassword to the uppercased Password
      Zero pad UcasePassword to 14 characters

      DesHash( 1st 7-octets of UcasePassword,
               giving 1st 8-octets of PasswordHash )

      DesHash( 2nd 7-octets of UcasePassword,
               giving 2nd 8-octets of PasswordHash )
   }


A.3 DesHash()

   DesHash(
   IN  7-octet Clear,
   OUT 8-octet Cypher )
   {
      /*
       * Make Cypher an irreversibly encrypted form of Clear by
       * encrypting known text using Clear as the secret key.
       * The known text consists of the string
       *
       *              KGS!@#$%
       */

      Set StdText to "KGS!@#$%"



Zorn & Cobb                  Informational                     [Page 11]

RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998


      DesEncrypt( StdText, Clear, giving Cypher )
   }


A.4 DesEncrypt()

   DesEncrypt(
   IN  8-octet Clear,
   IN  7-octet Key,
   OUT 8-octet Cypher )
   {
      /*
       * Use the DES encryption algorithm [4] in ECB mode [9]
       * to encrypt Clear into Cypher such that Cypher can
       * only be decrypted back to Clear by providing Key.
       * Note that the DES algorithm takes as input a 64-bit
       * stream where the 8th, 16th, 24th, etc.  bits are
       * parity bits ignored by the encrypting algorithm.
       * Unless you write your own DES to accept 56-bit input
       * without parity, you will need to insert the parity bits
       * yourself.
       */
   }


A.5 NtChallengeResponse()

   NtChallengeResponse(
   IN  8-octet               Challenge,
   IN  0-to-256-unicode-char Password,
   OUT 24-octet              Response )
   {
      NtPasswordHash( Password, giving PasswordHash )
      ChallengeResponse( Challenge, PasswordHash, giving Response )
   }


A.6 NtPasswordHash()

   NtPasswordHash(
   IN  0-to-256-unicode-char Password,
   OUT 16-octet              PasswordHash )
   {
      /*
       * Use the MD4 algorithm [5] to irreversibly hash Password
       * into PasswordHash.  Only the password is hashed without
       * including any terminating 0.
       */



Zorn & Cobb                  Informational                     [Page 12]

RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998


   }


A.7 ChallengeResponse()

   ChallengeResponse(
   IN  8-octet  Challenge,
   IN  16-octet PasswordHash,
   OUT 24-octet Response )
   {
      Set ZPasswordHash to PasswordHash zero-padded to 21 octets

      DesEncrypt( Challenge,
                  1st 7-octets of ZPasswordHash,
                  giving 1st 8-octets of Response )

      DesEncrypt( Challenge,
                  2nd 7-octets of ZPasswordHash,
                  giving 2nd 8-octets of Response )

      DesEncrypt( Challenge,
                  3rd 7-octets of ZPasswordHash,
                  giving 3rd 8-octets of Response )
   }


A.8 LmEncryptedPasswordHash()

   LmEncryptedPasswordHash(
   IN  0-to-14-oem-char Password,
   IN  8-octet          KeyValue,
   OUT 16-octet         Cypher )
   {
      LmPasswordHash( Password, giving PasswordHash )

      PasswordHashEncryptedWithBlock( PasswordHash,
                                      KeyValue,
                                      giving Cypher )
   }


A.9 PasswordHashEncryptedWithBlock()

   PasswordHashEncryptedWithBlock(
   IN  16-octet PasswordHash,
   IN  8-octet  Block,
   OUT 16-octet Cypher )
   {



Zorn & Cobb                  Informational                     [Page 13]

RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998


      DesEncrypt( 1st 8-octets PasswordHash,
                  1st 7-octets Block,
                  giving 1st 8-octets Cypher )

      DesEncrypt( 2nd 8-octets PasswordHash,
                  1st 7-octets Block,
                  giving 2nd 8-octets Cypher )
   }


A.10 NtEncryptedPasswordHash()

   NtEncryptedPasswordHash(  IN   0-to-14-oem-char  Password IN  8-octet
   Challenge OUT 16-octet         Cypher ) {
      NtPasswordHash( Password, giving PasswordHash )