home *** CD-ROM | disk | FTP | other *** search
/ Internet Core Protocols / Oreilly-InternetCoreProtocols.iso / RFCs / rfc2548.txt < prev    next >
Encoding:
Text File  |  1999-10-14  |  81.1 KB  |  2,300 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                            G. Zorn
  8. Request for Comments: 2548                         Microsoft Corporation
  9. Category: Informational                                       March 1999
  10.  
  11.  
  12.               Microsoft Vendor-specific RADIUS Attributes
  13.  
  14. Status of this Memo
  15.  
  16.    This memo provides information for the Internet community.  It does
  17.    not specify an Internet standard of any kind.  Distribution of this
  18.    memo is unlimited.
  19.  
  20. Copyright Notice
  21.  
  22.    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  23.  
  24. Abstract
  25.  
  26.    This document describes the set of Microsoft vendor-specific RADIUS
  27.    attributes.  These attributes are designed to support Microsoft
  28.    proprietary dial-up protocols and/or provide support for features
  29.    which is not provided by the standard RADIUS attribute set [3].  It
  30.    is expected that this memo will be updated whenever Microsoft defines
  31.    a new vendor-specific attribute, since its primary purpose is to
  32.    provide an open, easily accessible reference for third-parties
  33.    wishing to interoperate with Microsoft products.
  34.  
  35. 1.  Specification of Requirements
  36.  
  37.    In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
  38.    "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as
  39.    described in [2].
  40.  
  41. 2.  Attributes
  42.  
  43.    The following sections describe sub-attributes which may be
  44.    transmitted in one or more RADIUS attributes of type Vendor-Specific
  45.    [3].  More than one sub-attribute MAY be transmitted in a single
  46.    Vendor-Specific Attribute; if this is done, the sub-attributes SHOULD
  47.    be packed as a sequence of Vendor-Type/Vendor-Length/Value triples
  48.    following the inital Type, Length and Vendor-ID fields.  The Length
  49.    field of the Vendor-Specific Attribute MUST be set equal to the sum
  50.    of the Vendor-Length fields of the sub-attributes contained in the
  51.    Vendor-Specific Attribute, plus six.  The Vendor-ID field of the
  52.    Vendor-Specific Attribute(s) MUST be set to decimal 311 (Microsoft).
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Zorn                         Informational                      [Page 1]
  59.  
  60. RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
  61.  
  62.  
  63. 2.1.  Attributes for Support of MS-CHAP Version 1
  64.  
  65. 2.1.1.  Introduction
  66.  
  67.    Microsoft created Microsoft Challenge-Handshake Authentication
  68.    Protocol (MS-CHAP) [4] to authenticate remote Windows workstations,
  69.    providing the functionality to which LAN-based users are accustomed.
  70.    Where possible, MS-CHAP is consistent with standard CHAP [5], and the
  71.    differences are easily modularized.  Briefly, the differences between
  72.    MS-CHAP and standard CHAP are:
  73.  
  74.       * MS-CHAP is enabled by negotiating CHAP Algorithm 0x80 in LCP
  75.         option 3, Authentication Protocol.
  76.  
  77.       * The MS-CHAP Response packet is in a format designed for
  78.         compatibility with Microsoft Windows NT 3.5, 3.51 and 4.0,
  79.         Microsoft Windows95, and Microsoft LAN Manager 2.x networking
  80.         products.  The MS-CHAP format does not require the authenticator
  81.         to store a clear-text or reversibly encrypted password.
  82.  
  83.       * MS-CHAP provides an authenticator-controlled authentication
  84.         retry mechanism.
  85.  
  86.       * MS-CHAP provides an authenticator-controlled password changing
  87.         mechanism.
  88.  
  89.       * MS-CHAP defines an extended  set of reason-for-failure codes,
  90.         returned in the Failure packet Message field.
  91.  
  92.    The attributes defined in this section reflect these differences.
  93.  
  94. 2.1.2.  MS-CHAP-Challenge
  95.  
  96.    Description
  97.  
  98.       This Attribute contains the challenge sent by a NAS to a Microsoft
  99.       Challenge-Handshake Authentication Protocol (MS-CHAP) user.  It
  100.       MAY be used in both Access-Request and Access-Challenge packets.
  101.  
  102.    A summary of the MS-CHAP-Challenge Attribute format is shown below.
  103.    The fields are transmitted from left to right.
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Zorn                         Informational                      [Page 2]
  115.  
  116. RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
  117.  
  118.  
  119.     0                   1                   2                   3
  120.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  121.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  122.    |  Vendor-Type  | Vendor-Length |           String...
  123.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  124.  
  125.    Vendor-Type
  126.       11 for MS-CHAP-Challenge.
  127.  
  128.    Vendor-Length
  129.       > 2
  130.  
  131.    String
  132.       The String field contains the MS-CHAP challenge.
  133.  
  134. 2.1.3.  MS-CHAP-Response
  135.  
  136.    Description
  137.  
  138.       This Attribute contains the response value provided by a PPP
  139.       Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP)
  140.       user in response to the challenge.  It is only used in Access-
  141.       Request packets.
  142.  
  143.    A summary of the MS-CHAP-Response Attribute format is shown below.
  144.    The fields are transmitted from left to right.
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Zorn                         Informational                      [Page 3]
  171.  
  172. RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
  173.  
  174.  
  175.     0                   1                   2                   3
  176.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  177.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  178.    |  Vendor-Type  | Vendor-Length |     Ident     |     Flags     |
  179.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  180.    |                            LM-Response
  181.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  182.                              LM-Response (cont)
  183.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  184.                              LM-Response (cont)
  185.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  186.                              LM-Response (cont)
  187.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  188.                              LM-Response (cont)
  189.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  190.                              LM-Response(cont)                     |
  191.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  192.    |                           NT-Response
  193.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  194.                              NT-Response (cont)
  195.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  196.                              NT-Response (cont)
  197.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  198.                              NT-Response (cont)
  199.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  200.                              NT-Response (cont)
  201.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  202.                              NT-Response (cont)                    |
  203.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  204.  
  205.    Vendor-Type
  206.       1 for MS-CHAP-Response.
  207.  
  208.    Vendor-Length
  209.       52
  210.  
  211.    Ident
  212.       Identical to the PPP CHAP Identifier.
  213.  
  214.    Flags
  215.       The Flags field is one octet in length.  If the Flags field is one
  216.       (0x01), the NT-Response field is to be used in preference to the
  217.       LM-Response field for authentication.  The LM-Response field MAY
  218.       still be used (if non-empty), but the NT-Response SHOULD be tried
  219.       first.  If it is zero, the NT-Response field MUST be ignored and
  220.       the LM-Response field used.
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Zorn                         Informational                      [Page 4]
  227.  
  228. RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
  229.  
  230.  
  231.    LM-Response
  232.       The LM-Response field is 24 octets in length and holds an encoded
  233.       function of the password and the received challenge.  If this
  234.       field is empty, it SHOULD be zero-filled.
  235.  
  236.    NT-Response
  237.  
  238.       The NT-Response field is 24 octets in length and holds an encoded
  239.       function of the password and the received challenge.  If this
  240.       field is empty, it SHOULD be zero-filled.
  241.  
  242. 2.1.4.  MS-CHAP-Domain
  243.  
  244.    Description
  245.  
  246.       The MS-CHAP-Domain Attribute indicates the Windows NT domain in
  247.       which the user was authenticated.  It MAY be included in both
  248.       Access-Accept and Accounting-Request packets.
  249.  
  250.    A summary of the MS-CHAP-Domain Attribute format is given below.  The
  251.    fields are transmitted left to right.
  252.  
  253.     0                   1                   2                   3
  254.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  255.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  256.    |  Vendor-Type  | Vendor-Length |     Ident     |    String...
  257.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  258.  
  259.    Vendor-Type
  260.       10 for MS-CHAP-Domain.
  261.  
  262.    Vendor-Length
  263.       > 3
  264.  
  265.    Ident
  266.       The Ident field is one octet and aids in matching requests and
  267.       replies.
  268.  
  269.    String
  270.       This  field contains the name in ASCII of the Windows NT domain in
  271.       which the user was authenticated.
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Zorn                         Informational                      [Page 5]
  283.  
  284. RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
  285.  
  286.  
  287. 2.1.5.  MS-CHAP-Error
  288.  
  289.    Description
  290.  
  291.       The MS-CHAP-Error Attribute contains error data related to the
  292.       preceding MS-CHAP exchange.  This Attribute may be used in both
  293.       MS-CHAP-V1 and MS-CHAP-V2 (see below) exchanges.  It is only used
  294.       in Access-Reject packets.
  295.  
  296.    A summary of the MS-CHAP-Error Attribute format is given below.  The
  297.    fields are transmitted left to right.
  298.  
  299.     0                   1                   2                   3
  300.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  301.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  302.    |  Vendor-Type  | Vendor-Length |     Ident     |    String...
  303.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  304.  
  305.    Vendor-Type
  306.       2 for MS-CHAP-Error.
  307.  
  308.    Vendor-Length
  309.       > 3
  310.  
  311.    Ident
  312.       The Ident field is one octet and aids in matching requests and
  313.       replies.
  314.  
  315.    String
  316.       This field contains specially formatted ASCII text, which is
  317.       interpreted by the authenticating peer.
  318.  
  319. 2.1.6.  MS-CHAP-CPW-1
  320.  
  321.    Description
  322.  
  323.       This Attribute allows the user to change their password if it has
  324.       expired.  This Attribute is only used in Access-Request packets, and
  325.       should only be included if an MS-CHAP-Error attribute was included in
  326.       the immediately preceding Access-Reject packet, the String field of
  327.       the MS-CHAP-Error attribute indicated that the user password had
  328.       expired, and the MS-CHAP version is less than 2.
  329.  
  330.    A summary of the MS-CHAP-CPW-1  Attribute format is shown below.  The
  331.    fields are transmitted from left to right.
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Zorn                         Informational                      [Page 6]
  339.  
  340. RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
  341.  
  342.  
  343.     0                   1                   2                   3
  344.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  345.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  346.    |  Vendor-Type  | Vendor-Length |     Code      |     Ident     |
  347.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  348.    |                       LM-Old-Password
  349.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  350.                          LM-Old-Password (cont)
  351.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  352.                          LM-Old-Password (cont)
  353.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  354.                          LM-Old-Password (cont)                    |
  355.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  356.    |                       LM-New-Password
  357.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  358.                          LM-New-Password (cont)
  359.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  360.                          LM-New-Password (cont)
  361.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  362.                          LM-New-Password (cont)                    |
  363.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  364.    |                       NT-Old-Password
  365.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  366.                          NT-Old-Password (cont)
  367.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  368.                          NT-Old-Password (cont)
  369.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  370.                          NT-Old-Password (cont)                    |
  371.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  372.    |                       NT-New-Password
  373.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  374.                          NT-New-Password (cont)
  375.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  376.                          NT-New-Password (cont)
  377.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  378.                          NT-New-Password (cont)                    |
  379.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  380.    |     New-LM-Password-Length    |             Flags             |
  381.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  382.  
  383.    Vendor-Type
  384.       3 for MS-CHAP-PW-1
  385.  
  386.    Vendor-Length
  387.       72
  388.  
  389.    Code
  390.       The Code field is one octet in length.  Its value is always 5.
  391.  
  392.  
  393.  
  394. Zorn                         Informational                      [Page 7]
  395.  
  396. RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
  397.  
  398.  
  399.    Ident
  400.       The  Ident  field  is  one octet and aids in matching requests and
  401.       replies.
  402.  
  403.    LM-Old-Password
  404.       The LM-Old-Password field is 16 octets in length.  It contains the
  405.       encrypted Lan Manager hash of the old password.
  406.  
  407.    LM-New-Password
  408.       The LM-New-Password field is 16 octets in length.  It contains the
  409.       encrypted Lan Manager hash of the new password.
  410.  
  411.    NT-Old-Password
  412.       The NT-Old-Password field is 16 octets in length.  It contains the
  413.       encrypted Lan Manager hash of the old password.
  414.  
  415.    NT-New-Password
  416.       The NT-New-Password field is 16 octets in length.  It contains the
  417.       encrypted Lan Manager hash of the new password.
  418.  
  419.    New-LM-Password-Length
  420.       The New-LM-Password-Length field is two octets in length and
  421.       contains the length in octets of the new LAN Manager-compatible
  422.       password.
  423.  
  424.    Flags
  425.       The Flags field is two octets in length.  If the least significant
  426.       bit  of  the  Flags  field is one, this indicates that the NT-New-
  427.       Password and NT-Old-Password fields are valid and SHOULD be  used.
  428.       Otherwise,  the LM-New-Password and LM-Old-Password fields MUST be
  429.       used.
  430.  
  431. 2.1.7.  MS-CHAP-CPW-2
  432.  
  433.    Description
  434.  
  435.       This Attribute allows the user to change their password if it has
  436.       expired.  This Attribute is only used in Access-Request packets,
  437.       and should only be included if an MS-CHAP-Error attribute was
  438.       included in the immediately preceding Access-Reject packet, the
  439.       String field of the MS-CHAP-Error attribute indicated that the
  440.       user password had expired, and the MS-CHAP version is equal to 2.
  441.  
  442.    A summary of the MS-CHAP-CPW-2  Attribute format is shown below.  The
  443.    fields are transmitted from left to right.
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Zorn                         Informational                      [Page 8]
  451.  
  452. RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
  453.  
  454.  
  455.     0                   1                   2                   3
  456.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  457.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  458.    |  Vendor-Type  | Vendor-Length |     Code      |     Ident     |
  459.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  460.    |                         Old-NT-Hash
  461.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  462.                           Old-NT-Hash (cont)
  463.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  464.                           Old-NT-Hash (cont)
  465.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  466.                           Old-NT-Hash (cont)                       |
  467.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  468.    |                         Old-LM-Hash
  469.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  470.                           Old-LM-Hash(cont)
  471.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  472.                           Old-LM-Hash(cont)
  473.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  474.                           Old-LM-Hash(cont)                      |
  475.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  476.    |                         LM-Response
  477.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  478.                            LM-Response (cont)
  479.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  480.                            LM-Response (cont)
  481.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  482.                            LM-Response (cont)
  483.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  484.                            LM-Response (cont)
  485.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  486.                            LM-Response (cont)                      |
  487.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  488.    |                          NT-Response
  489.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--++-+-+-+-+-+-+-+-+-+-+-+-+
  490.                            NT-Response (cont)
  491.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--++-+-+-+-+-+-+-+-+-+-+-+
  492.                            NT-Response (cont)
  493.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  494.                            NT-Response (cont)
  495.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  496.                            NT-Response (cont)
  497.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  498.                            NT-Response (cont)                      |
  499.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  500.    |             Flags             |
  501.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  502.  
  503.  
  504.  
  505.  
  506. Zorn                         Informational                      [Page 9]
  507.  
  508. RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
  509.  
  510.  
  511.    Vendor-Type
  512.       4 for MS-CHAP-PW-2
  513.  
  514.    Vendor-Length
  515.       86
  516.  
  517.    Code
  518.       6
  519.  
  520.    Ident
  521.       The Ident field is one octet and aids in matching requests and
  522.       replies.  The value of this field MUST be identical to that in the
  523.       Ident field in all instances of the MS-CHAP-LM-Enc-PW, MS-CHAP-NT-
  524.       Enc-PW and MS-CHAP-PW-2 attributes contained in a single Access-
  525.       Request packet.
  526.  
  527.    Old-NT-Hash
  528.       The Old-NT-Hash field is 16 octets in length.  It contains the old
  529.       Windows NT password hash encrypted with the new Windows NT
  530.       password hash.
  531.  
  532.    Old-LM-Hash
  533.       The Old-LM-Hash field is 16 octets in length.  It contains the old
  534.       Lan Manager password hash encrypted with the new Windows NT
  535.       password hash.
  536.  
  537.    LM-Response
  538.       The LM-Response field is 24 octets in length and holds an encoded
  539.       function of the password and the received challenge.  If this
  540.       field is empty, it SHOULD be zero-filled.
  541.  
  542.    NT-Response
  543.       The NT-Response field is 24 octets in length and holds an encoded
  544.       function of the password and the received challenge.  If this
  545.       field is empty, it SHOULD be zero-filled.
  546.  
  547.    Flags
  548.       The Flags field is two octets in length.  If the least significant
  549.       bit (bit 0) of this field is one, the NT-Response field is to be
  550.       used in preference to the LM-Response field for authentication.
  551.       The LM-Response field MAY still be used (if present), but the NT-
  552.       Response SHOULD be tried first.  If least significant bit of the
  553.       field is zero, the NT-Response field MUST be ignored and the LM-
  554.       Response field used instead.  If bit 1 of the Flags field is one,
  555.       the Old-LM-Hash field is valid and SHOULD be used.  If this bit is
  556.       set, at least one instance of the MS-CHAP-LM-Enc-PW attribute MUST
  557.       be included in the packet.
  558.  
  559.  
  560.  
  561.  
  562. Zorn                         Informational                     [Page 10]
  563.  
  564. RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
  565.  
  566.  
  567. 2.1.8.  MS-CHAP-LM-Enc-PW
  568.  
  569.    Description
  570.  
  571.       This Attribute contains the new Windows NT password encrypted with
  572.       the old LAN Manager password hash.  The encrypted Windows NT
  573.       password is 516 octets in length; since this is longer than the
  574.       maximum lengtth of a RADIUS attribute, the password must be split
  575.       into several attibutes for transmission.  A 2 octet sequence
  576.       number is included in the attribute to help preserve ordering of
  577.       the password fragments.
  578.  
  579.       This Attribute is only used in Access-Request packets, in
  580.       conjunction with the MS-CHAP-CPW-2 attribute.  It should only be
  581.       included if an MS-CHAP-Error attribute was included in the
  582.       immediately preceding Access-Reject packet, the String field of
  583.       the MS-CHAP-Error attribute indicated that the user password had
  584.       expired, and the MS-CHAP version is 2 or greater.
  585.  
  586.    A summary of the MS-CHAP-LM-Enc-PW Attribute format is shown below.
  587.    The fields are transmitted from left to right.
  588.  
  589.     0                   1                   2                   3
  590.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  591.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  592.    |  Vendor-Type  | Vendor-Length |      Code     |     Ident     |
  593.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  594.    |       Sequence-Number         |          String ...
  595.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  596.  
  597.    Vendor-Type
  598.       5 for MS-CHAP-LM-Enc-PW
  599.  
  600.    Vendor-Length
  601.       > 6
  602.  
  603.    Code 6.  Code is the same as for the MS-CHAP-PW-2 attribute.
  604.  
  605.    Ident
  606.       The Ident field is one octet and aids in matching requests and
  607.       replies.  The value of this field MUST be identical in all
  608.       instances of the MS-CHAP-LM-Enc-PW, MS-CHAP-NT-Enc-PW and MS-
  609.       CHAP-PW-2 attributes which are present in the same Access-Request
  610.       packet.
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Zorn                         Informational                     [Page 11]
  619.  
  620. RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
  621.  
  622.  
  623.    Sequence-Number
  624.       The Sequence-Number field is two octets in length and indicates
  625.       which "chunk" of the encrypted password is contained in the
  626.       following String field.
  627.  
  628.    String The String field contains a portion of the encrypted password.
  629.  
  630. 2.2.  MS-CHAP-NT-Enc-PW
  631.  
  632.    Description
  633.  
  634.       This Attribute contains the new Windows NT password encrypted with
  635.       the old Windows NT password hash.  The encrypted Windows NT
  636.       password is 516 octets in length; since this is longer than the
  637.       maximum lengtth of a RADIUS attribute, the password must be split
  638.       into several attibutes for transmission.  A 2 octet sequence
  639.       number is included in the attribute to help preserve ordering of
  640.       the password fragments.
  641.  
  642.       This Attribute is only used in Access-Request packets, in conjunc-
  643.       tion with the MS-CHAP-CPW-2 and MS-CHAP2-CPW attributes.  It
  644.       should only be included if an MS-CHAP-Error attribute was included
  645.       in the immediately preceding Access-Reject packet, the String
  646.       field of the MS-CHAP-Error attribute indicated that the user
  647.       password had expired, and the MS-CHAP version is 2 or greater.
  648.  
  649.    A summary of the MS-CHAP-NT-Enc-PW Attribute format is shown below.
  650.    The fields are transmitted from left to right.
  651.  
  652.     0                   1                   2                   3
  653.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  654.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  655.    |  Vendor-Type  | Vendor-Length |      Code     |     Ident     |
  656.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  657.    |        Sequence-Number        |           String ...
  658.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  659.  
  660.    Vendor-Type
  661.       6 for MS-CHAP-NT-Enc-PW
  662.  
  663.    Vendor-Length
  664.       > 6
  665.  
  666.    Code
  667.       6.  Code is the same as for the MS-CHAP-PW-2 attribute.
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Zorn                         Informational                     [Page 12]
  675.  
  676. RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
  677.  
  678.  
  679.    Ident
  680.       The Ident field is one octet and aids in matching requests and
  681.       replies.  The value of this field MUST be identical in all
  682.       instances of the MS-CHAP-LM-Enc-PW, MS-CHAP-NT-Enc-PW and MS-
  683.       CHAP-PW-2 attributes which are present in the same Access-Request
  684.       packet.
  685.  
  686.    Sequence-Number
  687.       The Sequence-Number field is two octets in length and indicates
  688.       which "chunk" of the encrypted password is contained in the
  689.       following String field.
  690.  
  691.    String
  692.       The String field contains a portion of the encrypted password.
  693.  
  694. 2.3.  Attributes for Support of MS-CHAP Version 2
  695.  
  696. 2.3.1.  Introduction
  697.  
  698.    This section describes RADIUS attributes supporting version two of
  699.    Microsoft's PPP CHAP dialect (MS-CHAP-V2) [14].  MS-CHAP-V2 is
  700.    similar to, but incompatible with, MS-CHAP version one (MS-CHAP-V1)
  701.    [4].  Certain protocol fields have been deleted or reused but with
  702.    different semantics.  Where possible, MS-CHAP-V2 is consistent with
  703.    both MS-CHAP-V1 and standard CHAP [1].  Briefly, the differences
  704.    between MS-CHAP-V2 and MS-CHAP-V1 are:
  705.  
  706.       * MS-CHAP-V2 is enabled by negotiating CHAP Algorithm 0x81 in LCP
  707.         option 3, Authentication Protocol.
  708.  
  709.       * MS-CHAP-V2 provides mutual authentication between peers by
  710.         piggybacking a peer challenge on the Response packet and an
  711.         authenticator response on the Success packet.
  712.  
  713.       * The calculation of the "Windows NT compatible challenge
  714.         response" sub-field in the Response packet has been changed to
  715.         include the peer challenge and the user name.
  716.  
  717.       * In MS-CHAP-V1, the "LAN Manager compatible challenge response"
  718.         sub-field was always sent in the Response packet.  This field
  719.         has been replaced in MS-CHAP-V2 by the Peer-Challenge field.
  720.  
  721.       * The format of the Message field in the Failure packet has been
  722.         changed.
  723.  
  724.       * The Change Password (version 1) and Change Password (version 2)
  725.         packets are no longer supported. They have been replaced with a
  726.         single Change-Password packet.
  727.  
  728.  
  729.  
  730. Zorn                         Informational                     [Page 13]
  731.  
  732. RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
  733.  
  734.  
  735.    The attributes defined in this section reflect these differences.
  736.  
  737. 2.3.2.  MS-CHAP2-Response
  738.  
  739.    Description
  740.  
  741.       This Attribute contains the response value provided by an MS-
  742.       CHAP-V2 peer in response to the challenge.  It is only used in
  743.       Access-Request packets.
  744.  
  745.    A summary of the MS-CHAP2-Response Attribute format is shown below.
  746.    The fields are transmitted from left to right.
  747.  
  748.     0                   1                   2                   3
  749.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  750.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  751.    |  Vendor-Type  | Vendor-Length |     Ident     |     Flags     |
  752.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  753.    |                           Peer-Challenge
  754.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  755.                             Peer-Challenge (cont)
  756.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  757.                             Peer-Challenge (cont)
  758.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  759.                             Peer-Challenge (cont)                  |
  760.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  761.    |                             Reserved
  762.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  763.                                Reserved (cont)                     |
  764.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  765.    |                             Response
  766.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  767.                                Response (cont)
  768.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  769.                                Response (cont)
  770.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  771.                                Response (cont)
  772.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  773.                                Response (cont)
  774.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  775.                                Response (cont)                     |
  776.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  777.  
  778.    Vendor-Type
  779.       25 for MS-CHAP2-Response.
  780.  
  781.    Vendor-Length
  782.       52
  783.  
  784.  
  785.  
  786. Zorn                         Informational                     [Page 14]
  787.  
  788. RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
  789.  
  790.  
  791.    Ident
  792.       Identical to the PPP MS-CHAP v2 Identifier.
  793.  
  794.    Flags
  795.       The Flags field is one octet in length.  It is reserved for future
  796.       use and MUST be zero.
  797.  
  798.    Peer-Challenge
  799.       The Peer-Challenge field is a 16-octet random number.
  800.  
  801.    Reserved
  802.       This field is reserved for future use and MUST be zero.
  803.  
  804.    Response
  805.       The Response field is 24 octets in length and holds an encoded
  806.       function of the password, the Peer-Challenge field and the
  807.       received challenge.
  808.  
  809. 2.3.3.  MS-CHAP2-Success
  810.  
  811.    Description
  812.  
  813.       This Attribute contains a 42-octet authenticator response string.
  814.       This string MUST be included in the Message field of the MS-CHAP-
  815.       V2 Success packet sent from the NAS to the peer.  This Attribute
  816.       is only used in Access-Accept packets.
  817.  
  818.    A summary of the MS-CHAP2-Success Attribute format is shown below.
  819.    The fields are transmitted from left to right.
  820.  
  821.     0                   1                   2                   3
  822.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  823.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  824.    |  Vendor-Type  | Vendor-Length |     Ident     |   String...
  825.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  826.  
  827.    Vendor-Type
  828.       26 for MS-CHAP2-Success.
  829.  
  830.    Vendor-Length
  831.       45
  832.  
  833.    Ident
  834.       Identical to the PPP MS-CHAP v2 Identifier.
  835.  
  836.    String
  837.       The 42-octet authenticator string (see above).
  838.  
  839.  
  840.  
  841.  
  842. Zorn                         Informational                     [Page 15]
  843.  
  844. RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
  845.  
  846.  
  847. 2.3.4.  MS-CHAP2-CPW
  848.  
  849.    Description
  850.  
  851.       This Attribute allows the user to change their password if it has
  852.       expired.  This Attribute is only used in conjunction with the MS-
  853.       CHAP-NT-Enc-PW attribute in Access-Request packets, and should
  854.       only be included if an MS-CHAP-Error attribute was included in the
  855.       immediately preceding Access-Reject packet, the String field of
  856.       the MS-CHAP-Error attribute indicated that the user password had
  857.       expired, and the MS-CHAP version is equal to 3.
  858.  
  859.    A summary of the MS-CHAP-CPW-2 Attribute format is shown below.   The
  860.    fields are transmitted from left to right.
  861.  
  862.  
  863.  
  864.  
  865.  
  866.  
  867.  
  868.  
  869.  
  870.  
  871.  
  872.  
  873.  
  874.  
  875.  
  876.  
  877.  
  878.  
  879.  
  880.  
  881.  
  882.  
  883.  
  884.  
  885.  
  886.  
  887.  
  888.  
  889.  
  890.  
  891.  
  892.  
  893.  
  894.  
  895.  
  896.  
  897.  
  898. Zorn                         Informational                     [Page 16]
  899.  
  900. RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
  901.  
  902.  
  903.     0                   1                   2                   3
  904.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  905.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  906.    |  Vendor-Type  | Vendor-Length |     Code      |     Ident     |
  907.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  908.    |                         Encrypted-Hash
  909.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  910.                           Encrypted-Hash (cont)
  911.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  912.                           Encrypted-Hash (cont)
  913.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  914.                           Encrypted-Hash (cont)                    |
  915.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  916.    |                         Peer-Challenge
  917.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  918.                           Peer-Challenge (cont)
  919.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  920.                           Peer-Challenge (cont)
  921.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  922.                           Peer-Challenge (cont)
  923.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  924.                           Peer-Challenge (cont)
  925.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  926.                           Peer-Challenge (cont)                    |
  927.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  928.    |                          NT-Response
  929.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--++-+-+-+-+-+-+-+-+-+-+-+-+
  930.                            NT-Response (cont)
  931.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--++-+-+-+-+-+-+-+-+-+-+-+
  932.                            NT-Response (cont)
  933.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  934.                            NT-Response (cont)
  935.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  936.                            NT-Response (cont)
  937.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  938.                            NT-Response (cont)                      |
  939.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  940.    |             Flags             |
  941.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  942.  
  943.    Vendor-Type
  944.       27 for MS-CHAP2-PW
  945.  
  946.    Vendor-Length
  947.       70
  948.  
  949.    Code
  950.       7
  951.  
  952.  
  953.  
  954. Zorn                         Informational                     [Page 17]
  955.  
  956. RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
  957.  
  958.  
  959.    Ident
  960.       The Ident field is one octet and aids in matching requests and
  961.       replies.  The value of this field MUST be identical to that in the
  962.       Ident field in all instances of the MS-CHAP-NT-Enc-PW contained in
  963.       the Access-Request packet.
  964.  
  965.    Encrypted-Hash
  966.       The Encrypted-Hash field is 16 octets in length.  It contains the
  967.       old Windows NT password hash encrypted with the new Windows NT
  968.       password hash.
  969.  
  970.    NT-Response
  971.       The NT-Response field is 24 octets in length and holds an encoded
  972.       function of the new password, the Peer-Challenge field and the
  973.       received challenge.
  974.  
  975.    Flags
  976.       The Flags field is two octets in length.  This field is reserved
  977.       for future use and MUST be zero.
  978.  
  979. 2.4.  Attributes for MPPE Support
  980.  
  981.    This section describes a set of Attributes designed to support the
  982.    use of Microsoft Point-to-Point Encryption (MPPE) [6] in dial-up
  983.    networks.  MPPE is a means of representing Point to Point Protocol
  984.    (PPP) [7] packets in a encrypted form.  MPPE uses the RSA RC4 [8]
  985.    algorithm for encryption.  The length of the session key to be used
  986.    for initializing encryption tables can be negotiated; MPPE currently
  987.    supports 40 bit and 128 bit session keys.  MPPE is negotiated within
  988.    option 18 in the PPP Compression Control Protocol (CCP)[9], [10].
  989.  
  990. 2.4.1.  MS-CHAP-MPPE-Keys
  991.  
  992.    Description
  993.  
  994.       The MS-CHAP-MPPE-Keys Attribute contains two session keys for use
  995.       by the Microsoft Point-to-Point Encryption Protocol (MPPE).  This
  996.       Attribute is only included in Access-Accept packets.
  997.  
  998.    A summary of the MS-CHAP-MPPE-Keys Attribute format is given below.
  999.    The fields are transmitted left to right.
  1000.  
  1001.  
  1002.  
  1003.  
  1004.  
  1005.  
  1006.  
  1007.  
  1008.  
  1009.  
  1010. Zorn                         Informational                     [Page 18]
  1011.  
  1012. RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
  1013.  
  1014.  
  1015.     0                   1                   2                   3
  1016.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1017.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1018.    |  Vendor-Type  | Vendor-Length |           Keys
  1019.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1020.                              Keys (cont)
  1021.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1022.                              Keys (cont)
  1023.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1024.                              Keys (cont)
  1025.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1026.                              Keys (cont)
  1027.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1028.                              Keys (cont)
  1029.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1030.                              Keys (cont)
  1031.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1032.                              Keys (cont)
  1033.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1034.               Keys (cont)          |
  1035.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1036.  
  1037.    Vendor-Type
  1038.       12 for MS-CHAP-MPPE-Keys.
  1039.  
  1040.    Vendor-Length
  1041.       34
  1042.  
  1043.    Keys
  1044.       The Keys field consists of two logical sub-fields: the LM-Key and
  1045.       the NT-Key.  The LM-Key is eight octets in length and contains the
  1046.       first eight bytes of the output of the function LmPasswordHash(P,
  1047.       This hash is constructed as follows: let the plain-text password
  1048.       be represented by P.
  1049.  
  1050.       The NT-Key sub-field is sixteen octets in length and contains the
  1051.       first sixteen octets of the hashed Windows NT password.  The
  1052.       format of the plaintext Keys field is illustrated in the following
  1053.       diagram:
  1054.  
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060.  
  1061.  
  1062.  
  1063.  
  1064.  
  1065.  
  1066. Zorn                         Informational                     [Page 19]
  1067.  
  1068. RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
  1069.  
  1070.  
  1071.       0                   1                   2                   3
  1072.       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1073.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1074.       |                           LM-Key
  1075.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1076.                                LM-Key (cont)                        |
  1077.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1078.       |                           NT-Key
  1079.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1080.                                NT-Key (cont)
  1081.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1082.                                NT-Key (cont)
  1083.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1084.                                NT-Key (cont)                        |
  1085.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1086.       |                          Padding
  1087.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1088.                               Padding (cont)                        |
  1089.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1090.  
  1091.       The Keys field MUST be encrypted by the RADIUS server using the
  1092.       same method defined for the User-Password Attribute [3].  Padding
  1093.       is required because the method referenced above requires the field
  1094.       to be encrypted to be a multiple of sixteen octets in length.
  1095.  
  1096.    Implementation Note
  1097.          This attribute should only be returned in response to an
  1098.          Access-Request packet containing MS-CHAP attributes.
  1099.  
  1100. 2.4.2.  MS-MPPE-Send-Key
  1101.  
  1102.    Description
  1103.  
  1104.       The MS-MPPE-Send-Key Attribute contains a session key for use by
  1105.       the Microsoft Point-to-Point Encryption Protocol (MPPE).  As the
  1106.       name implies, this key is intended for encrypting packets sent
  1107.       from the NAS to the remote host.  This Attribute is only included
  1108.       in Access-Accept packets.
  1109.  
  1110.    A summary of the MS-MPPE-Send-Key Attribute format is given below.
  1111.    The fields are transmitted left to right.
  1112.  
  1113.  
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122. Zorn                         Informational                     [Page 20]
  1123.  
  1124. RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
  1125.  
  1126.  
  1127.     0                   1                   2                   3
  1128.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1129.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1130.    |  Vendor-Type  | Vendor-Length |             Salt
  1131.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1132.                                String...
  1133.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1134.  
  1135.    Vendor-Type
  1136.       16 for MS-MPPE-Send-Key.
  1137.  
  1138.    Vendor-Length
  1139.       > 4
  1140.  
  1141.    Salt
  1142.       The Salt field is two octets in length and is used to ensure the
  1143.       uniqueness of the keys used to encrypt each of the encrypted
  1144.       attributes occurring in a given Access-Accept packet.  The most
  1145.       significant bit (leftmost) of the Salt field MUST be set (1).  The
  1146.       contents of each Salt field in a given Access-Accept packet MUST
  1147.       be unique.
  1148.  
  1149.    String
  1150.       The plaintext String field consists of three logical sub-fields:
  1151.       the Key-Length and Key sub-fields (both of which are required),
  1152.       and the optional Padding sub-field.  The Key-Length sub-field is
  1153.       one octet in length and contains the length of the unencrypted Key
  1154.       sub-field.  The Key sub-field contains the actual encryption key.
  1155.       If the combined length (in octets) of the unencrypted Key-Length
  1156.       and Key sub-fields is not an even multiple of 16, then the Padding
  1157.       sub-field MUST be present.  If it is present, the length of the
  1158.       Padding sub-field is variable, between 1 and 15 octets.  The
  1159.       String field MUST be encrypted as follows, prior to transmission:
  1160.  
  1161.          Construct a plaintext version of the String field by concate-
  1162.          nating the Key-Length and Key sub-fields.  If necessary, pad
  1163.          the resulting string until its length (in octets) is an even
  1164.          multiple of 16.  It is recommended that zero octets (0x00) be
  1165.          used for padding.  Call this plaintext P.
  1166.  
  1167.          Call the shared secret S, the pseudo-random 128-bit Request
  1168.          Authenticator (from the corresponding Access-Request packet) R,
  1169.          and the contents of the Salt field A.  Break P into 16 octet
  1170.          chunks p(1), p(2)...p(i), where i = len(P)/16.  Call the
  1171.          ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C.
  1172.          Intermediate values b(1), b(2)...c(i) are required.  Encryption
  1173.          is performed in the following manner ('+' indicates
  1174.          concatenation):
  1175.  
  1176.  
  1177.  
  1178. Zorn                         Informational                     [Page 21]
  1179.  
  1180. RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
  1181.  
  1182.  
  1183.       b(1) = MD5(S + R + A)    c(1) = p(1) xor b(1)   C = c(1)
  1184.       b(2) = MD5(S + c(1))     c(2) = p(2) xor b(2)   C = C + c(2)
  1185.                   .                      .
  1186.                   .                      .
  1187.                   .                      .
  1188.       b(i) = MD5(S + c(i-1))   c(i) = p(i) xor b(i)   C = C + c(i)
  1189.  
  1190.       The   resulting   encrypted   String   field    will    contain
  1191.       c(1)+c(2)+...+c(i).
  1192.  
  1193.    On receipt, the process is reversed to yield the plaintext String.
  1194.  
  1195.    Implementation Notes
  1196.       It is possible that the length of the key returned may be larger
  1197.       than needed for the encryption scheme in use.  In this case, the
  1198.       RADIUS client is responsible for performing any necessary
  1199.       truncation.
  1200.  
  1201.       This attribute MAY be used to pass a key from an external (e.g.,
  1202.       EAP [15]) server to the RADIUS server.  In this case, it may be
  1203.       impossible for the external server to correctly encrypt the key,
  1204.       since the RADIUS shared secret might be unavailable.  The external
  1205.       server SHOULD, however, return the attribute as defined above; the
  1206.       Salt field SHOULD be zero-filled and padding of the String field
  1207.       SHOULD be done.  When the RADIUS server receives the attribute
  1208.       from the external server, it MUST correctly set the Salt field and
  1209.       encrypt the String field before transmitting it to the RADIUS
  1210.       client.  If the channel used to communicate the MS-MPPE-Send-Key
  1211.       attribute is not secure from eavesdropping, the attribute MUST be
  1212.       cryptographically protected.
  1213.  
  1214. 2.4.3.  MS-MPPE-Recv-Key
  1215.  
  1216.    Description
  1217.  
  1218.       The MS-MPPE-Recv-Key Attribute contains a session key for use by
  1219.       the Microsoft Point-to-Point Encryption Protocol (MPPE).  As the
  1220.       name implies, this key is intended for encrypting packets received
  1221.       by the NAS from the remote host.  This Attribute is only included
  1222.       in Access-Accept packets.
  1223.  
  1224.    A summary of the MS-MPPE-Recv-Key Attribute format is given below.
  1225.    The fields are transmitted left to right.
  1226.  
  1227.  
  1228.  
  1229.  
  1230.  
  1231.  
  1232.  
  1233.  
  1234. Zorn                         Informational                     [Page 22]
  1235.  
  1236. RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
  1237.  
  1238.  
  1239.     0                   1                   2                   3
  1240.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1241.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1242.    |  Vendor-Type  | Vendor-Length |             Salt
  1243.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1244.                                String...
  1245.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1246.  
  1247.    Vendor-Type
  1248.       17 for MS-MPPE-Recv-Key.
  1249.  
  1250.    Vendor-Length
  1251.       > 4
  1252.  
  1253.    Salt
  1254.       The Salt field is two octets in length and is used to ensure the
  1255.       uniqueness of the keys used to encrypt each of the encrypted
  1256.       attributes occurring in a given Access-Accept packet.  The most
  1257.       significant bit (leftmost) of the Salt field MUST be set (1).  The
  1258.       contents of each Salt field in a given Access-Accept packet MUST
  1259.       be unique.
  1260.  
  1261.    String
  1262.       The plaintext String field consists of three logical sub-fields:
  1263.       the Key-Length and Key sub-fields (both of which are required),
  1264.       and the optional Padding sub-field.  The Key-Length sub-field is
  1265.       one octet in length and contains the length of the unencrypted Key
  1266.       sub-field.  The Key sub-field contains the actual encryption key.
  1267.       If the combined length (in octets) of the unencrypted Key-Length
  1268.       and Key sub-fields is not an even multiple of 16, then the Padding
  1269.       sub-field MUST be present.  If it is present, the length of the
  1270.       Padding sub-field is variable, between 1 and 15 octets.  The
  1271.       String field MUST be encrypted as follows, prior to transmission:
  1272.  
  1273.          Construct a plaintext version of the String field by
  1274.          concatenating the Key-Length and Key sub-fields.  If necessary,
  1275.          pad the resulting string until its length (in octets) is an
  1276.          even multiple of 16.  It is recommended that zero octets (0x00)
  1277.          be used for padding.  Call this plaintext P.
  1278.  
  1279.          Call the shared secret S, the pseudo-random 128-bit Request
  1280.          Authenticator (from the corresponding Access-Request packet) R,
  1281.          and the contents of the Salt field A.  Break P into 16 octet
  1282.          chunks p(1), p(2)...p(i), where i = len(P)/16.  Call the
  1283.          ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C.
  1284.          Intermediate values b(1), b(2)...c(i) are required.  Encryption
  1285.          is performed in the following manner ('+' indicates
  1286.          concatenation):
  1287.  
  1288.  
  1289.  
  1290. Zorn                         Informational                     [Page 23]
  1291.  
  1292. RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
  1293.  
  1294.  
  1295.          b(1) = MD5(S + R + A)    c(1) = p(1) xor b(1)   C = c(1)
  1296.          b(2) = MD5(S + c(1))     c(2) = p(2) xor b(2)   C = C + c(2)
  1297.                      .                      .
  1298.                      .                      .
  1299.                      .                      .
  1300.          b(i) = MD5(S + c(i-1))   c(i) = p(i) xor b(i)   C = C + c(i)
  1301.  
  1302.          The resulting encrypted String field will contain
  1303.          c(1)+c(2)+...+c(i).
  1304.  
  1305.       On receipt, the process is reversed to yield the plaintext String.
  1306.  
  1307.    Implementation Notes
  1308.       It is possible that the length of the key returned may be larger
  1309.       than needed for the encryption scheme in use.  In this case, the
  1310.       RADIUS client is responsible for performing any necessary
  1311.       truncation.
  1312.  
  1313.       This attribute MAY be used to pass a key from an external (e.g.,
  1314.       EAP [15]) server to the RADIUS server.  In this case, it may be
  1315.       impossible for the external server to correctly encrypt the key,
  1316.       since the RADIUS shared secret might be unavailable.  The external
  1317.       server SHOULD, however, return the attribute as defined above; the
  1318.       Salt field SHOULD be zero-filled and padding of the String field
  1319.       SHOULD be done.  When the RADIUS server receives the attribute
  1320.       from the external server, it MUST correctly set the Salt field and
  1321.       encrypt the String field before transmitting it to the RADIUS
  1322.       client.  If the channel used to communicate the MS-MPPE-Recv-Key
  1323.       attribute is not secure from eavesdropping, the attribute MUST be
  1324.       cryptographically protected.
  1325.  
  1326. 2.4.4.  MS-MPPE-Encryption-Policy
  1327.  
  1328.    Description
  1329.  
  1330.       The MS-MPPE-Encryption-Policy Attribute may be used to signify
  1331.       whether the use of encryption is allowed or required.  If the
  1332.       Policy field is equal to 1 (Encryption-Allowed), any or none of
  1333.       the encryption types specified in the MS-MPPE-Encryption-Types
  1334.       Attribute MAY be used.  If the Policy field is equal to 2
  1335.       (Encryption-Required), any of the encryption types specified in
  1336.       the MS-MPPE-Encryption-Types Attribute MAY be used, but at least
  1337.       one MUST be used.
  1338.  
  1339.    A summary of the MS-MPPE-Encryption-Policy Attribute format is given
  1340.    below.  The fields are transmitted left to right.
  1341.  
  1342.  
  1343.  
  1344.  
  1345.  
  1346. Zorn                         Informational                     [Page 24]
  1347.  
  1348. RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
  1349.  
  1350.  
  1351.     0                   1                   2                   3
  1352.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1353.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1354.    |  Vendor-Type  | Vendor-Length |             Policy
  1355.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1356.               Policy (cont)        |
  1357.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1358.  
  1359.    Vendor-Type
  1360.       7 for MS-MPPE-Encryption-Policy.
  1361.  
  1362.    Vendor-Length
  1363.       6
  1364.  
  1365.    Policy
  1366.       The Policy field is 4 octets in length.  Defined values are:
  1367.  
  1368.          1      Encryption-Allowed 2      Encryption-Required
  1369.  
  1370. 2.4.5.  MS-MPPE-Encryption-Types
  1371.  
  1372.    Description
  1373.  
  1374.       The MS-MPPE-Encryption-Types Attribute is used to signify the
  1375.       types of encryption available for use with MPPE.  It is a four
  1376.       octet integer that is interpreted as a string of bits.
  1377.  
  1378.    A summary of the MS-MPPE-Encryption-Policy Attribute format is given
  1379.    below.  The fields are transmitted left to right.
  1380.  
  1381.     0                   1                   2                   3
  1382.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1383.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1384.    |  Vendor-Type  | Vendor-Length |             Types
  1385.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1386.                Types (cont)        |
  1387.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1388.  
  1389.    Vendor-Type
  1390.       8 for MS-MPPE-Encryption-Types.
  1391.  
  1392.    Vendor-Length
  1393.       6
  1394.  
  1395.    Policy
  1396.       The Types field is 4 octets in length.  The following diagram
  1397.       illustrates the Types field.
  1398.  
  1399.  
  1400.  
  1401.  
  1402. Zorn                         Informational                     [Page 25]
  1403.  
  1404. RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
  1405.  
  1406.  
  1407.          3                   2                   1
  1408.        1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
  1409.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1410.       |                                                         |S|L| |
  1411.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1412.  
  1413.       If the L bit is set, RC4[5] encryption using a 40-bit key is
  1414.       allowed.  If the S bit is set, RC4 encryption using a 128-bit key
  1415.       is allowed.  If both the L and S bits are set, then either 40- or
  1416.       128-bit keys may be used with the RC4 algorithm.
  1417.  
  1418. 2.5.  Attributes for BAP Support
  1419.  
  1420.    This section describes a set of vendor-specific RADIUS attributes
  1421.    designed to support the dynamic control of bandwidth allocation in
  1422.    multilink PPP [11].  Attributes are defined that specify whether use
  1423.    of the PPP Bandwidth Allocation Protocol (BAP) [12] is allowed or
  1424.    required on incoming calls, the level of line capacity (expressed as
  1425.    a percentage) below which utilization must fall before a link is
  1426.    eligible to be dropped, and the length of time (in seconds) that a
  1427.    link must be under-utilized before it is dropped.
  1428.  
  1429. 2.5.1.  MS-BAP-Usage
  1430.  
  1431.    Description
  1432.  
  1433.       This Attribute describes whether the use of BAP is allowed,
  1434.       disallowed or required on new multilink calls.  It MAY be used in
  1435.       Access-Accept packets.
  1436.  
  1437.    A summary of the MS-BAP-Usage Attribute format is shown below.  The
  1438.    fields are transmitted from left to right.
  1439.  
  1440.     0                   1                   2                   3
  1441.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1442.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1443.    |  Vendor-Type  | Vendor-Length |            Value
  1444.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1445.               Value (cont)         |
  1446.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1447.  
  1448.    Vendor-Type
  1449.       13 for MS-BAP-Usage.
  1450.  
  1451.    Vendor-Length
  1452.       6
  1453.  
  1454.  
  1455.  
  1456.  
  1457.  
  1458. Zorn                         Informational                     [Page 26]
  1459.  
  1460. RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
  1461.  
  1462.  
  1463.    Value
  1464.       The Value field is four octets.
  1465.  
  1466.          0      BAP usage not allowed
  1467.          1      BAP usage allowed
  1468.          2      BAP usage required
  1469.  
  1470. 2.5.2.  MS-Link-Utilization-Threshold
  1471.  
  1472.    Description
  1473.  
  1474.       This Attribute represents the percentage of available bandwidth
  1475.       utilization below which the link must fall before the link is
  1476.       eligible for termination.  Permissible values for the MS-Link-
  1477.       Utilization-Threshold Attribute are in the range 1-100, inclusive.
  1478.       It is only used in Access-Accept packets.
  1479.  
  1480.    A summary of the MS-Link-Utilization-Threshold Attribute format is
  1481.    shown below.  The fields are transmitted from left to right.
  1482.  
  1483.     0                   1                   2                   3
  1484.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1485.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1486.    |  Vendor-Type  | Vendor-Length |            Value
  1487.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1488.               Value (cont)         |
  1489.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1490.  
  1491.    Vendor-Type
  1492.       14 for MS-Link-Utilization-Threshold
  1493.  
  1494.    Vendor-Length 6
  1495.  
  1496.    Value The Value field is four octets in length and represents the
  1497.       percentage of available bandwidth utilization below which the link
  1498.       must fall before the link is eligible for termination.
  1499.       Permissible values are in the range 1-100, inclusive.
  1500.  
  1501. 2.5.3.  MS-Link-Drop-Time-Limit
  1502.  
  1503.    Description
  1504.  
  1505.       The MS-Link-Drop-Time-Limit Attribute indicates the length of time
  1506.       (in seconds) that a link must be underutilized before it is
  1507.       dropped.  It MAY only be included in Access-Accept packets.
  1508.  
  1509.    A summary of the MS-Link-Drop-Time-Limit Attribute format is given
  1510.    below.  The fields are transmitted left to right.
  1511.  
  1512.  
  1513.  
  1514. Zorn                         Informational                     [Page 27]
  1515.  
  1516. RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
  1517.  
  1518.  
  1519.     0                   1                   2                   3
  1520.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1521.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1522.    |  Vendor-Type  | Vendor-Length |             Value
  1523.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1524.              Value (cont)          |
  1525.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1526.  
  1527.    Vendor-Type
  1528.       15 for MS-Link-Drop-Time-Limit
  1529.  
  1530.    Vendor-Length
  1531.       6
  1532.  
  1533.    Value
  1534.       The Value field represents the number of seconds that a link must
  1535.       be underutilized (i.e., display bandwidth utilization below the
  1536.       threshold specified in the MS-Link-Utilization-Threshold
  1537.       Attribute) before the link is dropped.
  1538.  
  1539. 2.6.  Attributes for ARAP Support
  1540.  
  1541.    This section describes a set of Attributes designed to support the
  1542.    Apple Remote Access Protocol (ARAP).
  1543.  
  1544. 2.6.1.  MS-Old-ARAP-Password
  1545.  
  1546.    Description
  1547.  
  1548.       The MS-Old-ARAP-Password Attribute is used to transmit the old
  1549.       ARAP password during an ARAP password change operation.  It MAY be
  1550.       included in Access-Request packets.
  1551.  
  1552.    A summary of the MS-Old-ARAP-Password Attribute Attribute format is
  1553.    given below.  The fields are transmitted left to right.
  1554.  
  1555.     0                   1                   2                   3
  1556.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1557.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1558.    |  Vendor-Type  | Vendor-Length |          String...
  1559.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1560.  
  1561.    Vendor-Type
  1562.       19 for MS-Old-ARAP-Password Attribute
  1563.  
  1564.    Vendor-Length
  1565.       > 3
  1566.  
  1567.  
  1568.  
  1569.  
  1570. Zorn                         Informational                     [Page 28]
  1571.  
  1572. RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
  1573.  
  1574.  
  1575.    String
  1576.       The String field is one or more octets.  It contains the old ARAP
  1577.       password DES-encrypted using itself as the key.
  1578.  
  1579. 2.6.2.  MS-New-ARAP-Password
  1580.  
  1581.    Description
  1582.  
  1583.       The MS-New-ARAP-Password Attribute is used to transmit the new
  1584.       ARAP password during an ARAP password change operation.  It MAY be
  1585.       included in Access-Request packets.
  1586.  
  1587.    A summary of the MS-New-ARAP-Password Attribute Attribute format is
  1588.    given below.  The fields are transmitted left to right.
  1589.  
  1590.     0                   1                   2                   3
  1591.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1592.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1593.    |  Vendor-Type  | Vendor-Length |          String...
  1594.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1595.  
  1596.    Vendor-Type
  1597.       20 for MS-New-ARAP-Password Attribute
  1598.  
  1599.    Vendor-Length
  1600.       > 3
  1601.  
  1602.    String
  1603.       The  String field is one or more octets.  It contains the new ARAP
  1604.       password DES-encrypted using the old ARAP password as the key.
  1605.  
  1606. 2.6.3.  MS-ARAP-Password-Change-Reason
  1607.  
  1608.    Description
  1609.  
  1610.       The MS-ARAP-Password-Change-Reason Attribute is used to indicate
  1611.       reason for a server-initiated password change.  It MAY be included
  1612.       in Access-Challenge packets.
  1613.  
  1614.    A summary of the MS-ARAP-Password-Change-Reason Attribute format is
  1615.    given below.  The fields are transmitted left to right.
  1616.  
  1617.  
  1618.  
  1619.  
  1620.  
  1621.  
  1622.  
  1623.  
  1624.  
  1625.  
  1626. Zorn                         Informational                     [Page 29]
  1627.  
  1628. RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
  1629.  
  1630.  
  1631.     0                   1                   2                   3
  1632.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1633.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1634.    |  Vendor-Type  | Vendor-Length |             Why
  1635.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1636.                Why (cont)          |
  1637.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1638.  
  1639.    Vendor-Type
  1640.       21 for MS-ARAP-Password-Change-Reason
  1641.  
  1642.    Vendor-Length
  1643.       6
  1644.  
  1645.    Why
  1646.       The Why field is 4 octets in length.  The following values are
  1647.       defined:
  1648.          Just-Change-Password            1
  1649.          Expired-Password                2
  1650.          Admin-Requires-Password-Change  3
  1651.          Password-Too-Short              4
  1652.  
  1653. 2.6.4.  MS-ARAP-Challenge
  1654.  
  1655.    Description
  1656.  
  1657.       This attribute is only present in an Access-Request packet
  1658.       containing a Framed-Protocol Attribute with the value 3 (ARAP).
  1659.  
  1660.    A summary of the MS-ARAP-Challenge Attribute format is given below.
  1661.    The fields are transmitted left to right.
  1662.  
  1663.     0                   1                   2                   3
  1664.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1665.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1666.    |  Vendor-Type  | Vendor-Length |           Challenge
  1667.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1668.                             Challenge (cont)                       |
  1669.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1670.             Challenge (cont)       |
  1671.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1672.  
  1673.    Vendor-Type
  1674.       33 for MS-ARAP-Challenge
  1675.  
  1676.    Vendor-Length
  1677.       10
  1678.  
  1679.  
  1680.  
  1681.  
  1682. Zorn                         Informational                     [Page 30]
  1683.  
  1684. RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
  1685.  
  1686.  
  1687.    Value
  1688.       The Challenge Field is 8 octets in length.  It contains the
  1689.       challenge (as two 4-octet quantities) sent by the NAS to the peer.
  1690.  
  1691. 2.7.  Miscellaneous Attributes
  1692.  
  1693.    This section describes attributes which do not fall into any
  1694.    particular category, but are used in the identification and operation
  1695.    of Microsoft remote access products.
  1696.  
  1697. 2.7.1.  MS-RAS-Vendor
  1698.  
  1699.    Description
  1700.  
  1701.       The MS-RAS-Vendor Attribute is used to indicate the manufacturer
  1702.       of the RADIUS client machine.  It MAY be included in both Access-
  1703.       Request and Accounting-Request packets.
  1704.  
  1705.    A summary of the MS-RAS-Vendor Attribute format is given below.  The
  1706.    fields are transmitted left to right.
  1707.  
  1708.     0                   1                   2                   3
  1709.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1710.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1711.    |  Vendor-Type  | Vendor-Length |           Vendor-ID
  1712.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1713.            Vendor-ID (cont)        |
  1714.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1715.  
  1716.    Vendor-Type
  1717.       9 for MS-RAS-Vendor
  1718.  
  1719.    Vendor-Length
  1720.       6
  1721.  
  1722.    Vendor-ID
  1723.       The Vendor-ID field is 4 octets in length.  The high-order octet
  1724.       is 0 and the low-order 3 octets are the SMI Network Management
  1725.       Private Enterprise Code of the Vendor in network byte order, as
  1726.       defined in the Assigned Numbers RFC [13].
  1727.  
  1728. 2.7.2.  MS-RAS-Version
  1729.  
  1730.    Description
  1731.  
  1732.       The MS-RAS-Version Attribute is used to indicate the version of
  1733.       the RADIUS client software.  This attribute SHOULD be included in
  1734.       packets containing an MS-RAS-Vendor Attribute; it SHOULD NOT be
  1735.  
  1736.  
  1737.  
  1738. Zorn                         Informational                     [Page 31]
  1739.  
  1740. RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
  1741.  
  1742.  
  1743.       sent in packets which do not contain an MS-RAS-Vendor Attribute.
  1744.       It MAY be included in both Access-Request and Accounting-Request
  1745.       packets.
  1746.  
  1747.    A summary of the MS-RAS-Version Attribute format is given below.  The
  1748.    fields are transmitted left to right.
  1749.  
  1750.     0                   1                   2                   3
  1751.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1752.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1753.    |  Vendor-Type  | Vendor-Length |          String...
  1754.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1755.  
  1756.    Vendor-Type
  1757.       18 for MS-RAS-Version
  1758.  
  1759.    Vendor-Length
  1760.       > 3
  1761.  
  1762.    String
  1763.       The  String field is one or more octets.  The actual format of the
  1764.       information is vendor specific, and a robust implementation SHOULD
  1765.       support the field as undistinguished octets.
  1766.  
  1767. 2.7.3.  MS-Filter
  1768.  
  1769.    Description
  1770.  
  1771.       The MS-Filter Attribute is used to transmit traffic filters.  It
  1772.       MAY be included in both Access-Accept and Accounting-Request
  1773.       packets.
  1774.  
  1775.       If multiple MS-Filter Attributes are contained within a packet,
  1776.       they MUST be in order and they MUST be consecutive attributes in
  1777.       the packet.
  1778.  
  1779.    A summary of the MS-Filter Attribute format is given below.  The
  1780.    fields are transmitted left to right.
  1781.  
  1782.     0                   1                   2                   3
  1783.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1784.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1785.    |  Vendor-Type  | Vendor-Length |           Filter...
  1786.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1787.  
  1788.    Vendor-Type
  1789.       22 for MS-Filter Attribute
  1790.  
  1791.  
  1792.  
  1793.  
  1794. Zorn                         Informational                     [Page 32]
  1795.  
  1796. RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
  1797.  
  1798.  
  1799.    Vendor-Length
  1800.       > 3
  1801.  
  1802.    Filter
  1803.       The Filter field is one or more octets.  It contains a sequence of
  1804.       undifferentiated octets.
  1805.  
  1806.       If multiple MS-Filter Attributes occur in a single Access-Accept
  1807.       packet, the Filter field from each MUST be concatenated in the
  1808.       order received to form the actual filter.
  1809.  
  1810. 2.7.4.  MS-Acct-Auth-Type
  1811.  
  1812.    Description
  1813.  
  1814.       The MS-Acct-Auth-Type Attribute is used to represent the method
  1815.       used to authenticate the dial-up user.  It MAY be included in
  1816.       Accounting-Request packets.
  1817.  
  1818.    A summary of the MS-Acct-Auth-Type Attribute format is given below.
  1819.    The fields are transmitted left to right.
  1820.  
  1821.     0                   1                   2                   3
  1822.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1823.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1824.    |  Vendor-Type  | Vendor-Length |           Auth-Type
  1825.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1826.             Auth-Type (cont)       |
  1827.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1828.  
  1829.    Vendor-Type
  1830.       23 for MS-Acct-Auth-Type
  1831.  
  1832.    Vendor-Length
  1833.       6
  1834.  
  1835.    Auth-Type
  1836.       The Auth-Type field is 4 octets in length.  The following values
  1837.       are defined for this field:
  1838.  
  1839.          PAP               1
  1840.          CHAP              2
  1841.          MS-CHAP-1         3
  1842.          MS-CHAP-2         4
  1843.          EAP               5
  1844.  
  1845.  
  1846.  
  1847.  
  1848.  
  1849.  
  1850. Zorn                         Informational                     [Page 33]
  1851.  
  1852. RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
  1853.  
  1854.  
  1855. 2.7.5.  MS-Acct-EAP-Type
  1856.  
  1857.    Description
  1858.  
  1859.       The MS-Acct-EAP-Type Attribute is used to represent the Extensible
  1860.       Authentication Protocol (EAP) [15] type used to authenticate the
  1861.       dial-up user.  It MAY be included in Accounting-Request packets.
  1862.  
  1863.    A summary of the MS-Acct-EAP-Type Attribute format is given below.
  1864.    The fields are transmitted left to right.
  1865.  
  1866.     0                   1                   2                   3
  1867.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1868.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1869.    |  Vendor-Type  | Vendor-Length |           EAP-Type
  1870.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1871.              EAP-Type (cont)       |
  1872.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1873.  
  1874.    Vendor-Type
  1875.       24 for MS-Acct-EAP-Type
  1876.  
  1877.    Vendor-Length
  1878.       6
  1879.  
  1880.    Auth-Type
  1881.       The EAP-Type field is 4 octets in length.  The following values
  1882.       are currently defined for this field:
  1883.  
  1884.          MD5                    4
  1885.          OTP                    5
  1886.          Generic Token Card     6
  1887.          TLS                    13
  1888.  
  1889. 2.7.6.  MS-Primary-DNS-Server
  1890.  
  1891.    Description
  1892.  
  1893.       The MS-Primary-DNS-Server Attribute is used to indicate the
  1894.       address of the primary Domain Name Server (DNS) [16, 17] server to
  1895.       be used by the PPP peer.  It MAY be included in both Access-Accept
  1896.       and Accounting-Request packets.
  1897.  
  1898.    A summary of the MS-Primary-DNS-Server Attribute format is given
  1899.    below.  The fields are transmitted left to right.
  1900.  
  1901.  
  1902.  
  1903.  
  1904.  
  1905.  
  1906. Zorn                         Informational                     [Page 34]
  1907.  
  1908. RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
  1909.  
  1910.  
  1911.     0                   1                   2                   3
  1912.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1913.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1914.    |  Vendor-Type  | Vendor-Length |           IP-Address
  1915.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1916.            IP-Address (cont)       |
  1917.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1918.  
  1919.    Vendor-Type
  1920.       28 for MS-Primary-DNS-Server
  1921.  
  1922.    Vendor-Length
  1923.       6
  1924.  
  1925.    IP-Address
  1926.       The IP-Address field is 4 octets in length.  It contains the IP
  1927.       address of the primary DNS server.
  1928.  
  1929. 2.7.7.  MS-Secondary-DNS-Server
  1930.  
  1931.    Description
  1932.  
  1933.       The MS-Secondary-DNS-Server Attribute is used to indicate the
  1934.       address of the secondary DNS server to be used by the PPP peer.
  1935.       It MAY be included in both Access-Accept and Accounting-Request
  1936.       packets.
  1937.  
  1938.    A summary of the MS-Secondary-DNS-Server Attribute format is given
  1939.    below.  The fields are transmitted left to right.
  1940.  
  1941.     0                   1                   2                   3
  1942.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1943.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1944.    |  Vendor-Type  | Vendor-Length |           IP-Address
  1945.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1946.            IP-Address (cont)       |
  1947.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1948.  
  1949.    Vendor-Type
  1950.       29 for MS-Secondary-DNS-Server
  1951.  
  1952.    Vendor-Length
  1953.       6
  1954.  
  1955.    IP-Address
  1956.       The IP-Address field is 4 octets in length.  It contains the IP
  1957.       address of the secondary DNS server.
  1958.  
  1959.  
  1960.  
  1961.  
  1962. Zorn                         Informational                     [Page 35]
  1963.  
  1964. RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
  1965.  
  1966.  
  1967. 2.7.8.  MS-Primary-NBNS-Server
  1968.  
  1969.    Description
  1970.  
  1971.       The MS-Primary-NBNS-Server Attribute is used to indicate the
  1972.       address of the primary NetBIOS Name Server (NBNS) [18] server to
  1973.       be used by the PPP peer.  It MAY be included in both Access-Accept
  1974.       and Accounting-Request packets.
  1975.  
  1976.    A summary of the MS-Primary-MBNS-Server Attribute format is given
  1977.    below.  The fields are transmitted left to right.
  1978.  
  1979.     0                   1                   2                   3
  1980.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1981.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1982.    |  Vendor-Type  | Vendor-Length |           IP-Address
  1983.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1984.            IP-Address (cont)       |
  1985.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1986.  
  1987.    Vendor-Type
  1988.       30 for MS-Primary-NBNS-Server
  1989.  
  1990.    Vendor-Length
  1991.       6
  1992.  
  1993.    IP-Address
  1994.       The IP-Address field is 4 octets in length.  It contains the IP
  1995.       address of the primary NBNS server.
  1996.  
  1997. 2.7.9.  MS-Secondary-NBNS-Server
  1998.  
  1999.    Description
  2000.  
  2001.       The MS-Secondary-NBNS-Server Attribute is used to indicate the
  2002.       address of the secondary DNS server to be used by the PPP peer.
  2003.       It MAY be included in both Access-Accept and Accounting-Request
  2004.       packets.
  2005.  
  2006.    A summary of the MS-Secondary-NBNS-Server Attribute format is given
  2007.    below.  The fields are transmitted left to right.
  2008.  
  2009.  
  2010.  
  2011.  
  2012.  
  2013.  
  2014.  
  2015.  
  2016.  
  2017.  
  2018. Zorn                         Informational                     [Page 36]
  2019.  
  2020. RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
  2021.  
  2022.  
  2023.     0                   1                   2                   3
  2024.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  2025.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2026.    |  Vendor-Type  | Vendor-Length |           IP-Address
  2027.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2028.            IP-Address (cont)       |
  2029.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2030.  
  2031.    Vendor-Type
  2032.       31 for MS-Secondary-NBNS-Server
  2033.  
  2034.    Vendor-Length
  2035.       6
  2036.  
  2037.    IP-Address
  2038.       The IP-Address field is 4 octets in length.  It contains the IP
  2039.       address of the secondary NBNS server.
  2040.  
  2041. 3.  Table of Attributes
  2042.  
  2043.    The following table provides a guide to which of the above attributes
  2044.    may be found in which kinds of packets, and in what quantity.
  2045.  
  2046.  Request Accept Reject Challenge Acct-Request #  Attribute
  2047.  0-1     0      0      0         0             1 MS-CHAP-Response
  2048.  0       0      0-1    0         0             2 MS-CHAP-Error
  2049.  0-1     0      0      0         0             3 MS-CHAP-CPW-1
  2050.  0-1     0      0      0         0             4 MS-CHAP-CPW-2
  2051.  0+      0      0      0         0             5 MS-CHAP-LM-Enc-PW
  2052.  0+      0      0      0         0             6 MS-CHAP-NT-Enc-PW
  2053.  0       0-1    0      0         0             7 MS-MPPE-Encryption-
  2054.                                                  Policy
  2055.  0       0-1    0      0         0             8 MS-MPPE-Encryption-Type
  2056.  0-1     0      0      0         0-1           9 MS-RAS-Vendor
  2057.  0       0-1    0      0         0-1          10 MS-CHAP-Domain
  2058.  0-1     0      0      0-1       0            11 MS-CHAP-Challenge
  2059.  0       0-1    0      0         0            12 MS-CHAP-MPPE-Keys
  2060.  0       0-1    0      0         0            13 MS-BAP-Usage
  2061.  0       0-1    0      0         0            14 MS-Link-Utilization-
  2062.                                                  Threshold
  2063.  0       0-1    0      0         0            15 MS-Link-Drop-Time-Limit
  2064.  0       0-1    0      0         0            16 MS-MPPE-Send-Key
  2065.  0       0-1    0      0         0            17 MS-MPPE-Recv-Key
  2066.  0-1     0      0      0         0-1          18 MS-RAS-Version
  2067.  0-1     0      0      0         0            19 MS-Old-ARAP-Password
  2068.  0-1     0      0      0         0            20 MS-New-ARAP-Password
  2069.  0       0      0      0-1       0            21 MS-ARAP-PW-Change-
  2070.                                                  Reason
  2071.  
  2072.  
  2073.  
  2074. Zorn                         Informational                     [Page 37]
  2075.  
  2076. RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
  2077.  
  2078.  
  2079.  0       0+     0      0         0+           22 MS-Filter
  2080.  0       0      0      0         0-1          23 MS-Acct-Auth-Type
  2081.  0       0      0      0         0-1          24 MS-Acct-EAP-Type
  2082.  0-1     0      0      0         0            25 MS-CHAP2-Response
  2083.  0       0-1    0      0         0            26 MS-CHAP2-Success
  2084.  0-1     0      0      0         0            27 MS-CHAP2-CPW
  2085.  0       0-1    0      0         0-1          28 MS-Primary-DNS-Server
  2086.  0       0-1    0      0         0-1          29 MS-Secondary-DNS-Server
  2087.  0       0-1    0      0         0-1          30 MS-Primary-NBNS-Server
  2088.  0       0-1    0      0         0-1          31 MS-Secondary-NBNS-
  2089.                                                  Server
  2090.  0-1     0      0      0         0            33 MS-ARAP-Challenge
  2091.  
  2092. The following table defines the meaning of the above table entries.
  2093.  
  2094. 0     This attribute MUST NOT be present in packet.
  2095. 0+    Zero or more instances of this attribute MAY be present in packet.
  2096. 0-1   Zero or one instance of this attribute MAY be present in packet.
  2097.  
  2098. 4.  Security Considerations
  2099.  
  2100.    MS-CHAP, like PPP CHAP, is susceptible to dictionary attacks.  User
  2101.    passwords should be chosen with care, and be of sufficient length to
  2102.    deter easy guessing.
  2103.  
  2104.    Although the scheme used to protect the Keys field of the MS-CHAP-
  2105.    MPPE-Keys, MS-MPPE-Send-Key and MS-MPPE-Recv-Key Attributes is
  2106.    believed to be relatively secure on the wire, RADIUS proxies will
  2107.    decrypt and re-encrypt the field for forwarding.  Therefore, these
  2108.    attributes SHOULD NOT be used on networks where untrusted RADIUS
  2109.    proxies reside.
  2110.  
  2111. 5.  Acknowledgements
  2112.  
  2113.    Thanks to Carl Rigney (cdr@livingston.com), Ashwin Palekar (ash-
  2114.    winp@microsoft.com), Aydin Edguer (edguer@MorningStar.com), Narendra
  2115.    Gidwani (nareng@microsoft.com), Steve Cobb (stevec@microsoft.com),
  2116.    Pat Calhoun (pcalhoun@eng.sun.com), Dave Mitton
  2117.    (dmitton@baynetworks.com), Paul Funk (paul@funk.com), Gurdeep Singh
  2118.    Pall (gurdeep@microsoft.com), Stephen Bensley (sbens@microsoft.com),
  2119.    and Don Rule (don-aldr@microsoft.com) for useful suggestions and
  2120.    editorial feedback.
  2121.  
  2122.  
  2123.  
  2124.  
  2125.  
  2126.  
  2127.  
  2128.  
  2129.  
  2130. Zorn                         Informational                     [Page 38]
  2131.  
  2132. RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
  2133.  
  2134.  
  2135. 6.  Editor's Address
  2136.  
  2137.    Questions about this memo can be directed to:
  2138.  
  2139.    Glen Zorn
  2140.    Microsoft Corporation
  2141.    One Microsoft Way
  2142.    Redmond, Washington 98052
  2143.  
  2144.    Phone: +1 425 703 1559
  2145.    Fax:   +1 425 936 7329
  2146.    EMail: glennz@microsoft.com
  2147.  
  2148. 7.  References
  2149.  
  2150.    [1]  Simpson, W., "PPP Challenge Handshake Authentication
  2151.         Protocol (CHAP)", RFC 1994, August 1996.
  2152.  
  2153.    [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
  2154.         Levels", BCP 14, RFC 2119, March 1997.
  2155.  
  2156.    [3]  Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
  2157.         Access Dial In User Service", RFC 2138, April 1997.
  2158.  
  2159.    [4]  Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC 2433,
  2160.         October 1998.
  2161.  
  2162.    [5]  Simpson, W., "PPP Challenge Handshake Authentication Protocol
  2163.         (CHAP)", RFC 1994, August 1996.
  2164.  
  2165.    [6]  Zorn, G. and G. Pall, "Microsoft Point-to-Point Encryption
  2166.         (MPPE) Protocol", Work in Progress.
  2167.  
  2168.    [7]  Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
  2169.         1661, July 1994.
  2170.  
  2171.    [8]  RC4 is a proprietary encryption algorithm available under
  2172.         license from RSA Data Security Inc.  For licensing information,
  2173.         contact:
  2174.                RSA Data Security, Inc.
  2175.                100 Marine Parkway
  2176.                Redwood City, CA 94065-1031
  2177.  
  2178.    [9]  Pall, G., "Microsoft Point-to-Point Compression (MPPC)
  2179.         Protocol", RFC 2118, March 1997.
  2180.  
  2181.    [10] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC
  2182.         1962, June 1996.
  2183.  
  2184.  
  2185.  
  2186. Zorn                         Informational                     [Page 39]
  2187.  
  2188. RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
  2189.  
  2190.  
  2191.    [11] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti,
  2192.         "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
  2193.  
  2194.    [12] Richards, C. and K. Smith, "The PPP Bandwidth Allocation
  2195.         Protocol (BAP) The PPP Bandwidth Allocation Control Protocol
  2196.         (BACP)", RFC 2125, March 1997.
  2197.  
  2198.    [13] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
  2199.         October 1994.
  2200.  
  2201.    [14] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", Work in
  2202.         Progress.
  2203.  
  2204.    [15] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
  2205.         Protocol (EAP)", RFC 2284, March 1998.
  2206.  
  2207.    [16] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
  2208.         13, RFC 1034, USC/ISI, November 1987.
  2209.  
  2210.    [17] Mockapetris, P., "Domain Names - Implementation and
  2211.         Specification", STD 13, RFC 1035, November 1987.
  2212.  
  2213.    [18] Auerbach, K., and A. Aggarwal, "Protocol Standard for a NetBIOS
  2214.         Service on a TCP/UDP Transport", STD 19, RFCs 1001 and 1002,
  2215.         March 1987.
  2216.  
  2217.  
  2218.  
  2219.  
  2220.  
  2221.  
  2222.  
  2223.  
  2224.  
  2225.  
  2226.  
  2227.  
  2228.  
  2229.  
  2230.  
  2231.  
  2232.  
  2233.  
  2234.  
  2235.  
  2236.  
  2237.  
  2238.  
  2239.  
  2240.  
  2241.  
  2242. Zorn                         Informational                     [Page 40]
  2243.  
  2244. RFC 2548      Microsoft Vendor-specific RADIUS Attributes     March 1999
  2245.  
  2246.  
  2247. 10.  Full Copyright Statement
  2248.  
  2249.    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  2250.  
  2251.    This document and translations of it may be copied and furnished to
  2252.    others, and derivative works that comment on or otherwise explain it
  2253.    or assist in its implementation may be prepared, copied, published
  2254.    and distributed, in whole or in part, without restriction of any
  2255.    kind, provided that the above copyright notice and this paragraph are
  2256.    included on all such copies and derivative works.  However, this
  2257.    document itself may not be modified in any way, such as by removing
  2258.    the copyright notice or references to the Internet Society or other
  2259.    Internet organizations, except as needed for the purpose of
  2260.    developing Internet standards in which case the procedures for
  2261.    copyrights defined in the Internet Standards process must be
  2262.    followed, or as required to translate it into languages other than
  2263.    English.
  2264.  
  2265.    The limited permissions granted above are perpetual and will not be
  2266.    revoked by the Internet Society or its successors or assigns.
  2267.  
  2268.    This document and the information contained herein is provided on an
  2269.    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  2270.    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  2271.    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  2272.    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  2273.    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  2274.  
  2275.  
  2276.  
  2277.  
  2278.  
  2279.  
  2280.  
  2281.  
  2282.  
  2283.  
  2284.  
  2285.  
  2286.  
  2287.  
  2288.  
  2289.  
  2290.  
  2291.  
  2292.  
  2293.  
  2294.  
  2295.  
  2296.  
  2297.  
  2298. Zorn                         Informational                     [Page 41]
  2299.  
  2300.