idnits 2.17.1 draft-ietf-radius-ms-vsa-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 267 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 10 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The abstract seems to contain references ([3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 11 has weird spacing: '...This document...' == Line 12 has weird spacing: '...as, and its...' == Line 17 has weird spacing: '...and may be ...' == Line 18 has weird spacing: '...ference mater...' == Line 21 has weird spacing: '...To learn the...' == (262 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 1998) is 9325 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2138 (ref. '3') (Obsoleted by RFC 2865) -- Duplicate reference: RFC1994, mentioned in '5', was also mentioned in '1'. == Outdated reference: A later version (-05) exists of draft-ietf-pppext-mppe-02 ** Obsolete normative reference: RFC 1700 (ref. '13') (Obsoleted by RFC 3232) == Outdated reference: A later version (-04) exists of draft-ietf-pppext-mschap-v2-01 ** Obsolete normative reference: RFC 2284 (ref. '15') (Obsoleted by RFC 3748) Summary: 17 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Zorn, Editor 3 Internet-Draft Microsoft Corporation 4 Category: Informational October 1998 5 7 Microsoft Vendor-specific RADIUS Attributes 9 1. Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working docu- 12 ments of the Internet Engineering Task Force (IETF), its areas, and its 13 working groups. Note that other groups may also distribute working doc- 14 uments as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference material 19 or to cite them other than as ``work in progress''. 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), 24 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 26 This memo provides information for the Internet community. This memo 27 does not specify an Internet standard of any kind. The distribution of 28 this memo is unlimited. It is filed as and expires April 29, 1999. Please send comments to the 30 editor (glennz@microsoft.com). 32 2. Abstract 34 This document describes the set of Microsoft vendor-specific RADIUS 35 attributes. These attributes are designed to support Microsoft propri- 36 etary dial-up protocols and/or provide support for features which is not 37 provided by the standard RADIUS attribute set [3]. It is expected that 38 this memo will be updated whenever Microsoft defines a new vendor-spe- 39 cific attribute, since its primary purpose is to provide an open, easily 40 accessible reference for third-parties wishing to interoperate with 41 Microsoft products. 43 3. Specification of Requirements 45 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 46 "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as 47 described in [2]. 49 4. Attributes 51 The following sections describe sub-attributes which may be transmitted 52 in one or more RADIUS attributes of type Vendor-Specific [3]. More than 53 one sub-attribute MAY be transmitted in a single Vendor-Specific 54 Attribute; if this is done, the sub-attributes SHOULD be packed as a 55 sequence of Vendor-Type/Vendor-Length/Value triples following the inital 56 Type, Length and Vendor-ID fields. The Length field of the Vendor-Spe- 57 cific Attribute MUST be set equal to the sum of the Vendor-Length fields 58 of the sub-attributes contained in the Vendor-Specific Attribute, plus 59 six. The Vendor-ID field of the Vendor-Specific Attribute(s) MUST be 60 set to decimal 311 (Microsoft). 62 4.1. Attributes for Support of MS-CHAP Version 1 64 4.1.1. Introduction 66 Microsoft created Microsoft Challenge-Handshake Authentication Protocol 67 (MS-CHAP) [4] to authenticate remote Windows workstations, providing the 68 functionality to which LAN-based users are accustomed. Where possible, 69 MS-CHAP is consistent with standard CHAP [5], and the differences are 70 easily modularized. Briefly, the differences between MS-CHAP and stan- 71 dard CHAP are: 73 * MS-CHAP is enabled by negotiating CHAP Algorithm 0x80 in LCP 74 option 3, Authentication Protocol. 76 * The MS-CHAP Response packet is in a format designed for 77 compatibility with Microsoft Windows NT 3.5, 3.51 and 4.0, 78 Microsoft Windows95, and Microsoft LAN Manager 2.x networking 79 products. The MS-CHAP format does not require the 80 authenticator to store a clear-text or reversibly encrypted 81 password. 83 * MS-CHAP provides an authenticator-controlled authentication 84 retry mechanism. 86 * MS-CHAP provides an authenticator-controlled password changing 87 mechanism. 89 * MS-CHAP defines an extended set of reason-for-failure codes, 90 returned in the Failure packet Message field. 92 The attributes defined in this section reflect these differences. 94 4.1.2. MS-CHAP-Challenge 96 Description 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. 102 A summary of the MS-CHAP-Challenge Attribute format is shown below. 103 The fields are transmitted from left to right. 105 0 1 2 3 106 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 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | Vendor-Type | Vendor-Length | String... 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 Vendor-Type 112 11 for MS-CHAP-Challenge. 114 Vendor-Length 115 > 2 117 String 118 The String field contains the MS-CHAP challenge. 120 4.1.3. MS-CHAP-Response 122 Description 124 This Attribute contains the response value provided by a PPP 125 Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP) 126 user in response to the challenge. It is only used in Access- 127 Request packets. 129 A summary of the MS-CHAP-Response Attribute format is shown below. 130 The fields are transmitted from left to right. 132 0 1 2 3 133 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 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Vendor-Type | Vendor-Length | Ident | Flags | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | LM-Response 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 LM-Response (cont) 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 LM-Response (cont) 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 LM-Response (cont) 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 LM-Response (cont) 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 LM-Response(cont) | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | NT-Response 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 NT-Response (cont) 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 NT-Response (cont) 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 NT-Response (cont) 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 NT-Response (cont) 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 NT-Response (cont) | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 Vendor-Type 163 1 for MS-CHAP-Response. 165 Vendor-Length 166 52 168 Ident 169 Identical to the PPP CHAP Identifier. 171 Flags 172 The Flags field is one octet in length. If the Flags field is one 173 (0x01), the NT-Response field is to be used in preference to the 174 LM-Response field for authentication. The LM-Response field MAY 175 still be used (if non-empty), but the NT-Response SHOULD be tried 176 first. If it is zero, the NT-Response field MUST be ignored and 177 the LM-Response field used. 179 LM-Response 180 The LM-Response field is 24 octets in length and holds an encoded 181 function of the password and the received challenge. If this 182 field is empty, it SHOULD be zero-filled. 184 NT-Response 185 The NT-Response field is 24 octets in length and holds an encoded 186 function of the password and the received challenge. If this 187 field is empty, it SHOULD be zero-filled. 189 4.1.4. MS-CHAP-Domain 191 Description 193 The MS-CHAP-Domain Attribute indicates the Windows NT domain in 194 which the user was authenticated. It MAY be included in both 195 Access-Accept and Accounting-Request packets. 197 A summary of the MS-CHAP-Domain Attribute format is given below. The 198 fields are transmitted left to right. 200 0 1 2 3 201 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 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Vendor-Type | Vendor-Length | Ident | String... 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 Vendor-Type 207 10 for MS-CHAP-Domain. 209 Vendor-Length 210 > 3 212 Ident 213 The Ident field is one octet and aids in matching requests and 214 replies. 216 String 217 This field contains the name in ASCII of the Windows NT domain in 218 which the user was authenticated. 220 4.1.5. MS-CHAP-Error 222 Description 224 The MS-CHAP-Error Attribute contains error data related to the 225 preceding MS-CHAP exchange. This Attribute may be used in both 226 MS-CHAP-V1 and MS-CHAP-V2 (see below) exchanges. It is only used 227 in Access-Reject packets. 229 A summary of the MS-CHAP-Error Attribute format is given below. The 230 fields are transmitted left to right. 232 0 1 2 3 233 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 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Vendor-Type | Vendor-Length | Ident | String... 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 Vendor-Type 240 2 for MS-CHAP-Error. 242 Vendor-Length 243 > 3 245 Ident 246 The Ident field is one octet and aids in matching requests and 247 replies. 249 String 250 This field contains specially formatted ASCII text, which is 251 interpreted by the authenticating peer. 253 4.1.6. MS-CHAP-CPW-1 255 Description 257 This Attribute allows the user to change their password if it has 258 expired. This Attribute is only used in Access-Request packets, 259 and should only be included if an MS-CHAP-Error attribute was 260 included in the immediately preceding Access-Reject packet, the 261 String field of the MS-CHAP-Error attribute indicated that the 262 user password had expired, and the MS-CHAP version is less than 2. 264 A summary of the MS-CHAP-CPW-1 Attribute format is shown below. The 265 fields are transmitted from left to right. 267 0 1 2 3 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Vendor-Type | Vendor-Length | Code | Ident | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | LM-Old-Password 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 LM-Old-Password (cont) 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 LM-Old-Password (cont) 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 LM-Old-Password (cont) | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | LM-New-Password 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 LM-New-Password (cont) 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 LM-New-Password (cont) 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 LM-New-Password (cont) | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | NT-Old-Password 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 NT-Old-Password (cont) 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 NT-Old-Password (cont) 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 NT-Old-Password (cont) | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | NT-New-Password 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 NT-New-Password (cont) 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 NT-New-Password (cont) 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 NT-New-Password (cont) | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | New-LM-Password-Length | Flags | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 Vendor-Type 308 3 for MS-CHAP-PW-1 310 Vendor-Length 311 72 313 Code 314 The Code field is one octet in length. Its value is always 5. 316 Ident 317 The Ident field is one octet and aids in matching requests and 318 replies. 320 LM-Old-Password 321 The LM-Old-Password field is 16 octets in length. It contains the 322 encrypted Lan Manager hash of the old password. 324 LM-New-Password 325 The LM-New-Password field is 16 octets in length. It contains the 326 encrypted Lan Manager hash of the new password. 328 NT-Old-Password 329 The NT-Old-Password field is 16 octets in length. It contains the 330 encrypted Lan Manager hash of the old password. 332 NT-New-Password 333 The NT-New-Password field is 16 octets in length. It contains the 334 encrypted Lan Manager hash of the new password. 336 New-LM-Password-Length 337 The New-LM-Password-Length field is two octets in length and con- 338 tains the length in octets of the new LAN Manager-compatible pass- 339 word. 341 Flags 342 The Flags field is two octets in length. If the least significant 343 bit of the Flags field is one, this indicates that the NT-New- 344 Password and NT-Old-Password fields are valid and SHOULD be used. 345 Otherwise, the LM-New-Password and LM-Old-Password fields MUST be 346 used. 348 4.1.7. MS-CHAP-CPW-2 350 Description 352 This Attribute allows the user to change their password if it has 353 expired. This Attribute is only used in Access-Request packets, 354 and should only be included if an MS-CHAP-Error attribute was 355 included in the immediately preceding Access-Reject packet, the 356 String field of the MS-CHAP-Error attribute indicated that the 357 user password had expired, and the MS-CHAP version is equal to 2. 359 A summary of the MS-CHAP-CPW-2 Attribute format is shown below. The 360 fields are transmitted from left to right. 362 0 1 2 3 363 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 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Vendor-Type | Vendor-Length | Code | Ident | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Old-NT-Hash 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 Old-NT-Hash (cont) 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 Old-NT-Hash (cont) 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 Old-NT-Hash (cont) | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Old-LM-Hash 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 Old-LM-Hash(cont) 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 Old-LM-Hash(cont) 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 Old-LM-Hash(cont) | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | LM-Response 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 LM-Response (cont) 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 LM-Response (cont) 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 LM-Response (cont) 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 LM-Response (cont) 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 LM-Response (cont) | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | NT-Response 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--++-+-+-+-+-+-+-+-+-+-+-+-+ 397 NT-Response (cont) 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--++-+-+-+-+-+-+-+-+-+-+-+ 399 NT-Response (cont) 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 NT-Response (cont) 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 NT-Response (cont) 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 NT-Response (cont) | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Flags | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 Vendor-Type 411 4 for MS-CHAP-PW-2 413 Vendor-Length 414 86 416 Code 417 6 419 Ident 420 The Ident field is one octet and aids in matching requests and 421 replies. The value of this field MUST be identical to that in the 422 Ident field in all instances of the MS-CHAP-LM-Enc-PW, MS-CHAP-NT- 423 Enc-PW and MS-CHAP-PW-2 attributes contained in a single Access- 424 Request packet. 426 Old-NT-Hash 427 The Old-NT-Hash field is 16 octets in length. It contains the old 428 Windows NT password hash encrypted with the new Windows NT pass- 429 word hash. 431 Old-LM-Hash 432 The Old-LM-Hash field is 16 octets in length. It contains the old 433 Lan Manager password hash encrypted with the new Windows NT pass- 434 word hash. 436 LM-Response 437 The LM-Response field is 24 octets in length and holds an encoded 438 function of the password and the received challenge. If this 439 field is empty, it SHOULD be zero-filled. 441 NT-Response 442 The NT-Response field is 24 octets in length and holds an encoded 443 function of the password and the received challenge. If this 444 field is empty, it SHOULD be zero-filled. 446 Flags 447 The Flags field is two octets in length. If the least significant 448 bit (bit 0) of this field is one, the NT-Response field is to be 449 used in preference to the LM-Response field for authentication. 450 The LM-Response field MAY still be used (if present), but the NT- 451 Response SHOULD be tried first. If least significant bit of the 452 field is zero, the NT-Response field MUST be ignored and the LM- 453 Response field used instead. If bit 1 of the Flags field is one, 454 the Old-LM-Hash field is valid and SHOULD be used. If this bit is 455 set, at least one instance of the MS-CHAP-LM-Enc-PW attribute MUST 456 be included in the packet. 458 4.1.8. MS-CHAP-LM-Enc-PW 460 Description 462 This Attribute contains the new Windows NT password encrypted with 463 the old LAN Manager password hash. The encrypted Windows NT pass- 464 word is 516 octets in length; since this is longer than the maxi- 465 mum lengtth of a RADIUS attribute, the password must be split into 466 several attibutes for transmission. A 2 octet sequence number is 467 included in the attribute to help preserve ordering of the pass- 468 word fragments. 470 This Attribute is only used in Access-Request packets, in conjunc- 471 tion with the MS-CHAP-CPW-2 attribute. It should only be included 472 if an MS-CHAP-Error attribute was included in the immediately pre- 473 ceding Access-Reject packet, the String field of the MS-CHAP-Error 474 attribute indicated that the user password had expired, and the 475 MS-CHAP version is 2 or greater. 477 A summary of the MS-CHAP-LM-Enc-PW Attribute format is shown below. 478 The fields are transmitted from left to right. 480 0 1 2 3 481 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 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Vendor-Type | Vendor-Length | Code | Ident | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Sequence-Number | String ... 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 Vendor-Type 489 5 for MS-CHAP-LM-Enc-PW 491 Vendor-Length 492 > 6 494 Code 495 6. Code is the same as for the MS-CHAP-PW-2 attribute. 497 Ident 498 The Ident field is one octet and aids in matching requests and 499 replies. The value of this field MUST be identical in all 500 instances of the MS-CHAP-LM-Enc-PW, MS-CHAP-NT-Enc-PW and MS-CHAP- 501 PW-2 attributes which are present in the same Access-Request 502 packet. 504 Sequence-Number 505 The Sequence-Number field is two octets in length and indicates 506 which "chunk" of the encrypted password is contained in the fol- 507 lowing String field. 509 String 510 The String field contains a portion of the encrypted password. 512 4.2. MS-CHAP-NT-Enc-PW 514 Description 516 This Attribute contains the new Windows NT password encrypted with 517 the old Windows NT password hash. The encrypted Windows NT pass- 518 word is 516 octets in length; since this is longer than the maxi- 519 mum lengtth of a RADIUS attribute, the password must be split into 520 several attibutes for transmission. A 2 octet sequence number is 521 included in the attribute to help preserve ordering of the pass- 522 word fragments. 524 This Attribute is only used in Access-Request packets, in conjunc- 525 tion with the MS-CHAP-CPW-2 and MS-CHAP2-CPW attributes. It 526 should only be included if an MS-CHAP-Error attribute was included 527 in the immediately preceding Access-Reject packet, the String 528 field of the MS-CHAP-Error attribute indicated that the user pass- 529 word had expired, and the MS-CHAP version is 2 or greater. 531 A summary of the MS-CHAP-NT-Enc-PW Attribute format is shown below. 532 The fields are transmitted from left to right. 534 0 1 2 3 535 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 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Vendor-Type | Vendor-Length | Code | Ident | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | Sequence-Number | String ... 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 Vendor-Type 543 6 for MS-CHAP-NT-Enc-PW 545 Vendor-Length 546 > 6 548 Code 549 6. Code is the same as for the MS-CHAP-PW-2 attribute. 551 Ident 552 The Ident field is one octet and aids in matching requests and 553 replies. The value of this field MUST be identical in all 554 instances of the MS-CHAP-LM-Enc-PW, MS-CHAP-NT-Enc-PW and MS-CHAP- 555 PW-2 attributes which are present in the same Access-Request 556 packet. 558 Sequence-Number 559 The Sequence-Number field is two octets in length and indicates 560 which "chunk" of the encrypted password is contained in the fol- 561 lowing String field. 563 String 564 The String field contains a portion of the encrypted password. 566 4.3. Attributes for Support of MS-CHAP Version 2 568 4.3.1. Introduction 570 This section describes RADIUS attributes supporting version two of 571 Microsoft's PPP CHAP dialect (MS-CHAP-V2) [14]. MS-CHAP-V2 is similar 572 to, but incompatible with, MS-CHAP ver- sion one (MS-CHAP-V1) [4]. 573 Certain protocol fields have been deleted or reused but with different 574 semantics. Where possible, MS-CHAP-V2 is consistent with both MS-CHAP- 575 V1 and stan- dard CHAP [1]. Briefly, the differences between MS- 576 CHAP-V2 and MS-CHAP-V1 are: 578 * MS-CHAP-V2 is enabled by negotiating CHAP Algorithm 0x81 in LCP 579 option 3, Authentication Protocol. 581 * MS-CHAP-V2 provides mutual authentication between peers by 582 piggybacking a peer challenge on the Response packet and an 583 authenticator response on the Success packet. 585 * The calculation of the "Windows NT compatible challenge 586 response" sub-field in the Response packet has been changed 587 to include the peer challenge and the user name. 589 * In MS-CHAP-V1, the "LAN Manager compatible challenge response" 590 sub-field was always sent in the Response packet. This field 591 has been replaced in MS-CHAP-V2 by the Peer-Challenge field. 593 * The format of the Message field in the Failure packet has 594 been changed. 596 * The Change Password (version 1) and Change Password (version 2) 597 packets are no longer supported. They have been replaced with a 598 single Change-Password packet. 600 The attributes defined in this section reflect these differences. 602 4.3.2. MS-CHAP2-Response 604 Description 606 This Attribute contains the response value provided by an MS-CHAP- 607 V2 peer in response to the challenge. It is only used in Access- 608 Request packets. 610 A summary of the MS-CHAP2-Response Attribute format is shown below. 611 The fields are transmitted from left to right. 613 0 1 2 3 614 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 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Vendor-Type | Vendor-Length | Ident | Flags | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Peer-Challenge 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 Peer-Challenge (cont) 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 Peer-Challenge (cont) 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 Peer-Challenge (cont) | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Reserved 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 Reserved (cont) | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | Response 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 Response (cont) 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 Response (cont) 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 Response (cont) 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 Response (cont) 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 Response (cont) | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 Vendor-Type 644 25 for MS-CHAP2-Response. 646 Vendor-Length 647 52 649 Ident 650 Identical to the PPP MS-CHAP v2 Identifier. 652 Flags 653 The Flags field is one octet in length. It is reserved for future 654 use and MUST be zero. 656 Peer-Challenge 657 The Peer-Challenge field is a 16-octet random number. 659 Reserved 660 This field is reserved for future use and MUST be zero. 662 Response 663 The Response field is 24 octets in length and holds an encoded 664 function of the password, the Peer-Challenge field and the 665 received challenge. 667 4.3.3. MS-CHAP2-Success 669 Description 671 This Attribute contains a 42-octet authenticator response string. 672 This string MUST be included in the Message field of the MS-CHAP- 673 V2 Success packet sent from the NAS to the peer. This Attribute 674 is only used in Access-Accept packets. 676 A summary of the MS-CHAP2-Success Attribute format is shown below. 677 The fields are transmitted from left to right. 679 0 1 2 3 680 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 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | Vendor-Type | Vendor-Length | Ident | String... 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 Vendor-Type 686 26 for MS-CHAP2-Success. 688 Vendor-Length 689 45 691 Ident 692 Identical to the PPP MS-CHAP v2 Identifier. 694 String 695 The 42-octet authenticator string (see above). 697 4.3.4. MS-CHAP2-CPW 699 Description 701 This Attribute allows the user to change their password if it has 702 expired. This Attribute is only used in conjunction with the MS- 703 CHAP-NT-Enc-PW attribute in Access-Request packets, and should 704 only be included if an MS-CHAP-Error attribute was included in the 705 immediately preceding Access-Reject packet, the String field of 706 the MS-CHAP-Error attribute indicated that the user password had 707 expired, and the MS-CHAP version is equal to 3. 709 A summary of the MS-CHAP-CPW-2 Attribute format is shown below. The 710 fields are transmitted from left to right. 712 0 1 2 3 713 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 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | Vendor-Type | Vendor-Length | Code | Ident | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | Encrypted-Hash 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 Encrypted-Hash (cont) 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 Encrypted-Hash (cont) 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 Encrypted-Hash (cont) | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | Peer-Challenge 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 Peer-Challenge (cont) 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 Peer-Challenge (cont) 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 Peer-Challenge (cont) 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 Peer-Challenge (cont) 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 Peer-Challenge (cont) | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | NT-Response 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--++-+-+-+-+-+-+-+-+-+-+-+-+ 739 NT-Response (cont) 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--++-+-+-+-+-+-+-+-+-+-+-+ 741 NT-Response (cont) 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 NT-Response (cont) 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 NT-Response (cont) 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 NT-Response (cont) | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | Flags | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 Vendor-Type 753 27 for MS-CHAP2-PW 755 Vendor-Length 756 70 758 Code 759 7 761 Ident 762 The Ident field is one octet and aids in matching requests and 763 replies. The value of this field MUST be identical to that in the 764 Ident field in all instances of the MS-CHAP-NT-Enc-PW contained in 765 the Access-Request packet. 767 Encrypted-Hash 768 The Encrypted-Hash field is 16 octets in length. It contains the 769 old Windows NT password hash encrypted with the new Windows NT 770 password hash. 772 NT-Response 773 The NT-Response field is 24 octets in length and holds an encoded 774 function of the new password, the Peer-Challenge field and the 775 received challenge. 777 Flags 778 The Flags field is two octets in length. This field is reserved 779 for future use and MUST be zero. 781 4.4. Attributes for MPPE Support 783 This section describes a set of Attributes designed to support the use 784 of Microsoft Point-to-Point Encryption (MPPE) [6] in dial-up networks. 785 MPPE is a means of representing Point to Point Protocol (PPP) [7] pack- 786 ets in a encrypted form. MPPE uses the RSA RC4 [8] algorithm for 787 encryption. The length of the session key to be used for initializing 788 encryption tables can be negotiated; MPPE currently supports 40 bit and 789 128 bit session keys. MPPE is negotiated within option 18 in the PPP 790 Compression Control Protocol (CCP)[9], [10]. 792 4.4.1. MS-CHAP-MPPE-Keys 794 Description 796 The MS-CHAP-MPPE-Keys Attribute contains two session keys for use 797 by the Microsoft Point-to-Point Encryption Protocol (MPPE). This 798 Attribute is only included in Access-Accept packets. 800 A summary of the MS-CHAP-MPPE-Keys Attribute format is given below. 801 The fields are transmitted left to right. 803 0 1 2 3 804 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 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | Vendor-Type | Vendor-Length | Keys 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 Keys (cont) 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 Keys (cont) 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 Keys (cont) 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 Keys (cont) 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 Keys (cont) 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 Keys (cont) 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 Keys (cont) 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 Keys (cont) | 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 Vendor-Type 826 12 for MS-CHAP-MPPE-Keys. 828 Vendor-Length 829 34 831 Keys 832 The Keys field consists of two logical sub-fields: the LM-Key and 833 the NT-Key. The LM-Key is eight octets in length and contains the 834 first eight bytes of the output of the function 835 LmPasswordHash(P, This hash is constructed as follows: let the 836 plain-text password be represented by P. 838 The NT-Key sub-field is sixteen octets in length and contains 839 the first sixteen octets of the hashed Windows NT password. 840 The format of the plaintext Keys field is illustrated in the 841 following diagram: 843 0 1 2 3 844 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 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | LM-Key 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 LM-Key (cont) | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | NT-Key 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 NT-Key (cont) 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 NT-Key (cont) 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 NT-Key (cont) | 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 | Padding 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 Padding (cont) | 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 The Keys field MUST be encrypted by the RADIUS server using the 864 same method defined for the User-Password Attribute [3]. 865 Padding is required because the method referenced above 866 requires the field to be encrypted to be a multiple of sixteen 867 octets in length. 869 Implementation Note 870 This attribute should only be returned in response to an 871 Access-Request packet containing MS-CHAP attributes. 873 4.4.2. MS-MPPE-Send-Key 875 Description 877 The MS-MPPE-Send-Key Attribute contains a session key for use by 878 the Microsoft Point-to-Point Encryption Protocol (MPPE). As the 879 name implies, this key is intended for encrypting packets sent 880 from the NAS to the remote host. This Attribute is only included 881 in Access-Accept packets. 883 A summary of the MS-MPPE-Send-Key Attribute format is given below. 884 The fields are transmitted left to right. 886 0 1 2 3 887 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 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 | Vendor-Type | Vendor-Length | Salt 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 String... 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 Vendor-Type 895 16 for MS-MPPE-Send-Key. 897 Vendor-Length 898 > 4 900 Salt 901 The Salt field is two octets in length and is used to ensure the 902 uniqueness of the keys used to encrypt each of the encrypted 903 attributes occurring in a given Access-Accept packet. The most 904 significant bit (leftmost) of the Salt field MUST be set (1). The 905 contents of each Salt field in a given Access-Accept packet MUST 906 be unique. 908 String 909 The plaintext String field consists of three logical sub-fields: 910 the Key-Length and Key sub-fields (both of which are required), 911 and the optional Padding sub-field. The Key-Length sub-field is 912 one octet in length and contains the length of the unencrypted Key 913 sub-field. The Key sub-field contains the actual encryption key. 914 If the combined length (in octets) of the unencrypted Key-Length 915 and Key sub-fields is not an even multiple of 16, then the Padding 916 sub-field MUST be present. If it is present, the length of the 917 Padding sub-field is variable, between 1 and 15 octets. The 918 String field MUST be encrypted as follows, prior to transmission: 920 Construct a plaintext version of the String field by concate- 921 nating the Key-Length and Key sub-fields. If necessary, pad 922 the resulting string until its length (in octets) is an even 923 multiple of 16. It is recommended that zero octets (0x00) be 924 used for padding. Call this plaintext P. 926 Call the shared secret S, the pseudo-random 128-bit Request 927 Authenticator (from the corresponding Access-Request packet) R, 928 and the contents of the Salt field A. Break P into 16 octet 929 chunks p(1), p(2)...p(i), where i = len(P)/16. Call the 930 ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C. 931 Intermediate values b(1), b(2)...c(i) are required. Encryption 932 is performed in the following manner ('+' indicates concatena- 933 tion): 935 b(1) = MD5(S + R + A) c(1) = p(1) xor b(1) C = c(1) 936 b(2) = MD5(S + c(1)) c(2) = p(2) xor b(2) C = C + c(2) 937 . . 938 . . 939 . . 940 b(i) = MD5(S + c(i-1)) c(i) = p(i) xor b(i) C = C + c(i) 942 The resulting encrypted String field will contain 943 c(1)+c(2)+...+c(i). 945 On receipt, the process is reversed to yield the plaintext String. 947 Implementation Notes 948 It is possible that the length of the key returned may be larger 949 than needed for the encryption scheme in use. In this case, the 950 RADIUS client is responsible for performing any necessary trunca- 951 tion. 953 This attribute MAY be used to pass a key from an external (e.g., 954 EAP [15]) server to the RADIUS server. In this case, it may be 955 impossible for the external server to correctly encrypt the key, 956 since the RADIUS shared secret might be unavailable. The external 957 server SHOULD, however, return the attribute as defined above; the 958 Salt field SHOULD be zero-filled and padding of the String field 959 SHOULD be done. When the RADIUS server receives the attribute 960 from the external server, it MUST correctly set the Salt field and 961 encrypt the String field before transmitting it to the RADIUS 962 client. If the channel used to communicate the MS-MPPE-Send-Key 963 attribute is not secure from eavesdropping, the attribute MUST be 964 cryptographically protected. 966 4.4.3. MS-MPPE-Recv-Key 968 Description 970 The MS-MPPE-Recv-Key Attribute contains a session key for use by 971 the Microsoft Point-to-Point Encryption Protocol (MPPE). As the 972 name implies, this key is intended for encrypting packets received 973 by the NAS from the remote host. This Attribute is only included 974 in Access-Accept packets. 976 A summary of the MS-MPPE-Recv-Key Attribute format is given below. 977 The fields are transmitted left to right. 979 0 1 2 3 980 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 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 | Vendor-Type | Vendor-Length | Salt 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 String... 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 987 Vendor-Type 988 17 for MS-MPPE-Recv-Key. 990 Vendor-Length 991 > 4 993 Salt 994 The Salt field is two octets in length and is used to ensure the 995 uniqueness of the keys used to encrypt each of the encrypted 996 attributes occurring in a given Access-Accept packet. The most 997 significant bit (leftmost) of the Salt field MUST be set (1). The 998 contents of each Salt field in a given Access-Accept packet MUST 999 be unique. 1001 String 1002 The plaintext String field consists of three logical sub-fields: 1003 the Key-Length and Key sub-fields (both of which are required), 1004 and the optional Padding sub-field. The Key-Length sub-field is 1005 one octet in length and contains the length of the unencrypted Key 1006 sub-field. The Key sub-field contains the actual encryption key. 1007 If the combined length (in octets) of the unencrypted Key-Length 1008 and Key sub-fields is not an even multiple of 16, then the Padding 1009 sub-field MUST be present. If it is present, the length of the 1010 Padding sub-field is variable, between 1 and 15 octets. The 1011 String field MUST be encrypted as follows, prior to transmission: 1013 Construct a plaintext version of the String field by concate- 1014 nating the Key-Length and Key sub-fields. If necessary, pad 1015 the resulting string until its length (in octets) is an even 1016 multiple of 16. It is recommended that zero octets (0x00) be 1017 used for padding. Call this plaintext P. 1019 Call the shared secret S, the pseudo-random 128-bit Request 1020 Authenticator (from the corresponding Access-Request packet) R, 1021 and the contents of the Salt field A. Break P into 16 octet 1022 chunks p(1), p(2)...p(i), where i = len(P)/16. Call the 1023 ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C. 1024 Intermediate values b(1), b(2)...c(i) are required. Encryption 1025 is performed in the following manner ('+' indicates concatena- 1026 tion): 1028 b(1) = MD5(S + R + A) c(1) = p(1) xor b(1) C = c(1) 1029 b(2) = MD5(S + c(1)) c(2) = p(2) xor b(2) C = C + c(2) 1030 . . 1031 . . 1032 . . 1033 b(i) = MD5(S + c(i-1)) c(i) = p(i) xor b(i) C = C + c(i) 1035 The resulting encrypted String field will contain 1036 c(1)+c(2)+...+c(i). 1038 On receipt, the process is reversed to yield the plaintext String. 1040 Implementation Notes 1041 It is possible that the length of the key returned may be larger 1042 than needed for the encryption scheme in use. In this case, the 1043 RADIUS client is responsible for performing any necessary trunca- 1044 tion. 1046 This attribute MAY be used to pass a key from an external (e.g., 1047 EAP [15]) server to the RADIUS server. In this case, it may be 1048 impossible for the external server to correctly encrypt the key, 1049 since the RADIUS shared secret might be unavailable. The external 1050 server SHOULD, however, return the attribute as defined above; the 1051 Salt field SHOULD be zero-filled and padding of the String field 1052 SHOULD be done. When the RADIUS server receives the attribute 1053 from the external server, it MUST correctly set the Salt field and 1054 encrypt the String field before transmitting it to the RADIUS 1055 client. If the channel used to communicate the MS-MPPE-Recv-Key 1056 attribute is not secure from eavesdropping, the attribute MUST be 1057 cryptographically protected. 1059 4.4.4. MS-MPPE-Encryption-Policy 1061 Description 1063 The MS-MPPE-Encryption-Policy Attribute may be used to signify 1064 whether the use of encryption is allowed or required. If the Pol- 1065 icy field is equal to 1 (Encryption-Allowed), any or none of the 1066 encryption types specified in the MS-MPPE-Encryption-Types 1067 Attribute MAY be used. If the Policy field is equal to 2 (Encryp- 1068 tion-Required), any of the encryption types specified in the MS- 1069 MPPE-Encryption-Types Attribute MAY be used, but at least one MUST 1070 be used. 1071 A summary of the MS-MPPE-Encryption-Policy Attribute format is given 1072 below. The fields are transmitted left to right. 1074 0 1 2 3 1075 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 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 | Vendor-Type | Vendor-Length | Policy 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 Policy (cont) | 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 Vendor-Type 1083 7 for MS-MPPE-Encryption-Policy. 1085 Vendor-Length 1086 6 1088 Policy 1089 The Policy field is 4 octets in length. Defined values are: 1091 1 Encryption-Allowed 2 Encryption-Required 1093 4.4.5. MS-MPPE-Encryption-Types 1095 Description 1097 The MS-MPPE-Encryption-Types Attribute is used to signify the 1098 types of encryption available for use with MPPE. It is a four 1099 octet integer that is interpreted as a string of bits. 1100 A summary of the MS-MPPE-Encryption-Policy Attribute format is given 1101 below. The fields are transmitted left to right. 1103 0 1 2 3 1104 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 1105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 | Vendor-Type | Vendor-Length | Types 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 Types (cont) | 1109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1111 Vendor-Type 1112 8 for MS-MPPE-Encryption-Types. 1114 Vendor-Length 1115 6 1117 Policy 1118 The Types field is 4 octets in length. The following diagram 1119 illustrates the Types field. 1121 3 2 1 1122 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 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1124 | |S|L| | 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1127 If the L bit is set, RC4[5] encryption using a 40-bit key is 1128 allowed. If the S bit is set, RC4 encryption using a 128-bit key 1129 is allowed. If both the L and S bits are set, then either 40- or 1130 128-bit keys may be used with the RC4 algorithm. 1132 4.5. Attributes for BAP Support 1134 This section describes a set of vendor-specific RADIUS attributes 1135 designed to support the dynamic control of bandwidth allocation in mul- 1136 tilink PPP [11]. Attributes are defined that specify whether use of the 1137 PPP Bandwidth Allocation Protocol (BAP) [12] is allowed or required on 1138 incoming calls, the level of line capacity (expressed as a percentage) 1139 below which utilization must fall before a link is eligible to be 1140 dropped, and the length of time (in seconds) that a link must be under- 1141 utilized before it is dropped. 1143 4.5.1. MS-BAP-Usage 1145 Description 1147 This Attribute describes whether the use of BAP is allowed, disal- 1148 lowed or required on new multilink calls. It MAY be used in 1149 Access-Accept packets. 1151 A summary of the MS-BAP-Usage Attribute format is shown below. The 1152 fields are transmitted from left to right. 1154 0 1 2 3 1155 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 1156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1157 | Vendor-Type | Vendor-Length | Value 1158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1159 Value (cont) | 1160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1162 Vendor-Type 1163 13 for MS-BAP-Usage. 1165 Vendor-Length 1166 6 1168 Value 1169 The Value field is four octets. 1171 0 BAP usage not allowed 1172 1 BAP usage allowed 1173 2 BAP usage required 1175 4.5.2. MS-Link-Utilization-Threshold 1177 Description 1179 This Attribute represents the percentage of available bandwidth 1180 utilization below which the link must fall before the link is eli- 1181 gible for termination. Permissible values for the MS-Link-Uti- 1182 lization-Threshold Attribute are in the range 1-100, inclusive. 1183 It is only used in Access-Accept packets. 1185 A summary of the MS-Link-Utilization-Threshold Attribute format is 1186 shown below. The fields are transmitted from left to right. 1188 0 1 2 3 1189 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 1190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1191 | Vendor-Type | Vendor-Length | Value 1192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1193 Value (cont) | 1194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1196 Vendor-Type 1197 14 for MS-Link-Utilization-Threshold 1199 Vendor-Length 1200 6 1202 Value 1203 The Value field is four octets in length and represents the per- 1204 centage of available bandwidth utilization below which the link 1205 must fall before the link is eligible for termination. Permissi- 1206 ble values are in the range 1-100, inclusive. 1208 4.5.3. MS-Link-Drop-Time-Limit 1210 Description 1212 The MS-Link-Drop-Time-Limit Attribute indicates the length of time 1213 (in seconds) that a link must be underutilized before it is 1214 dropped. It MAY only be included in Access-Accept packets. 1216 A summary of the MS-Link-Drop-Time-Limit Attribute format is given 1217 below. The fields are transmitted left to right. 1219 0 1 2 3 1220 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 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 | Vendor-Type | Vendor-Length | Value 1223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1224 Value (cont) | 1225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1227 Vendor-Type 1228 15 for MS-Link-Drop-Time-Limit 1230 Vendor-Length 1231 6 1233 Value 1234 The Value field represents the number of seconds that a link must 1235 be underutilized (i.e., display bandwidth utilization below the 1236 threshold specified in the MS-Link-Utilization-Threshold 1237 Attribute) before the link is dropped. 1239 4.6. Attributes for ARAP Support 1241 This section describes a set of Attributes designed to support the Apple 1242 Remote Access Protocol (ARAP). 1244 4.6.1. MS-Old-ARAP-Password 1246 Description 1248 The MS-Old-ARAP-Password Attribute is used to transmit the old 1249 ARAP password durin an ARAP password change operation. It MAY be 1250 included in Access-Request packets. 1252 A summary of the MS-Old-ARAP-Password Attribute Attribute format is 1253 given below. The fields are transmitted left to right. 1255 0 1 2 3 1256 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 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1258 | Vendor-Type | Vendor-Length | String... 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1261 Vendor-Type 1262 19 for MS-Old-ARAP-Password Attribute 1264 Vendor-Length 1265 >3 1267 String 1268 The String field is one or more octets. It contains the old ARAP 1269 password DES-encrypted using itself as the key. 1271 4.6.2. MS-New-ARAP-Password 1273 Description 1275 The MS-New-ARAP-Password Attribute is used to transmit the new 1276 ARAP password during an ARAP password change operation. It MAY be 1277 included in Access-Request packets. 1279 A summary of the MS-New-ARAP-Password Attribute Attribute format is 1280 given below. The fields are transmitted left to right. 1282 0 1 2 3 1283 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 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1285 | Vendor-Type | Vendor-Length | String... 1286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1288 Vendor-Type 1289 20 for MS-New-ARAP-Password Attribute 1291 Vendor-Length 1292 >3 1294 String 1295 The String field is one or more octets. It contains the new ARAP 1296 password DES-encrypted using the old ARAP password as the key. 1298 4.6.3. MS-ARAP-Password-Change-Reason 1300 Description 1302 The MS-ARAP-Password-Change-Reason Attribute is used to indicate 1303 reason for a server-initiated password change. It MAY be included 1304 in Access-Challenge packets. 1306 A summary of the MS-ARAP-Password-Change-Reason Attribute format is 1307 given below. The fields are transmitted left to right. 1309 0 1 2 3 1310 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 1311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1312 | Vendor-Type | Vendor-Length | Why 1313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1314 Why (cont) | 1315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1317 Vendor-Type 1318 21 for MS-ARAP-Password-Change-Reason 1320 Vendor-Length 1321 6 1323 Why 1324 The Why field is 4 octets in length. The following values are 1325 defined: 1326 Just-Change-Password 1 1327 Expired-Password 2 1328 Admin-Requires-Password-Change 3 1329 Password-Too-Short 4 1331 4.6.4. MS-ARAP-Challenge 1333 Description 1335 This attribute is only present in an Access-Request packet con- 1336 taining a Framed-Protocol Attribute with the value 3 (ARAP). 1338 A summary of the MS-ARAP-Challenge Attribute format is given below. 1339 The fields are transmitted left to right. 1341 0 1 2 3 1342 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 1343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1344 | Vendor-Type | Vendor-Length | Challenge 1345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1346 Challenge (cont) | 1347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1348 Challenge (cont) | 1349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1351 Vendor-Type 1352 33 for MS-ARAP-Challenge 1354 Vendor-Length 1355 10 1357 Value 1358 The Challenge Field is 8 octets in length. It contains the chal- 1359 lenge (as two 4-octet quantities) sent by the NAS to the peer. 1361 4.7. Miscellaneous Attributes 1363 This section describes attributes which do not fall into any particular 1364 category, but are used in the identification and operation of Microsoft 1365 remote access products. 1367 4.7.1. MS-RAS-Vendor 1369 Description 1371 The MS-RAS-Vendor Attribute is used to indicate the manufacturer 1372 of the RADIUS client machine. It MAY be included in both Access- 1373 Request and Accounting-Request packets. 1375 A summary of the MS-RAS-Vendor Attribute format is given below. The 1376 fields are transmitted left to right. 1378 0 1 2 3 1379 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 1380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1381 | Vendor-Type | Vendor-Length | Vendor-ID 1382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1383 Vendor-ID (cont) | 1384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1386 Vendor-Type 1387 9 for MS-RAS-Vendor 1389 Vendor-Length 1390 6 1392 Vendor-ID 1393 The Vendor-ID field is 4 octets in length. The high-order octet 1394 is 0 and the low-order 3 octets are the SMI Network Management 1395 Private Enterprise Code of the Vendor in network byte order, as 1396 defined in the Assigned Numbers RFC [13]. 1398 4.7.2. MS-RAS-Version 1400 Description 1402 The MS-RAS-Version Attribute is used to indicate the version of 1403 the RADIUS client software. This attribute SHOULD be included in 1404 packets containing an MS-RAS-Vendor Attribute; it SHOULD NOT be 1405 sent in packets which do not contain an MS-RAS-Vendor Attribute. 1406 It MAY be included in both Access-Request and Accounting-Request 1407 packets. 1409 A summary of the MS-RAS-Version Attribute format is given below. The 1410 fields are transmitted left to right. 1412 0 1 2 3 1413 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 1414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1415 | Vendor-Type | Vendor-Length | String... 1416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1418 Vendor-Type 1419 18 for MS-RAS-Version 1421 Vendor-Length 1422 >3 1424 String 1425 The String field is one or more octets. The actual format of the 1426 information is vendor specific, and a robust implementation SHOULD 1427 support the field as undistinguished octets. 1429 4.7.3. MS-Filter 1431 Description 1433 The MS-Filter Attribute is used to transmit traffic filters. It 1434 MAY be included in both Access-Accept and Accounting-Request pack- 1435 ets. 1437 If multiple MS-Filter Attributes are contained within a packet, 1438 they MUST be in order and they MUST be consecutive attributes in 1439 the packet. 1441 A summary of the MS-Filter Attribute format is given below. The 1442 fields are transmitted left to right. 1444 0 1 2 3 1445 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 1446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1447 | Vendor-Type | Vendor-Length | Filter... 1448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1450 Vendor-Type 1451 22 for MS-Filter Attribute 1453 Vendor-Length 1454 >3 1456 Filter 1457 The Filter field is one or more octets. It contains a sequence of 1458 undifferentiated octets. 1460 If multiple MS-Filter Attributes occur in a single Access-Accept 1461 packet, the Filter field from each MUST be concatenated in the 1462 order received to form the actual filter. 1464 4.7.4. MS-Acct-Auth-Type 1466 Description 1468 The MS-Acct-Auth-Type Attribute is used to represent the method 1469 used to authenticate the dial-up user. It MAY be included in 1470 Accounting-Request packets. 1472 A summary of the MS-Acct-Auth-Type Attribute format is given below. 1473 The fields are transmitted left to right. 1475 0 1 2 3 1476 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 1477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1478 | Vendor-Type | Vendor-Length | Auth-Type 1479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1480 Auth-Type (cont) | 1481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1483 Vendor-Type 1484 23 for MS-Acct-Auth-Type 1486 Vendor-Length 1487 6 1489 Auth-Type 1490 The Auth-Type field is 4 octets in length. The following values 1491 are defined for this field: 1492 PAP 1 1493 CHAP 2 1494 MS-CHAP-1 3 1495 MS-CHAP-2 4 1496 EAP 5 1498 4.7.5. MS-Acct-EAP-Type 1500 Description 1502 The MS-Acct-EAP-Type Attribute is used to represent the Extensible 1503 Authentication Protocol (EAP) [15] type used to authenticate the 1504 dial-up user. It MAY be included in Accounting-Request packets. 1506 A summary of the MS-Acct-EAP-Type Attribute format is given below. 1507 The fields are transmitted left to right. 1509 0 1 2 3 1510 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 1511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1512 | Vendor-Type | Vendor-Length | EAP-Type 1513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1514 EAP-Type (cont) | 1515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1517 Vendor-Type 1518 24 for MS-Acct-EAP-Type 1520 Vendor-Length 1521 6 1523 Auth-Type 1524 The EAP-Type field is 4 octets in length. The following values 1525 are currently defined for this field: 1526 MD5 4 1527 OTP 5 1528 Generic Token Card 6 1529 TLS 13 1531 4.7.6. MS-Primary-DNS-Server 1533 Description 1535 The MS-Primary-DNS-Server Attribute is used to indicate the 1536 address of the primary Domain Name Server (DNS) [16, 17] server to 1537 be used by the PPP peer. It MAY be included in both Access-Accept 1538 and Accounting-Request packets. 1540 A summary of the MS-Primary-DNS-Server Attribute format is given 1541 below. The fields are transmitted left to right. 1543 0 1 2 3 1544 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 1545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1546 | Vendor-Type | Vendor-Length | IP-Address 1547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1548 IP-Address (cont) | 1549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1551 Vendor-Type 1552 28 for MS-Primary-DNS-Server 1554 Vendor-Length 1555 6 1557 IP-Address 1558 The IP-Address field is 4 octets in length. It contains the IP 1559 address of the primary DNS server. 1561 4.7.7. MS-Secondary-DNS-Server 1563 Description 1565 The MS-Secondary-DNS-Server Attribute is used to indicate the 1566 address of the secondary DNS server to be used by the PPP peer. 1567 It MAY be included in both Access-Accept and Accounting-Request 1568 packets. 1570 A summary of the MS-Secondary-DNS-Server Attribute format is given 1571 below. The fields are transmitted left to right. 1573 0 1 2 3 1574 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 1575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1576 | Vendor-Type | Vendor-Length | IP-Address 1577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1578 IP-Address (cont) | 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1581 Vendor-Type 1582 29 for MS-Secondary-DNS-Server 1584 Vendor-Length 1585 6 1587 IP-Address 1588 The IP-Address field is 4 octets in length. It contains the IP 1589 address of the secondary DNS server. 1591 4.7.8. MS-Primary-NBNS-Server 1593 Description 1595 The MS-Primary-NBNS-Server Attribute is used to indicate the 1596 address of the primary NetBIOS Name Server (NBNS) [18] server to 1597 be used by the PPP peer. It MAY be included in both Access-Accept 1598 and Accounting-Request packets. 1600 A summary of the MS-Primary-MBNS-Server Attribute format is given 1601 below. The fields are transmitted left to right. 1603 0 1 2 3 1604 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 1605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1606 | Vendor-Type | Vendor-Length | IP-Address 1607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1608 IP-Address (cont) | 1609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1611 Vendor-Type 1612 30 for MS-Primary-NBNS-Server 1614 Vendor-Length 1615 6 1617 IP-Address 1618 The IP-Address field is 4 octets in length. It contains the IP 1619 address of the primary NBNS server. 1621 4.7.9. MS-Secondary-NBNS-Server 1623 Description 1625 The MS-Secondary-NBNS-Server Attribute is used to indicate the 1626 address of the secondary DNS server to be used by the PPP peer. 1627 It MAY be included in both Access-Accept and Accounting-Request 1628 packets. 1630 A summary of the MS-Secondary-NBNS-Server Attribute format is given 1631 below. The fields are transmitted left to right. 1633 0 1 2 3 1634 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 1635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1636 | Vendor-Type | Vendor-Length | IP-Address 1637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1638 IP-Address (cont) | 1639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1641 Vendor-Type 1642 31 for MS-Secondary-NBNS-Server 1644 Vendor-Length 1645 6 1647 IP-Address 1648 The IP-Address field is 4 octets in length. It contains the IP 1649 address of the secondary NBNS server. 1651 5. Table of Attributes 1653 The following table provides a guide to which of the above attributes 1654 may be found in which kinds of packets, and in what quantity. 1656 Request Accept Reject Challenge Acct-Request # Attribute 1657 0-1 0 0 0 0 1 MS-CHAP-Response 1658 0 0 0-1 0 0 2 MS-CHAP-Error 1659 0-1 0 0 0 0 3 MS-CHAP-CPW-1 1660 0-1 0 0 0 0 4 MS-CHAP-CPW-2 1661 0+ 0 0 0 0 5 MS-CHAP-LM-Enc-PW 1662 0+ 0 0 0 0 6 MS-CHAP-NT-Enc-PW 1663 0 0-1 0 0 0 7 MS-MPPE-Encryption-Policy 1664 0 0-1 0 0 0 8 MS-MPPE-Encryption-Type 1665 0-1 0 0 0 0-1 9 MS-RAS-Vendor 1666 0 0-1 0 0 0-1 10 MS-CHAP-Domain 1667 0-1 0 0 0-1 0 11 MS-CHAP-Challenge 1668 0 0-1 0 0 0 12 MS-CHAP-MPPE-Keys 1669 0 0-1 0 0 0 13 MS-BAP-Usage 1670 0 0-1 0 0 0 14 MS-Link-Utilization-Threshold 1671 0 0-1 0 0 0 15 MS-Link-Drop-Time-Limit 1672 0 0-1 0 0 0 16 MS-MPPE-Send-Key 1673 0 0-1 0 0 0 17 MS-MPPE-Recv-Key 1674 0-1 0 0 0 0-1 18 MS-RAS-Version 1675 0-1 0 0 0 0 19 MS-Old-ARAP-Password 1676 0-1 0 0 0 0 20 MS-New-ARAP-Password 1677 0 0 0 0-1 0 21 MS-ARAP-PW-Change-Reason 1678 0 0+ 0 0 0+ 22 MS-Filter 1679 0 0 0 0 0-1 23 MS-Acct-Auth-Type 1680 0 0 0 0 0-1 24 MS-Acct-EAP-Type 1681 0-1 0 0 0 0 25 MS-CHAP2-Response 1682 0 0-1 0 0 0 26 MS-CHAP2-Success 1683 0-1 0 0 0 0 27 MS-CHAP2-CPW 1684 0 0-1 0 0 0-1 28 MS-Primary-DNS-Server 1685 0 0-1 0 0 0-1 29 MS-Secondary-DNS-Server 1686 0 0-1 0 0 0-1 30 MS-Primary-NBNS-Server 1687 0 0-1 0 0 0-1 31 MS-Secondary-NBNS-Server 1688 0-1 0 0 0 0 33 MS-ARAP-Challenge 1689 The following table defines the meaning of the above table entries. 1691 0 This attribute MUST NOT be present in packet. 1692 0+ Zero or more instances of this attribute MAY be present in packet. 1693 0-1 Zero or one instance of this attribute MAY be present in packet. 1695 6. Security Considerations 1697 MS-CHAP, like PPP CHAP, is susceptible to dictionary attacks. User 1698 passwords should be chosen with care, and be of sufficient length to 1699 deter easy guessing. 1701 Although the scheme used to protect the Keys field of the MS-CHAP-MPPE- 1702 Keys, MS-MPPE-Send-Key and MS-MPPE-Recv-Key Attributes is believed to be 1703 relatively secure on the wire, RADIUS proxies will decrypt and re- 1704 encrypt the field for forwarding. Therefore, these attributes SHOULD 1705 NOT be used on networks where untrusted RADIUS proxies reside. 1707 7. Acknowledgements 1709 Thanks to Carl Rigney (cdr@livingston.com), Ashwin Palekar (ash- 1710 winp@microsoft.com), Aydin Edguer (edguer@MorningStar.com), Narendra 1711 Gidwani (nareng@microsoft.com), Steve Cobb (stevec@microsoft.com), Pat 1712 Calhoun (pcalhoun@eng.sun.com), Dave Mitton (dmitton@baynetworks.com), 1713 Paul Funk (paul@funk.com), Gurdeep Singh Pall (gurdeep@microsoft.com), 1714 Stephen Bensley (sbens@microsoft.com), and Don Rule (don- 1715 aldr@microsoft.com) for useful suggestions and editorial feedback. 1717 8. Expiration Date 1719 This memo is filed as and expires 1720 April 29, 1999. 1722 9. Editor's Address 1724 Questions about this memo can be directed to: 1726 Glen Zorn 1727 Microsoft Corporation 1728 One Microsoft Way 1729 Redmond, Washington 98052 1731 Phone: +1 425 703 1559 1732 FAX: +1 425 936 7329 1733 EMail: glennz@microsoft.com 1735 10. References 1737 [1] Simpson, W., "PPP Challenge Handshake Authentication Protocol 1738 (CHAP)", RFC 1994, August 1996 1740 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1741 Levels", BCP 14, RFC 2119, March 1997 1743 [3] Rigney, C., et. al., "Remote Access Dial In User Service", RFC 1744 2138, April 1997 1746 [4] Zorn, G. and Cobb, S., "Microsoft PPP CHAP Extensions", draft-ietf- 1747 pppext-mschap-00.txt (work in progress), March 1998 1749 [5] Simpson, W., "PPP Challenge Handshake Authentication Protocol 1750 (CHAP)", RFC 1994, August 1996 1752 [6] Zorn, G. and Pall, G. S., "Microsoft Point-to-Point Encryption 1753 (MPPE) Protocol", draft-ietf-pppext-mppe-02.txt (work in progress), 1754 September 1998 1756 [7] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, 1757 July 1994 1759 [8] RC4 is a proprietary encryption algorithm available under license 1760 from RSA Data Security Inc. For licensing information, contact: 1761 RSA Data Security, Inc. 1762 100 Marine Parkway 1763 Redwood City, CA 94065-1031 1765 [9] Pall, G. S., "Microsoft Point-to-Point Compression (MPPC) Proto- 1766 col", RFC 2118, March 1997 1768 [10] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC 1962, 1769 June 1996 1771 [11] Sklower, K., et. al., "The PPP Multilink Protocol (MP)", RFC 1990, 1772 August 1996 1774 [12] Richards, C. and Smith, K., "The PPP Bandwidth Allocation Protocol 1775 (BAP) The PPP Bandwidth Allocation Control Protocol (BACP)" RFC 1776 2125, March 1997 1778 [13] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, 1779 October 1994 1781 [14] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", draft-ietf- 1782 pppext-mschap-v2-01.txt (work in progress), October 1998 1784 [15] Blunk, L. and Vollbrecht, J., "PPP Extensible Authentication Proto- 1785 col (EAP)", RFC 2284, March 1998 1787 [16] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, 1788 RFC 1034, USC/ISI, November 1987 1790 [17] Mockapetris, P., "Domain Names - Implementation and Specification", 1791 STD 13, RFC 1035, USC/ISI, November 1987 1793 [18] Auerbach, K., and Aggarwal, A., "Protocol Standard for a NetBIOS 1794 Service on a TCP/UDP Transport", STD 19, RFCs 1001 and 1002, March 1795 1987