home *** CD-ROM | disk | FTP | other *** search
/ Internet Core Protocols / Oreilly-InternetCoreProtocols.iso / RFCs / rfc2433.txt < prev    next >
Encoding:
Text File  |  1999-10-14  |  34.8 KB  |  1,124 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                            G. Zorn
  8. Request for Comments: 2433                                       S. Cobb
  9. Category: Informational                            Microsoft Corporation
  10.                                                             October 1998
  11.  
  12.  
  13.                      Microsoft PPP CHAP Extensions
  14.  
  15. Status of this Memo
  16.  
  17.    This memo provides information for the Internet community.  It does
  18.    not specify an Internet standard of any kind.  Distribution of this
  19.    memo is unlimited.
  20.  
  21. Copyright Notice
  22.  
  23.    Copyright (C) The Internet Society (1998).  All Rights Reserved.
  24.  
  25. IESG Note
  26.  
  27.    The protocol described here has significant vulnerabilities.  People
  28.    planning on implementing or using this protocol should read section
  29.    12, "Security Considerations".
  30.  
  31. 1.  Abstract
  32.  
  33.    The Point-to-Point Protocol (PPP) [1] provides a standard method for
  34.    transporting multi-protocol datagrams over point-to-point links.  PPP
  35.    defines an extensible Link Control Protocol and a family of Network
  36.    Control Protocols (NCPs) for establishing and configuring different
  37.    network-layer protocols.
  38.  
  39.    This document describes Microsoft's PPP CHAP dialect (MS-CHAP), which
  40.    extends the user authentication functionality provided on Windows
  41.    networks to remote workstations.  MS-CHAP is closely derived from the
  42.    PPP Challenge Handshake Authentication Protocol described in RFC 1994
  43.    [2], which the reader should have at hand.
  44.  
  45.    The algorithms used in the generation of various MS-CHAP protocol
  46.    fields are described in an appendix.
  47.  
  48. 2.  Introduction
  49.  
  50.    Microsoft created MS-CHAP to authenticate remote Windows
  51.    workstations, providing the functionality to which LAN-based users
  52.    are accustomed while integrating the encryption and hashing
  53.    algorithms used on Windows networks.
  54.  
  55.  
  56.  
  57.  
  58. Zorn & Cobb                  Informational                      [Page 1]
  59.  
  60. RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
  61.  
  62.  
  63.    Where possible, MS-CHAP is consistent with standard CHAP.  Briefly,
  64.    the differences between MS-CHAP and standard CHAP are:
  65.  
  66.       * MS-CHAP is enabled by negotiating CHAP Algorithm 0x80 in LCP
  67.         option 3, Authentication Protocol.
  68.  
  69.       * The MS-CHAP Response packet is in a format designed for
  70.         compatibility with Microsoft's Windows NT 3.5, 3.51 and 4.0, and
  71.         Windows95 networking products.  The MS-CHAP format does not
  72.         require the authenticator to store a clear-text or reversibly
  73.         encrypted password.
  74.  
  75.       * MS-CHAP provides authenticator-controlled authentication retry
  76.         and password changing mechanisms.
  77.  
  78.       * MS-CHAP defines a set of reason-for-failure codes returned in
  79.         the Failure packet Message field.
  80.  
  81. 3.  Specification of Requirements
  82.  
  83.    In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
  84.    "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as
  85.    described in [2].
  86.  
  87. 4.  LCP Configuration
  88.  
  89.    The LCP configuration for MS-CHAP is identical to that for standard
  90.    CHAP, except that the Algorithm field has value 0x80, rather than the
  91.    MD5 value 0x05.  PPP implementations which do not support MS-CHAP,
  92.    but correctly implement LCP Config-Rej, should have no problem
  93.    dealing with this non-standard option.
  94.  
  95. 5.  Challenge Packet
  96.  
  97.    The MS-CHAP Challenge packet is identical in format to the standard
  98.    CHAP Challenge packet.
  99.  
  100.    MS-CHAP authenticators send an 8-octet challenge Value field.  Peers
  101.    need not duplicate Microsoft's algorithm for selecting the 8-octet
  102.    value, but the standard guidelines on randomness [1,2,7] SHOULD be
  103.    observed.
  104.  
  105.    Microsoft authenticators do not currently provide information in the
  106.    Name field.  This may change in the future.
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Zorn & Cobb                  Informational                      [Page 2]
  115.  
  116. RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
  117.  
  118.  
  119. 6.  Response Packet
  120.  
  121.    The MS-CHAP Response packet is identical in format to the standard
  122.    CHAP Response packet.  However, the Value field is sub-formatted
  123.    differently as follows:
  124.  
  125.       24 octets: LAN Manager compatible challenge response
  126.       24 octets: Windows NT compatible challenge response
  127.        1 octet : "Use Windows NT compatible challenge response" flag
  128.  
  129.    The LAN Manager compatible challenge response is an encoded function
  130.    of the password and the received challenge as output by the routine
  131.    LmChallengeResponse() (see section A.1, below).  LAN Manager
  132.    passwords are limited to 14 case-insensitive OEM characters.  Note
  133.    that use of the LAN Manager compatible challenge response has been
  134.    deprecated; peers SHOULD NOT generate it, and the sub-field SHOULD be
  135.    zero-filled.  The algorithm used in the generation of the LAN Manager
  136.    compatible challenge response is described here for informational
  137.    purposes only.
  138.  
  139.    The Windows NT compatible challenge response is an encoded function
  140.    of the password and the received challenge as output by the routine
  141.    NTChallengeResponse() (see section A.5, below).  The Windows NT
  142.    password is a string of 0 to (theoretically) 256 case-sensitive
  143.    Unicode [8] characters.  Current versions of Windows NT limit
  144.    passwords to 14 characters, mainly for compatibility reasons; this
  145.    may change in the future.
  146.  
  147.    The "use Windows NT compatible challenge response" flag, if 1,
  148.    indicates that the Windows NT response is provided and should be used
  149.    in preference to the LAN Manager response.  The LAN Manager response
  150.    will still be used if the account does not have a Windows NT password
  151.    hash, e.g.  if the password has not been changed since the account
  152.    was uploaded from a LAN Manager 2.x account database.  If the flag is
  153.    0, the Windows NT response is ignored and the LAN Manager response is
  154.    used.  Since the use of LAN Manager authentication has been
  155.    deprecated, this flag SHOULD always be set (1) and the LAN Manager
  156.    compatible challenge response field SHOULD be zero-filled.
  157.  
  158.    The Name field identifies the peer's user account name.  The Windows
  159.    NT domain name may prefix the user's account name (e.g.
  160.    "BIGCO\johndoe" where "BIGCO" is a Windows NT domain containing the
  161.    user account "john-doe").  If a domain is not provided, the backslash
  162.    should also be omitted, (e.g. "johndoe").
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Zorn & Cobb                  Informational                      [Page 3]
  171.  
  172. RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
  173.  
  174.  
  175. 7.  Success Packet
  176.  
  177.    The Success packet is identical in format to the standard CHAP
  178.    Success packet.
  179.  
  180. 8.  Failure Packet
  181.  
  182.    The Failure packet is identical in format to the standard CHAP
  183.    Failure packet.  There is, however, formatted text stored in the
  184.    Message field which, contrary to the standard CHAP rules, affects the
  185.    protocol.  The Message field format is:
  186.  
  187.          "E=eeeeeeeeee R=r C=cccccccccccccccc V=vvvvvvvvvv"
  188.  
  189.       where
  190.  
  191.          The "eeeeeeeeee" is the decimal error code (need not be 10
  192.          digits) corresponding to one of those listed below, though
  193.          implementations should deal with codes not on this list
  194.          gracefully.
  195.  
  196.             646 ERROR_RESTRICTED_LOGON_HOURS
  197.             647 ERROR_ACCT_DISABLED
  198.             648 ERROR_PASSWD_EXPIRED
  199.             649 ERROR_NO_DIALIN_PERMISSION
  200.             691 ERROR_AUTHENTICATION_FAILURE
  201.             709 ERROR_CHANGING_PASSWORD
  202.  
  203.          The "r" is a flag set to "1" if a retry is allowed, and "0" if
  204.          not.  When the authenticator sets this flag to "1" it disables
  205.          short timeouts, expecting the peer to prompt the user for new
  206.          credentials and resubmit the response.
  207.  
  208.          The "cccccccccccccccc" is 16 hexadecimal digits representing an
  209.          ASCII representation of a new challenge value.  This field is
  210.          optional.  If it is not sent, the authenticator expects the
  211.          resubmitted response to be calculated based on the previous
  212.          challenge value plus decimal 23 in the first octet, i.e. the
  213.          one immediately following the Value Size field.  Windows 95
  214.          authenticators may send this field.  Windows NT authenticators
  215.          do not, but may in the future.  Both systems implement peer
  216.          support of this field.
  217.  
  218.          The "vvvvvvvvvv" is the decimal version code (need not be 10
  219.          digits) indicating the MS-CHAP protocol version supported on
  220.          the server.  Currently, this is interesting only in selecting a
  221.          Change Password packet type.  If the field is not present the
  222.          version should be assumed to be 1; since use of the version 1
  223.  
  224.  
  225.  
  226. Zorn & Cobb                  Informational                      [Page 4]
  227.  
  228. RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
  229.  
  230.  
  231.          Change Password packet has been deprecated, this field SHOULD
  232.          always contain a value greater than or equal to 2.
  233.  
  234.    Implementations should accept but ignore additional text they do not
  235.    recognize.
  236.  
  237. 9.  Change Password Packet (version 1)
  238.  
  239.    The version 1 Change Password packet does not appear in standard
  240.    CHAP.  It allows the peer to change the password on the account
  241.    specified in the previous Response packet.  The version 1 Change
  242.    Password packet should be sent only if the authenticator reports
  243.    ERROR_PASSWD_EXPIRED (E=648) and V is either missing or equal to one
  244.    in the Message field of the Failure packet.
  245.  
  246.    The use of the Change Password Packet (version 1) has been
  247.    deprecated; the format of the packet is described here for
  248.    informational purposes, but peers SHOULD NOT transmit it.
  249.  
  250.    The format of this packet is as follows:
  251.  
  252.        1 octet : Code (=5)
  253.        1 octet : Identifier
  254.        2 octets: Length (=72)
  255.       16 octets: Encrypted LAN Manager Old password Hash
  256.       16 octets: Encrypted LAN Manager New Password Hash
  257.       16 octets: Encrypted Windows NT Old Password Hash
  258.       16 octets: Encrypted Windows NT New Password Hash
  259.        2 octets: Password Length
  260.        2 octets: Flags
  261.  
  262.       Code
  263.          5
  264.  
  265.       Identifier
  266.          The Identifier field is one octet and aids in matching requests
  267.          and replies.  The value is the Identifier of the received
  268.          Failure packet to which this packet responds plus 1.
  269.  
  270.       Length
  271.          72
  272.  
  273.       Encrypted LAN Manager New Password Hash
  274.       Encrypted LAN Manager Old Password Hash
  275.          These fields contain the LAN Manager password hash of the new
  276.          and old passwords encrypted with the last received challenge
  277.          value, as output by the routine LmEncryptedPasswordHash() (see
  278.          section A.8, below).
  279.  
  280.  
  281.  
  282. Zorn & Cobb                  Informational                      [Page 5]
  283.  
  284. RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
  285.  
  286.  
  287.       Encrypted Windows NT New Password Hash
  288.       Encrypted Windows NT Old Password Hash
  289.          These fields contain the Windows NT password hash of the new
  290.          and old passwords encrypted with the last received challenge
  291.          value, as output by the pseudo-code routine
  292.          NtEncryptedPasswordHash() (see section A.10, below).
  293.  
  294.       Password Length
  295.          The length in octets of the LAN Manager compatible form of the
  296.          new password.  If this value is greater than or equal to zero
  297.          and less than or equal to 14 it is assumed that the encrypted
  298.          LAN Manager password hash fields are valid.  Otherwise, it is
  299.          assumed these fields are not valid, in which case the Windows
  300.          NT compatible passwords MUST be provided.
  301.  
  302.       Flags
  303.          This field is two octets in length.  It is a bit field of
  304.          option flags where 0 is the least significant bit of the 16-bit
  305.          quantity:
  306.  
  307.             Bit 0
  308.                If this bit is set (1), it indicates that the encrypted
  309.                Windows NT hashed passwords are valid and should be used.
  310.                If this bit is cleared (0), the Windows NT fields are not
  311.                used and the LAN Manager fields must be provided.
  312.  
  313.             Bits 1-15
  314.                Reserved, always clear (0).
  315.  
  316. 10.  Change Password Packet (version 2)
  317.  
  318.    The version 2 Change Password packet does not appear in standard
  319.    CHAP.  It allows the peer to change the password on the account
  320.    specified in the preceding Response packet.  The version 2 Change
  321.    Password packet should be sent only if the authenticator reports
  322.    ERROR_PASSWD_EXPIRED (E=648) and a version of 2 or greater in the
  323.    Message field of the Failure packet.
  324.  
  325.    This packet type is supported by Windows NT 3.51, 4.0 and recent
  326.    versions of Windows 95.  It is not supported by Windows NT 3.5 or
  327.    early versions of Windows 95.
  328.  
  329.       The format of this packet is as follows:
  330.  
  331.            1 octet  : Code
  332.            1 octet  : Identifier
  333.            2 octets : Length
  334.          516 octets : Password Encrypted with Old NT Hash
  335.  
  336.  
  337.  
  338. Zorn & Cobb                  Informational                      [Page 6]
  339.  
  340. RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
  341.  
  342.  
  343.           16 octets : Old NT Hash Encrypted with New NT Hash
  344.          516 octets : Password Encrypted with Old LM Hash
  345.           16 octets : Old LM Hash Encrypted With New NT Hash
  346.           24 octets : LAN Manager compatible challenge response
  347.           24 octets : Windows NT compatible challenge response
  348.            2-octet  : Flags
  349.  
  350.       Code
  351.          6
  352.  
  353.       Identifier
  354.          The Identifier field is one octet and aids in matching requests
  355.          and replies.  The value is the Identifier of the received
  356.          Failure packet to which this packet responds plus 1.
  357.  
  358.       Length
  359.          1118
  360.  
  361.       Password Encrypted with Old NT Hash
  362.          This field contains the PWBLOCK form of the new Windows NT
  363.          password encrypted with the old Windows NT password hash, as
  364.          output by the NewPasswordEncryptedWithOldNtPasswordHash()
  365.          routine (see section A.11, below).
  366.  
  367.       Old NT Hash Encrypted with New NT Hash
  368.          This field contains the old Windows NT password hash encrypted
  369.          with the new Windows NT password hash, as output by the
  370.          OldNtPasswordHashEncryptedWithNewNtPasswordHash() routine (see
  371.          section A.14, below).
  372.  
  373.       Password Encrypted with Old LM Hash
  374.          This field contains the PWBLOCK form of the new Windows NT
  375.          password encrypted with the old LAN Manager password hash, as
  376.          output by the NewPasswordEncryptedWithOldLmPasswordHash()
  377.          routine described in section A.15, below.  Note, however, that
  378.          the use of this field has been deprecated: peers SHOULD NOT
  379.          generate it, and this field SHOULD be zero-filled.
  380.  
  381.       Old LM Hash Encrypted With New NT Hash
  382.          This field contains the old LAN Manager password hash encrypted
  383.          with the new Windows NT password hash, as output by the
  384.          OldLmPasswordHashEncryptedWithNewNtPasswordHash() routine (see
  385.          section A.16, below).  Note, however, that the use of this
  386.          field has been deprecated: peers SHOULD NOT generate it, and
  387.          this field SHOULD be zero-filled.
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Zorn & Cobb                  Informational                      [Page 7]
  395.  
  396. RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
  397.  
  398.  
  399.       LAN Manager compatible challenge response
  400.       Windows NT compatible challenge response
  401.          The challenge response field (as described in the Response
  402.          packet description), but calculated on the new password and the
  403.          same challenge used in the last response.  Note that use of the
  404.          LAN Manager compatible challenge response has been deprecated;
  405.          peers SHOULD NOT generate it, and the field SHOULD be zero-
  406.          filled.
  407.  
  408.       Flags
  409.          This field is two octets in length.  It is a bit field of
  410.          option flags where 0 is the least significant bit of the 16-bit
  411.          quantity.  The format of this field is illustrated in the
  412.          following diagram:
  413.  
  414.                    1
  415.          5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
  416.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  417.          |                           | |
  418.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  419.  
  420.             Bit 0
  421.                The "use Windows NT compatible challenge response" flag
  422.                as described in the Response packet.
  423.  
  424.             Bit 1
  425.                Set (1) indicates that the "Password Encrypted with Old
  426.                LM Hash" and "Old LM Hash Encrypted With New NT Hash"
  427.                fields are valid and should be used.  Clear (0) indicates
  428.                these fields are not valid.  This bit SHOULD always be
  429.                clear (0).
  430.  
  431.             Bits 2-15
  432.                Reserved, always clear (0).
  433.  
  434. 11.  Security Considerations
  435.  
  436.    As an implementation detail, the authenticator SHOULD limit the
  437.    number of password retries allowed to make brute-force password
  438.    guessing attacks more difficult.
  439.  
  440.    Because the challenge value is encrypted using the password hash to
  441.    form the response and the challenge is transmitted in clear-text
  442.    form, both passive known-plaintext and active chosen-plaintext
  443.    attacks against the password hash are possible.  Suitable precautions
  444.    (i.e., frequent password changes) SHOULD be taken in environments
  445.    where eavesdropping is likely.
  446.  
  447.  
  448.  
  449.  
  450. Zorn & Cobb                  Informational                      [Page 8]
  451.  
  452. RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
  453.  
  454.  
  455.    The Change Password (version 1) packet is vulnerable to a passive
  456.    eavesdropping attack which can easily reveal the new password hash.
  457.    For this reason, it MUST NOT be sent if eavesdropping is possible.
  458.  
  459. 12.  References
  460.  
  461.    [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
  462.        1661, July 1994.
  463.  
  464.    [2] Simpson, W., "PPP Challenge Handshake Authentication Protocol
  465.        (CHAP)", RFC 1994, August 1996.
  466.  
  467.    [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
  468.        Levels", BCP 14, RFC 2119, March 1997.
  469.  
  470.    [4] "Data Encryption Standard (DES)", Federal Information Processing
  471.        Standard Publication 46-2, National Institute of Standards and
  472.        Technology, December 1993.
  473.  
  474.    [5] Rivest, R., "MD4 Message Digest Algorithm", RFC 1320, April 1992.
  475.  
  476.    [6] RC4 is a proprietary encryption algorithm available under license
  477.        from RSA Data Security Inc.  For licensing information, contact:
  478.        RSA Data Security, Inc.
  479.        100 Marine Parkway
  480.        Redwood City, CA 94065-1031
  481.  
  482.    [7] Eastlake, D., Crocker, S., and J. Schiller, "Randomness
  483.        Recomnendations for Security", RFC 1750, December 1994.
  484.  
  485.    [8] "The Unicode Standard, Version 2.0", The Unicode Consortium,
  486.        Addison-Wesley, 1996. ISBN 0-201-48345-9.
  487.  
  488.    [9] "DES Modes of Operation", Federal Information Processing
  489.        Standards Publication 81, National Institute of Standards and
  490.        Technology, December 1980
  491.  
  492. 13.  Acknowledgements
  493.  
  494.    Thanks (in no particular order) to Jeff Haag (Jeff_Haag@3com.com),
  495.    Bill Palter (palter@network-alchemy.com), Bruce Johnson
  496.    (bjohnson@microsoft.com), Tony Bell (tonybe@microsoft.com), Benoit
  497.    Martin (ehlija@vircom.com), and Joe Davies (josephd@microsoft.com)
  498.    for useful suggestions and feedback.
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Zorn & Cobb                  Informational                      [Page 9]
  507.  
  508. RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
  509.  
  510.  
  511. 14.  Chair's Address
  512.  
  513.    The PPP Extensions Working Group can be contacted via the current
  514.    chair:
  515.  
  516.    Karl Fox
  517.    Ascend Communications
  518.    3518 Riverside Drive
  519.    Suite 101
  520.    Columbus, OH 43221
  521.  
  522.    Phone: +1 614 326 6841
  523.    EMail: karl@ascend.com
  524.  
  525. 15.  Authors' Addresses
  526.  
  527.    Questions about this memo can also be directed to:
  528.  
  529.    Glen Zorn
  530.    Microsoft Corporation
  531.    One Microsoft Way
  532.    Redmond, Washington 98052
  533.  
  534.    Phone: +1 425 703 1559
  535.    Fax:   +1 425 936 7329
  536.    EMail: glennz@microsoft.com
  537.  
  538.  
  539.    Steve Cobb
  540.    Microsoft Corporation
  541.    One Microsoft Way
  542.    Redmond, Washington 98052
  543.  
  544.    EMail: stevec@microsoft.com
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Zorn & Cobb                  Informational                     [Page 10]
  563.  
  564. RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
  565.  
  566.  
  567. Appendix A - Pseudocode
  568.  
  569.    The routines mentioned in the text are described in pseudocode below.
  570.  
  571. A.1 LmChallengeResponse()
  572.  
  573.    LmChallengeResponse(
  574.    IN  8-octet          Challenge,
  575.    IN  0-to-14-oem-char Password,
  576.    OUT 24-octet         Response )
  577.    {
  578.       LmPasswordHash( Password, giving PasswordHash )
  579.       ChallengeResponse( Challenge, PasswordHash, giving Response )
  580.    }
  581.  
  582.  
  583. A.2 LmPasswordHash()
  584.  
  585.    LmPasswordHash(
  586.    IN  0-to-14-oem-char Password,
  587.    OUT 16-octet         PasswordHash )
  588.    {
  589.       Set UcasePassword to the uppercased Password
  590.       Zero pad UcasePassword to 14 characters
  591.  
  592.       DesHash( 1st 7-octets of UcasePassword,
  593.                giving 1st 8-octets of PasswordHash )
  594.  
  595.       DesHash( 2nd 7-octets of UcasePassword,
  596.                giving 2nd 8-octets of PasswordHash )
  597.    }
  598.  
  599.  
  600. A.3 DesHash()
  601.  
  602.    DesHash(
  603.    IN  7-octet Clear,
  604.    OUT 8-octet Cypher )
  605.    {
  606.       /*
  607.        * Make Cypher an irreversibly encrypted form of Clear by
  608.        * encrypting known text using Clear as the secret key.
  609.        * The known text consists of the string
  610.        *
  611.        *              KGS!@#$%
  612.        */
  613.  
  614.       Set StdText to "KGS!@#$%"
  615.  
  616.  
  617.  
  618. Zorn & Cobb                  Informational                     [Page 11]
  619.  
  620. RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
  621.  
  622.  
  623.       DesEncrypt( StdText, Clear, giving Cypher )
  624.    }
  625.  
  626.  
  627. A.4 DesEncrypt()
  628.  
  629.    DesEncrypt(
  630.    IN  8-octet Clear,
  631.    IN  7-octet Key,
  632.    OUT 8-octet Cypher )
  633.    {
  634.       /*
  635.        * Use the DES encryption algorithm [4] in ECB mode [9]
  636.        * to encrypt Clear into Cypher such that Cypher can
  637.        * only be decrypted back to Clear by providing Key.
  638.        * Note that the DES algorithm takes as input a 64-bit
  639.        * stream where the 8th, 16th, 24th, etc.  bits are
  640.        * parity bits ignored by the encrypting algorithm.
  641.        * Unless you write your own DES to accept 56-bit input
  642.        * without parity, you will need to insert the parity bits
  643.        * yourself.
  644.        */
  645.    }
  646.  
  647.  
  648. A.5 NtChallengeResponse()
  649.  
  650.    NtChallengeResponse(
  651.    IN  8-octet               Challenge,
  652.    IN  0-to-256-unicode-char Password,
  653.    OUT 24-octet              Response )
  654.    {
  655.       NtPasswordHash( Password, giving PasswordHash )
  656.       ChallengeResponse( Challenge, PasswordHash, giving Response )
  657.    }
  658.  
  659.  
  660. A.6 NtPasswordHash()
  661.  
  662.    NtPasswordHash(
  663.    IN  0-to-256-unicode-char Password,
  664.    OUT 16-octet              PasswordHash )
  665.    {
  666.       /*
  667.        * Use the MD4 algorithm [5] to irreversibly hash Password
  668.        * into PasswordHash.  Only the password is hashed without
  669.        * including any terminating 0.
  670.        */
  671.  
  672.  
  673.  
  674. Zorn & Cobb                  Informational                     [Page 12]
  675.  
  676. RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
  677.  
  678.  
  679.    }
  680.  
  681.  
  682. A.7 ChallengeResponse()
  683.  
  684.    ChallengeResponse(
  685.    IN  8-octet  Challenge,
  686.    IN  16-octet PasswordHash,
  687.    OUT 24-octet Response )
  688.    {
  689.       Set ZPasswordHash to PasswordHash zero-padded to 21 octets
  690.  
  691.       DesEncrypt( Challenge,
  692.                   1st 7-octets of ZPasswordHash,
  693.                   giving 1st 8-octets of Response )
  694.  
  695.       DesEncrypt( Challenge,
  696.                   2nd 7-octets of ZPasswordHash,
  697.                   giving 2nd 8-octets of Response )
  698.  
  699.       DesEncrypt( Challenge,
  700.                   3rd 7-octets of ZPasswordHash,
  701.                   giving 3rd 8-octets of Response )
  702.    }
  703.  
  704.  
  705. A.8 LmEncryptedPasswordHash()
  706.  
  707.    LmEncryptedPasswordHash(
  708.    IN  0-to-14-oem-char Password,
  709.    IN  8-octet          KeyValue,
  710.    OUT 16-octet         Cypher )
  711.    {
  712.       LmPasswordHash( Password, giving PasswordHash )
  713.  
  714.       PasswordHashEncryptedWithBlock( PasswordHash,
  715.                                       KeyValue,
  716.                                       giving Cypher )
  717.    }
  718.  
  719.  
  720. A.9 PasswordHashEncryptedWithBlock()
  721.  
  722.    PasswordHashEncryptedWithBlock(
  723.    IN  16-octet PasswordHash,
  724.    IN  8-octet  Block,
  725.    OUT 16-octet Cypher )
  726.    {
  727.  
  728.  
  729.  
  730. Zorn & Cobb                  Informational                     [Page 13]
  731.  
  732. RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
  733.  
  734.  
  735.       DesEncrypt( 1st 8-octets PasswordHash,
  736.                   1st 7-octets Block,
  737.                   giving 1st 8-octets Cypher )
  738.  
  739.       DesEncrypt( 2nd 8-octets PasswordHash,
  740.                   1st 7-octets Block,
  741.                   giving 2nd 8-octets Cypher )
  742.    }
  743.  
  744.  
  745. A.10 NtEncryptedPasswordHash()
  746.  
  747.    NtEncryptedPasswordHash(  IN   0-to-14-oem-char  Password IN  8-octet
  748.    Challenge OUT 16-octet         Cypher ) {
  749.       NtPasswordHash( Password, giving PasswordHash )
  750.  
  751.       PasswordHashEncryptedWithBlock( PasswordHash,
  752.                                       Challenge,
  753.                                       giving Cypher )
  754.    }
  755.  
  756.  
  757. A.11 NewPasswordEncryptedWithOldNtPasswordHash()
  758.  
  759.    datatype-PWBLOCK
  760.    {
  761.       256-unicode-char Password
  762.       4-octets         PasswordLength
  763.    }
  764.  
  765.    NewPasswordEncryptedWithOldNtPasswordHash(
  766.    IN  0-to-256-unicode-char NewPassword,
  767.    IN  0-to-256-unicode-char OldPassword,
  768.    OUT datatype-PWBLOCK      EncryptedPwBlock )
  769.    {
  770.       NtPasswordHash( OldPassword, giving PasswordHash )
  771.  
  772.       EncryptPwBlockWithPasswordHash( NewPassword,
  773.                                       PasswordHash,
  774.                                       giving EncryptedPwBlock )
  775.    }
  776.  
  777.  
  778. A.12 EncryptPwBlockWithPasswordHash()
  779.  
  780.    EncryptPwBlockWithPasswordHash(
  781.    IN  0-to-256-unicode-char Password,
  782.    IN  16-octet              PasswordHash,
  783.  
  784.  
  785.  
  786. Zorn & Cobb                  Informational                     [Page 14]
  787.  
  788. RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
  789.  
  790.  
  791.    OUT datatype-PWBLOCK      PwBlock )
  792.    {
  793.  
  794.       Fill ClearPwBlock with random octet values
  795.       PwSize = lstrlenW( Password ) * sizeof( unicode-char )
  796.       PwOffset = sizeof( ClearPwBlock.Password ) - PwSize
  797.       Move PwSize octets to (ClearPwBlock.Password + PwOffset ) from Password
  798.       ClearPwBlock.PasswordLength = PwSize
  799.       Rc4Encrypt( ClearPwBlock,
  800.                   sizeof( ClearPwBlock ),
  801.                   PasswordHash,
  802.                   sizeof( PasswordHash ),
  803.                   giving PwBlock )
  804.    }
  805.  
  806.  
  807. A.13 Rc4Encrypt()
  808.  
  809.    Rc4Encrypt(
  810.    IN  x-octet Clear,
  811.    IN  integer ClearLength,
  812.    IN  y-octet Key,
  813.    IN  integer KeyLength,
  814.    OUT x-octet Cypher )
  815.    {
  816.       /*
  817.        * Use the RC4 encryption algorithm [6] to encrypt Clear of
  818.        * length ClearLength octets into a Cypher of the same length
  819.        * such that the Cypher can only be decrypted back to Clear
  820.        * by providing a Key of length KeyLength octets.
  821.        */
  822.    }
  823.  
  824.  
  825. A.14 OldNtPasswordHashEncryptedWithNewNtPasswordHash()
  826.  
  827.    OldNtPasswordHashEncryptedWithNewNtPasswordHash(
  828.    IN  0-to-256-unicode-char NewPassword,
  829.    IN  0-to-256-unicode-char OldPassword,
  830.    OUT 16-octet              EncryptedPasswordHash )
  831.    {
  832.       NtPasswordHash( OldPassword, giving OldPasswordHash )
  833.       NtPasswordHash( NewPassword, giving NewPasswordHash )
  834.       NtPasswordHashEncryptedWithBlock( OldPasswordHash,
  835.                                         NewPasswordHash,
  836.                                         giving EncryptedPasswordHash )
  837.    }
  838.  
  839.  
  840.  
  841.  
  842. Zorn & Cobb                  Informational                     [Page 15]
  843.  
  844. RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
  845.  
  846.  
  847. A.15 NewPasswordEncryptedWithOldLmPasswordHash()
  848.  
  849.    NewPasswordEncryptedWithOldLmPasswordHash(
  850.    IN  0-to-256-unicode-char NewPassword,
  851.    IN  0-to-256-unicode-char OldPassword,
  852.    OUT datatype-PWBLOCK      EncryptedPwBlock )
  853.    {
  854.       LmPasswordHash( OldPassword, giving PasswordHash )
  855.  
  856.       EncryptPwBlockWithPasswordHash( NewPassword, PasswordHash,
  857.                                       giving EncryptedPwBlock )
  858.    }
  859.  
  860.  
  861. A.16 OldLmPasswordHashEncryptedWithNewNtPasswordHash()
  862.  
  863.    OldLmPasswordHashEncryptedWithNewNtPasswordHash(
  864.    IN  0-to-256-unicode-char NewPassword,
  865.    IN  0-to-256-unicode-char OldPassword,
  866.    OUT 16-octet              EncryptedPasswordHash )
  867.    {
  868.       LmPasswordHash( OldPassword, giving OldPasswordHash )
  869.  
  870.       NtPasswordHash( NewPassword, giving NewPasswordHash )
  871.  
  872.       NtPasswordHashEncryptedWithBlock( OldPasswordHash, NewPasswordHash,
  873.                                       giving EncrytptedPasswordHash )
  874.    }
  875.  
  876.  
  877. A.17 NtPasswordHashEncryptedWithBlock()
  878.  
  879.    NtPasswordHashEncryptedWithBlock(
  880.    IN  16-octet PasswordHash,
  881.    IN  16-octet Block,
  882.    OUT 16-octet Cypher )
  883.    {
  884.       DesEncrypt( 1st 8-octets PasswordHash,
  885.                   1st 7-octets Block,
  886.                   giving 1st 8-octets Cypher )
  887.  
  888.       DesEncrypt( 2nd 8-octets PasswordHash,
  889.                   2nd 7-octets Block,
  890.                   giving 2nd 8-octets Cypher )
  891.    }
  892.  
  893.  
  894.  
  895.  
  896.  
  897.  
  898. Zorn & Cobb                  Informational                     [Page 16]
  899.  
  900. RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
  901.  
  902.  
  903. Appendix B - Examples
  904.  
  905. B.1 Negotiation Examples
  906.  
  907.    Here are some examples of typical negotiations.  The peer is on the
  908.    left and the authenticator is on the right.
  909.  
  910.    The packet sequence ID is incremented on each authentication retry
  911.    Response and on the change password response.  All cases where the
  912.    packet sequence ID is updated are noted below.
  913.  
  914.    Response retry is never allowed after Change Password.  Change
  915.    Password may occur after Response retry.  The implied challenge form
  916.    is shown in the examples, though all cases of "first challenge+23"
  917.    should be replaced by the "C=cccccccccccccccc" challenge if
  918.    authenticator supplies it in the Failure packet.
  919.  
  920. B.1.1 Successful authentication
  921.  
  922.             <- Challenge
  923.         Response ->
  924.             <- Success
  925.  
  926.  
  927. B.1.2 Failed authentication with no retry allowed
  928.  
  929.             <- Challenge
  930.         Response ->
  931.             <- Failure (E=691 R=0)
  932.  
  933.  
  934. B.1.3 Successful authentication after retry
  935.  
  936.             <- Challenge
  937.         Response ->
  938.             <- Failure (E=691 R=1), disable short timeout
  939.         Response (++ID) to first challenge+23 ->
  940.             <- Success
  941.  
  942.  
  943. B.1.4 Failed hack attack with 3 attempts allowed
  944.  
  945.             <- Challenge
  946.         Response ->
  947.             <- Failure (E=691 R=1), disable short timeout
  948.         Response (++ID) to first challenge+23 ->
  949.             <- Failure (E=691 R=1), disable short timeout
  950.         Response (++ID) to first challenge+23+23 ->
  951.  
  952.  
  953.  
  954. Zorn & Cobb                  Informational                     [Page 17]
  955.  
  956. RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
  957.  
  958.  
  959.             <- Failure (E=691 R=0)
  960.  
  961.  
  962. B.1.5 Successful authentication with password change
  963.  
  964.             <- Challenge
  965.         Response ->
  966.             <- Failure (E=648 R=0 V=2), disable short timeout
  967.         ChangePassword (++ID) to first challenge ->
  968.             <- Success
  969.  
  970.  
  971. B.1.6 Successful authentication with retry and password change
  972.  
  973.             <- Challenge
  974.         Response ->
  975.             <- Failure (E=691 R=1), disable short timeout
  976.         Response (++ID) to first challenge+23 ->
  977.             <- Failure (E=648 R=0 V=2), disable short timeout
  978.         ChangePassword (++ID) to first challenge+23 ->
  979.             <- Success
  980.  
  981. B.2 Hash Example
  982.  
  983. Intermediate values for password "MyPw".
  984.  
  985.    8-octet Challenge:
  986.    10 2D B5 DF 08 5D 30 41
  987.  
  988.    0-to-256-unicode-char NtPassword:
  989.    4D 00 79 00 50 00 77 00
  990.  
  991.    16-octet NtPasswordHash:
  992.    FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC
  993.  
  994.    24-octet NtChallengeResponse:
  995.    4E 9D 3C 8F 9C FD 38 5D 5B F4 D3 24 67 91 95 6C
  996.    A4 C3 51 AB 40 9A 3D 61
  997.  
  998. B.3 Example of DES Key Generation
  999.  
  1000. DES uses 56-bit keys, expanded to 64 bits by the insertion of parity
  1001. bits.  After the parity of the key has been fixed, every eighth bit is a
  1002. parity bit and the number of bits that are set (1) in each octet is odd;
  1003. i.e., odd parity.  Note that many DES engines do not check parity,
  1004. however, simply stripping the parity bits.  The following example
  1005. illustrates the values resulting from the use of the 16-octet
  1006. NTPasswordHash shown in Appendix B.2 to generate a pair of DES keys
  1007.  
  1008.  
  1009.  
  1010. Zorn & Cobb                  Informational                     [Page 18]
  1011.  
  1012. RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
  1013.  
  1014.  
  1015. (e.g., for use in the NtPasswordHashEncryptedWithBlock() described in
  1016. Appendix A.17).
  1017.  
  1018.    16-octet NtPasswordHash:
  1019.    FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC
  1020.  
  1021.    First "raw" DES key (initial 7 octets of password hash):
  1022.    FC 15 6A F7 ED CD 6C
  1023.  
  1024.    First parity-corrected DES key (eight octets):
  1025.    FD 0B 5B 5E 7F 6E 34 D9
  1026.  
  1027.    Second "raw" DES key (second 7 octets of password hash)
  1028.    0E DD E3 33 7D 42 7F
  1029.  
  1030.    Second parity-corrected DES key (eight octets):
  1031.    0E 6E 79 67 37 EA 08 FE
  1032.  
  1033.  
  1034.  
  1035.  
  1036.  
  1037.  
  1038.  
  1039.  
  1040.  
  1041.  
  1042.  
  1043.  
  1044.  
  1045.  
  1046.  
  1047.  
  1048.  
  1049.  
  1050.  
  1051.  
  1052.  
  1053.  
  1054.  
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060.  
  1061.  
  1062.  
  1063.  
  1064.  
  1065.  
  1066. Zorn & Cobb                  Informational                     [Page 19]
  1067.  
  1068. RFC 2433             Microsoft PPP CHAP Extensions         Ocotober 1998
  1069.  
  1070.  
  1071. Full Copyright Statement
  1072.  
  1073.    Copyright (C) The Internet Society (1998).  All Rights Reserved.
  1074.  
  1075.    This document and translations of it may be copied and furnished to
  1076.    others, and derivative works that comment on or otherwise explain it
  1077.    or assist in its implementation may be prepared, copied, published
  1078.    and distributed, in whole or in part, without restriction of any
  1079.    kind, provided that the above copyright notice and this paragraph are
  1080.    included on all such copies and derivative works.  However, this
  1081.    document itself may not be modified in any way, such as by removing
  1082.    the copyright notice or references to the Internet Society or other
  1083.    Internet organizations, except as needed for the purpose of
  1084.    developing Internet standards in which case the procedures for
  1085.    copyrights defined in the Internet Standards process must be
  1086.    followed, or as required to translate it into languages other than
  1087.    English.
  1088.  
  1089.    The limited permissions granted above are perpetual and will not be
  1090.    revoked by the Internet Society or its successors or assigns.
  1091.  
  1092.    This document and the information contained herein is provided on an
  1093.    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  1094.    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  1095.    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  1096.    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  1097.    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  1098.  
  1099.  
  1100.  
  1101.  
  1102.  
  1103.  
  1104.  
  1105.  
  1106.  
  1107.  
  1108.  
  1109.  
  1110.  
  1111.  
  1112.  
  1113.  
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122. Zorn & Cobb                  Informational                     [Page 20]
  1123.  
  1124.