doc/rfc/rfc2548.txt

   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 \f
  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 \f
 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 \f
 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 \f
 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 \f
 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 \f
 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 \f
 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 \f
 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 \f
 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 \f
 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 \f
 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 \f
 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 \f
 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 \f
 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 \f
 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 \f
 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 \f
 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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f