Challenge (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Challenge (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
33 for MS-ARAP-Challenge
Vendor-Length
10
Value
The Challenge Field is 8 octets in length. It contains the
challenge (as two 4-octet quantities) sent by the NAS to the peer.
2.7. Miscellaneous Attributes
This section describes attributes which do not fall into any
particular category, but are used in the identification and operation
of Microsoft remote access products.
2.7.1. MS-RAS-Vendor
Description
The MS-RAS-Vendor Attribute is used to indicate the manufacturer
of the RADIUS client machine. It MAY be included in both Access-
Request and Accounting-Request packets.
A summary of the MS-RAS-Vendor Attribute format is given below. The
fields are transmitted left to right.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Vendor-ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-ID (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
9 for MS-RAS-Vendor
Vendor-Length
6
Vendor-ID
The Vendor-ID field is 4 octets in length. The high-order octet
is 0 and the low-order 3 octets are the SMI Network Management
Private Enterprise Code of the Vendor in network byte order, as
defined in the Assigned Numbers RFC[13].
2.7.2. MS-RAS-Version
Description
The MS-RAS-Version Attribute is used to indicate the version of
the RADIUS client software. This attribute SHOULD be included in
packets containing an MS-RAS-Vendor Attribute; it SHOULD NOT be
sent in packets which do not contain an MS-RAS-Vendor Attribute.
It MAY be included in both Access-Request and Accounting-Request
packets.
A summary of the MS-RAS-Version Attribute format is given below. The
fields are transmitted left to right.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
18 for MS-RAS-Version
Vendor-Length
> 3
String
The String field is one or more octets. The actual format of the
information is vendor specific, and a robust implementation SHOULD
support the field as undistinguished octets.
2.7.3. MS-Filter
Description
The MS-Filter Attribute is used to transmit traffic filters. It
MAY be included in both Access-Accept and Accounting-Request
packets.
If multiple MS-Filter Attributes are contained within a packet,
they MUST be in order and they MUST be consecutive attributes in
the packet.
A summary of the MS-Filter Attribute format is given below. The
fields are transmitted left to right.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Filter...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
22 for MS-Filter Attribute
Vendor-Length
> 3
Filter
The Filter field is one or more octets. It contains a sequence of
undifferentiated octets.
If multiple MS-Filter Attributes occur in a single Access-Accept
packet, the Filter field from each MUST be concatenated in the
order received to form the actual filter.
2.7.4. MS-Acct-Auth-Type
Description
The MS-Acct-Auth-Type Attribute is used to represent the method
used to authenticate the dial-up user. It MAY be included in
Accounting-Request packets.
A summary of the MS-Acct-Auth-Type Attribute format is given below.
The fields are transmitted left to right.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Auth-Type
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Auth-Type (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
23 for MS-Acct-Auth-Type
Vendor-Length
6
Auth-Type
The Auth-Type field is 4 octets in length. The following values
are defined for this field:
PAP 1
CHAP 2
MS-CHAP-1 3
MS-CHAP-2 4
EAP 5
2.7.5. MS-Acct-EAP-Type
Description
The MS-Acct-EAP-Type Attribute is used to represent the Extensible
Authentication Protocol (EAP) [15] type used to authenticate the
dial-up user. It MAY be included in Accounting-Request packets.
A summary of the MS-Acct-EAP-Type Attribute format is given below.
The fields are transmitted left to right.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | EAP-Type
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
EAP-Type (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
24 for MS-Acct-EAP-Type
Vendor-Length
6
Auth-Type
The EAP-Type field is 4 octets in length. The following values
are currently defined for this field:
MD5 4
OTP 5
Generic Token Card 6
TLS 13
2.7.6. MS-Primary-DNS-Server
Description
The MS-Primary-DNS-Server Attribute is used to indicate the
address of the primary Domain Name Server (DNS) [16, 17] server to
be used by the PPP peer. It MAY be included in both Access-Accept
and Accounting-Request packets.
A summary of the MS-Primary-DNS-Server Attribute format is given
below. The fields are transmitted left to right.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | IP-Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP-Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
28 for MS-Primary-DNS-Server
Vendor-Length
6
IP-Address
The IP-Address field is 4 octets in length. It contains the IP
address of the primary DNS server.
2.7.7. MS-Secondary-DNS-Server
Description
The MS-Secondary-DNS-Server Attribute is used to indicate the
address of the secondary DNS server to be used by the PPP peer.
It MAY be included in both Access-Accept and Accounting-Request
packets.
A summary of the MS-Secondary-DNS-Server Attribute format is given
below. The fields are transmitted left to right.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | IP-Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP-Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
29 for MS-Secondary-DNS-Server
Vendor-Length
6
IP-Address
The IP-Address field is 4 octets in length. It contains the IP
address of the secondary DNS server.
2.7.8. MS-Primary-NBNS-Server
Description
The MS-Primary-NBNS-Server Attribute is used to indicate the
address of the primary NetBIOS Name Server (NBNS) [18] server to
be used by the PPP peer. It MAY be included in both Access-Accept
and Accounting-Request packets.
A summary of the MS-Primary-MBNS-Server Attribute format is given
below. The fields are transmitted left to right.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | IP-Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP-Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
30 for MS-Primary-NBNS-Server
Vendor-Length
6
IP-Address
The IP-Address field is 4 octets in length. It contains the IP
address of the primary NBNS server.
2.7.9. MS-Secondary-NBNS-Server
Description
The MS-Secondary-NBNS-Server Attribute is used to indicate the
address of the secondary DNS server to be used by the PPP peer.
It MAY be included in both Access-Accept and Accounting-Request
packets.
A summary of the MS-Secondary-NBNS-Server Attribute format is given
below. The fields are transmitted left to right.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | IP-Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP-Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
31 for MS-Secondary-NBNS-Server
Vendor-Length
6
IP-Address
The IP-Address field is 4 octets in length. It contains the IP
address of the secondary NBNS server.
3. Table of Attributes
The following table provides a guide to which of the above attributes
may be found in which kinds of packets, and in what quantity.
Request Accept Reject Challenge Acct-Request # Attribute
0-1 0 0 0 0 1 MS-CHAP-Response
0 0 0-1 0 0 2 MS-CHAP-Error
0-1 0 0 0 0 3 MS-CHAP-CPW-1
0-1 0 0 0 0 4 MS-CHAP-CPW-2
0+ 0 0 0 0 5 MS-CHAP-LM-Enc-PW
0+ 0 0 0 0 6 MS-CHAP-NT-Enc-PW
0 0-1 0 0 0 7 MS-MPPE-Encryption-
Policy
0 0-1 0 0 0 8 MS-MPPE-Encryption-Type
0-1 0 0 0 0-1 9 MS-RAS-Vendor
0 0-1 0 0 0-1 10 MS-CHAP-Domain
0-1 0 0 0-1 0 11 MS-CHAP-Challenge
0 0-1 0 0 0 12 MS-CHAP-MPPE-Keys
0 0-1 0 0 0 13 MS-BAP-Usage
0 0-1 0 0 0 14 MS-Link-Utilization-
Threshold
0 0-1 0 0 0 15 MS-Link-Drop-Time-Limit
0 0-1 0 0 0 16 MS-MPPE-Send-Key
0 0-1 0 0 0 17 MS-MPPE-Recv-Key
0-1 0 0 0 0-1 18 MS-RAS-Version
0-1 0 0 0 0 19 MS-Old-ARAP-Password
0-1 0 0 0 0 20 MS-New-ARAP-Password
0 0 0 0-1 0 21 MS-ARAP-PW-Change-
Reason
0 0+ 0 0 0+ 22 MS-Filter
0 0 0 0 0-1 23 MS-Acct-Auth-Type
0 0 0 0 0-1 24 MS-Acct-EAP-Type
0-1 0 0 0 0 25 MS-CHAP2-Response
0 0-1 0 0 0 26 MS-CHAP2-Success
0-1 0 0 0 0 27 MS-CHAP2-CPW
0 0-1 0 0 0-1 28 MS-Primary-DNS-Server
0 0-1 0 0 0-1 29 MS-Secondary-DNS-Server
0 0-1 0 0 0-1 30 MS-Primary-NBNS-Server
0 0-1 0 0 0-1 31 MS-Secondary-NBNS-
Server
0-1 0 0 0 0 33 MS-ARAP-Challenge
The following table defines the meaning of the above table entries.
0 This attribute MUST NOT be present in packet.
0+ Zero or more instances of this attribute MAY be present in packet.
0-1 Zero or one instance of this attribute MAY be present in packet.
4. Security Considerations
MS-CHAP, like PPP CHAP, is susceptible to dictionary attacks. User
passwords should be chosen with care, and be of sufficient length to
deter easy guessing.
Although the scheme used to protect the Keys field of the MS-CHAP-
MPPE-Keys, MS-MPPE-Send-Key and MS-MPPE-Recv-Key Attributes is
believed to be relatively secure on the wire, RADIUS proxies will
decrypt and re-encrypt the field for forwarding. Therefore, these
attributes SHOULD NOT be used on networks where untrusted RADIUS
proxies reside.
5. Acknowledgements
Thanks to Carl Rigney (cdr@livingston.com), Ashwin Palekar (ash-
winp@microsoft.com), Aydin Edguer (edguer@MorningStar.com), Narendra
Gidwani (nareng@microsoft.com), Steve Cobb (stevec@microsoft.com),
Pat Calhoun (pcalhoun@eng.sun.com), Dave Mitton
(dmitton@baynetworks.com), Paul Funk (paul@funk.com), Gurdeep Singh
Pall (gurdeep@microsoft.com), Stephen Bensley (sbens@microsoft.com),
and Don Rule (don-aldr@microsoft.com) for useful suggestions and
editorial feedback.
6. Editor's Address
Questions about this memo can be directed to:
Glen Zorn
Microsoft Corporation
One Microsoft Way
Redmond, Washington 98052
Phone: +1 425 703 1559
Fax: +1 425 936 7329
EMail: glennz@microsoft.com
7. References
[1] Simpson, W., "PPP Challenge Handshake Authentication
Protocol (CHAP)", RFC1994, August 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March 1997.
[3] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
Access Dial In User Service", RFC2138, April 1997.
[4] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC2433,
October 1998.
[5] Simpson, W., "PPP Challenge Handshake Authentication Protocol
(CHAP)", RFC1994, August 1996.
[6] Zorn, G. and G. Pall, "Microsoft Point-to-Point Encryption
(MPPE) Protocol", Work in Progress.
[7] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
1661, July 1994.
[8] RC4 is a proprietary encryption algorithm available under
license from RSA Data Security Inc. For licensing information,
contact:
RSA Data Security, Inc.
100 Marine Parkway
Redwood City, CA 94065-1031
[9] Pall, G., "Microsoft Point-to-Point Compression (MPPC)
Protocol", RFC2118, March 1997.
[10] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC
1962, June 1996.
[11] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti,
"The PPP Multilink Protocol (MP)", RFC1990, August 1996.
[12] Richards, C. and K. Smith, "The PPP Bandwidth Allocation
Protocol (BAP) The PPP Bandwidth Allocation Control Protocol
(BACP)", RFC2125, March 1997.
[13] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC1700,
October 1994.
[14] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", Work in
Progress.
[15] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
Protocol (EAP)", RFC2284, March 1998.
[16] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
13, RFC1034, USC/ISI, November 1987.
[17] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC1035, November 1987.
[18] Auerbach, K., and A. Aggarwal, "Protocol Standard for a NetBIOS
Service on a TCP/UDP Transport", STD 19, RFCs 1001 and 1002,
March 1987.
10. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.