5 Virtual
6 PIAFS
7 HDLC Clear Channel
8 X.25
9 X.75
10 G.3 Fax
11 SDSL - Symmetric DSL
12 ADSL-CAP - Asymmetric DSL, Carrierless Amplitude Phase
Modulation
13 ADSL-DMT - Asymmetric DSL, Discrete Multi-Tone
14 IDSL - ISDN Digital Subscriber Line
15 Ethernet
16 xDSL - Digital Subscriber Line of unknown type
17 Cable
18 Wireless - Other
19 Wireless - IEEE 802.11
PIAFS is a form of wireless ISDN commonly used in Japan, and
stands for PHS (Personal Handyphone System) Internet Access Forum
Standard (PIAFS).
5.42. Port-Limit
Description
This Attribute sets the maximum number of ports to be provided to
the user by the NAS. This Attribute MAY be sent by the server to
the client in an Access-Accept packet. It is intended for use in
conjunction with Multilink PPP [12] or similar uses. It MAY also
be sent by the NAS to the server as a hint that that many ports
are desired for use, but the server is not required to honor the
hint.
A summary of the Port-Limit Attribute format is shown below. The
fields are transmitted from 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
62 for Port-Limit.
Length
6
Value
The field is 4 octets, containing a 32-bit unsigned integer with
the maximum number of ports this user should be allowed to connect
to on the NAS.
5.43. Login-LAT-Port
Description
This Attribute indicates the Port with which the user is to be
connected by LAT. It MAY be used in Access-Accept packets, but
only when LAT is specified as the Login-Service. It MAY be used
in an Access-Request packet as a hint to the server, but the
server is not required to honor the hint.
A summary of the Login-LAT-Port Attribute format is shown below. The
fields are transmitted from left to right.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
63 for Login-LAT-Port.
Length
>= 3
String
The String field is one or more octets, and contains the identity
of the LAT port to use. The LAT Architecture allows this string
to contain $ (dollar), - (hyphen), . (period), _ (underscore),
numerics, upper and lower case alphabetics, and the ISO Latin-1
character set extension. All LAT string comparisons are case
insensitive.
5.44. Table of Attributes
The following table provides a guide to which attributes may be found
in which kinds of packets, and in what quantity.
Request Accept Reject Challenge # Attribute
0-1 0-1 0 0 1 User-Name
0-1 0 0 0 2 User-Password [Note 1]
0-1 0 0 0 3 CHAP-Password [Note 1]
0-1 0 0 0 4 NAS-IP-Address [Note 2]
0-1 0 0 0 5 NAS-Port
0-1 0-1 0 0 6 Service-Type
0-1 0-1 0 0 7 Framed-Protocol
0-1 0-1 0 0 8 Framed-IP-Address
0-1 0-1 0 0 9 Framed-IP-Netmask
0 0-1 0 0 10 Framed-Routing
0 0+ 0 0 11 Filter-Id
0-1 0-1 0 0 12 Framed-MTU
0+ 0+ 0 0 13 Framed-Compression
0+ 0+ 0 0 14 Login-IP-Host
0 0-1 0 0 15 Login-Service
0 0-1 0 0 16 Login-TCP-Port
0 0+ 0+ 0+ 18 Reply-Message
0-1 0-1 0 0 19 Callback-Number
0 0-1 0 0 20 Callback-Id
0 0+ 0 0 22 Framed-Route
0 0-1 0 0 23 Framed-IPX-Network
0-1 0-1 0 0-1 24 State [Note 1]
0 0+ 0 0 25 Class
0+ 0+ 0 0+ 26 Vendor-Specific
0 0-1 0 0-1 27 Session-Timeout
0 0-1 0 0-1 28 Idle-Timeout
0 0-1 0 0 29 Termination-Action
0-1 0 0 0 30 Called-Station-Id
0-1 0 0 0 31 Calling-Station-Id
0-1 0 0 0 32 NAS-Identifier [Note 2]
0+ 0+ 0+ 0+ 33 Proxy-State
0-1 0-1 0 0 34 Login-LAT-Service
0-1 0-1 0 0 35 Login-LAT-Node
0-1 0-1 0 0 36 Login-LAT-Group
0 0-1 0 0 37 Framed-AppleTalk-Link
0 0+ 0 0 38 Framed-AppleTalk-Network
0 0-1 0 0 39 Framed-AppleTalk-Zone
0-1 0 0 0 60 CHAP-Challenge
0-1 0 0 0 61 NAS-Port-Type
0-1 0-1 0 0 62 Port-Limit
0-1 0-1 0 0 63 Login-LAT-Port
Request Accept Reject Challenge # Attribute
[Note 1] An Access-Request MUST contain either a User-Password or a
CHAP-Password or State. An Access-Request MUST NOT contain both a
User-Password and a CHAP-Password. If future extensions allow other
kinds of authentication information to be conveyed, the attribute for
that can be used in an Access-Request instead of User-Password or
CHAP-Password.
[Note 2] An Access-Request MUST contain either a NAS-IP-Address or a
NAS-Identifier (or both).
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.
1 Exactly one instance of this attribute MUST be present in packet.
6. IANA Considerations
This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the
RADIUS protocol, in accordance with BCP 26 [13].
There are three name spaces in RADIUS that require registration:
Packet Type Codes, Attribute Types, and Attribute Values (for certain
Attributes).
RADIUS is not intended as a general-purpose Network Access Server
(NAS) management protocol, and allocations should not be made for
purposes unrelated to Authentication, Authorization or Accounting.
6.1. Definition of Terms
The following terms are used here with the meanings defined in
BCP 26: "name space", "assigned value", "registration".
The following policies are used here with the meanings defined in
BCP 26: "Private Use", "First Come First Served", "Expert Review",
"Specification Required", "IETF Consensus", "Standards Action".
6.2. Recommended Registration Policies
For registration requests where a Designated Expert should be
consulted, the IESG Area Director for Operations should appoint the
Designated Expert.
For registration requests requiring Expert Review, the ietf-radius
mailing list should be consulted.
Packet Type Codes have a range from 1 to 254, of which 1-5,11-13 have
been allocated. Because a new Packet Type has considerable impact on
interoperability, a new Packet Type Code requires Standards Action,
and should be allocated starting at 14.
Attribute Types have a range from 1 to 255, and are the scarcest
resource in RADIUS, thus must be allocated with care. Attributes
1-53,55,60-88,90-91 have been allocated, with 17 and 21 available for
re-use. Attributes 17, 21, 54, 56-59, 89, 92-191 may be allocated
following Expert Review, with Specification Required. Release of
blocks of Attribute Types (more than 3 at a time for a given purpose)
should require IETF Consensus. It is recommended that attributes 17
and 21 be used only after all others are exhausted.
Note that RADIUS defines a mechanism for Vendor-Specific extensions
(Attribute 26) and the use of that should be encouraged instead of
allocation of global attribute types, for functions specific only to
one vendor's implementation of RADIUS, where no interoperability is
deemed useful.
As stated in the "Attributes" section above:
"[Attribute Type] Values 192-223 are reserved for experimental
use, values 224-240 are reserved for implementation-specific use,
and values 241-255 are reserved and should not be used."
Therefore Attribute values 192-240 are considered Private Use, and
values 241-255 require Standards Action.
Certain attributes (for example, NAS-Port-Type) in RADIUS define a
list of values to correspond with various meanings. There can be 4
billion (2^32) values for each attribute. Adding additional values to
the list can be done on a First Come, First Served basis by the IANA.
7. Examples
A few examples are presented to illustrate the flow of packets and
use of typical attributes. These examples are not intended to be
exhaustive, many others are possible. Hexadecimal dumps of the
example packets are given in network byte order, using the shared
secret "xyzzy5461".
7.1. User Telnet to Specified Host
The NAS at 192.168.1.16 sends an Access-Request UDP packet to the
RADIUS Server for a user named nemo logging in on port 3 with
password "arctangent".
The Request Authenticator is a 16 octet random number generated by
the NAS.
The User-Password is 16 octets of password padded at end with nulls,
XORed with MD5(shared secret|Request Authenticator).
01 00 00 38 0f 40 3f 94 73 97 80 57 bd 83 d5 cb
98 f4 22 7a 01 06 6e 65 6d 6f 02 12 0d be 70 8d
93 d4 13 ce 31 96 e4 3f 78 2a 0a ee 04 06 c0 a8
01 10 05 06 00 00 00 03
1 Code = Access-Request (1)
1 ID = 0
2 Length = 56
16 Request Authenticator
Attributes:
6 User-Name = "nemo"
18 User-Password
6 NAS-IP-Address = 192.168.1.16
6 NAS-Port = 3
The RADIUS server authenticates nemo, and sends an Access-Accept UDP
packet to the NAS telling it to telnet nemo to host 192.168.1.3.
The Response Authenticator is a 16-octet MD5 checksum of the code
(2), id (0), Length (38), the Request Authenticator from above, the
attributes in this reply, and the shared secret.
02 00 00 26 86 fe 22 0e 76 24 ba 2a 10 05 f6 bf
9b 55 e0 b2 06 06 00 00 00 01 0f 06 00 00 00 00
0e 06 c0 a8 01 03
1 Code = Access-Accept (2)
1 ID = 0 (same as in Access-Request)
2 Length = 38
16 Response Authenticator
Attributes:
6 Service-Type (6) = Login (1)
6 Login-Service (15) = Telnet (0)
6 Login-IP-Host (14) = 192.168.1.3
7.2. Framed User Authenticating with CHAP
The NAS at 192.168.1.16 sends an Access-Request UDP packet to the
RADIUS Server for a user named flopsy logging in on port 20 with PPP,
authenticating using CHAP. The NAS sends along the Service-Type and
Framed-Protocol attributes as a hint to the RADIUS server that this
user is looking for PPP, although the NAS is not required to do so.
The Request Authenticator is a 16 octet random number generated by
the NAS, and is also used as the CHAP Challenge.
The CHAP-Password consists of a 1 octet CHAP ID, in this case 22,
followed by the 16 octet CHAP response.
01 01 00 47 2a ee 86 f0 8d 0d 55 96 9c a5 97 8e
0d 33 67 a2 01 08 66 6c 6f 70 73 79 03 13 16 e9
75 57 c3 16 18 58 95 f2 93 ff 63 44 07 72 75 04
06 c0 a8 01 10 05 06 00 00 00 14 06 06 00 00 00
02 07 06 00 00 00 01
1 Code = 1 (Access-Request)
1 ID = 1
2 Length = 71
16 Request Authenticator
Attributes:
8 User-Name (1) = "flopsy"
19 CHAP-Password (3)
6 NAS-IP-Address (4) = 192.168.1.16
6 NAS-Port (5) = 20
6 Service-Type (6) = Framed (2)
6 Framed-Protocol (7) = PPP (1)
The RADIUS server authenticates flopsy, and sends an Access-Accept
UDP packet to the NAS telling it to start PPP service and assign an
address for the user out of its dynamic address pool.
The Response Authenticator is a 16-octet MD5 checksum of the code
(2), id (1), Length (56), the Request Authenticator from above, the
attributes in this reply, and the shared secret.
02 01 00 38 15 ef bc 7d ab 26 cf a3 dc 34 d9 c0
3c 86 01 a4 06 06 00 00 00 02 07 06 00 00 00 01
08 06 ff ff ff fe 0a 06 00 00 00 02 0d 06 00 00
00 01 0c 06 00 00 05 dc
1 Code = Access-Accept (2)
1 ID = 1 (same as in Access-Request)
2 Length = 56
16 Response Authenticator
Attributes:
6 Service-Type (6) = Framed (2)
6 Framed-Protocol (7) = PPP (1)
6 Framed-IP-Address (8) = 255.255.255.254
6 Framed-Routing (10) = None (0)
6 Framed-Compression (13) = VJ TCP/IP Header Compression (1)
6 Framed-MTU (12) = 1500
7.3. User with Challenge-Response card
The NAS at 192.168.1.16 sends an Access-Request UDP packet to the
RADIUS Server for a user named mopsy logging in on port 7. The user
enters the dummy password "challenge" in this example. The challenge
and response generated by the smart card for this example are
"32769430" and "99101462".
The Request Authenticator is a 16 octet random number generated by
the NAS.
The User-Password is 16 octets of password, in this case "challenge",
padded at the end with nulls, XORed with MD5(shared secret|Request
Authenticator).
01 02 00 39 f3 a4 7a 1f 6a 6d 76 71 0b 94 7a b9
30 41 a0 39 01 07 6d 6f 70 73 79 02 12 33 65 75
73 77 82 89 b5 70 88 5e 15 08 48 25 c5 04 06 c0
a8 01 10 05 06 00 00 00 07
1 Code = Access-Request (1)
1 ID = 2
2 Length = 57
16 Request Authenticator
Attributes:
7 User-Name (1) = "mopsy"
18 User-Password (2)
6 NAS-IP-Address (4) = 192.168.1.16
6 NAS-Port (5) = 7
The RADIUS server decides to challenge mopsy, sending back a
challenge string and looking for a response. The RADIUS server
therefore and sends an Access-Challenge UDP packet to the NAS.
The Response Authenticator is a 16-octet MD5 checksum of the code
(11), id (2), length (78), the Request Authenticator from above, the
attributes in this reply, and the shared secret.
The Reply-Message is "Challenge 32769430. Enter response at prompt."
The State is a magic cookie to be returned along with user's
response; in this example 8 octets of data (33 32 37 36 39 34 33 30
in hex).
0b 02 00 4e 36 f3 c8 76 4a e8 c7 11 57 40 3c 0c
71 ff 9c 45 12 30 43 68 61 6c 6c 65 6e 67 65 20
33 32 37 36 39 34 33 30 2e 20 20 45 6e 74 65 72
20 72 65 73 70 6f 6e 73 65 20 61 74 20 70 72 6f
6d 70 74 2e 18 0a 33 32 37 36 39 34 33 30
1 Code = Access-Challenge (11)
1 ID = 2 (same as in Access-Request)
2 Length = 78
16 Response Authenticator
Attributes:
48 Reply-Message (18)
10 State (24)
The user enters his response, and the NAS send a new Access-Request
with that response, and includes the State Attribute.
The Request Authenticator is a new 16 octet random number.
The User-Password is 16 octets of the user's response, in this case
"99101462", padded at the end with nulls, XORed with MD5(shared
secret|Request Authenticator).
The state is the magic cookie from the Access-Challenge packet,
unchanged.
01 03 00 43 b1 22 55 6d 42 8a 13 d0 d6 25 38 07
c4 57 ec f0 01 07 6d 6f 70 73 79 02 12 69 2c 1f
20 5f c0 81 b9 19 b9 51 95 f5 61 a5 81 04 06 c0
a8 01 10 05 06 00 00 00 07 18 10 33 32 37 36 39
34 33 30
1 Code = Access-Request (1)
1 ID = 3 (Note that this changes.)
2 Length = 67
16 Request Authenticator
Attributes:
7 User-Name = "mopsy"
18 User-Password
6 NAS-IP-Address (4) = 192.168.1.16
6 NAS-Port (5) = 7
10 State (24)
The Response was incorrect (for the sake of example), so the RADIUS
server tells the NAS to reject the login attempt.
The Response Authenticator is a 16 octet MD5 checksum of the code
(3), id (3), length(20), the Request Authenticator from above, the
attributes in this reply (in this case, none), and the shared secret.
03 03 00 14 a4 2f 4f ca 45 91 6c 4e 09 c8 34 0f
9e 74 6a a0
1 Code = Access-Reject (3)
1 ID = 3 (same as in Access-Request)
2 Length = 20
16 Response Authenticator
Attributes:
(none, although a Reply-Message could be sent)
8. Security Considerations
Security issues are the primary topic of this document.
In practice, within or associated with each RADIUS server, there is a
database which associates "user" names with authentication
information ("secrets"). It is not anticipated that a particular
named user would be authenticated by multiple methods. This would
make the user vulnerable to attacks which negotiate the least secure
method from among a set. Instead, for each named user there should
be an indication of exactly one method used to authenticate that user
name. If a user needs to make use of different authentication
methods under different circumstances, then distinct user names
SHOULD be employed, each of which identifies exactly one
authentication method.
Passwords and other secrets should be stored at the respective ends
such that access to them is as limited as possible. Ideally, the
secrets should only be accessible to the process requiring access in
order to perform the authentication.
The secrets should be distributed with a mechanism that limits the
number of entities that handle (and thus gain knowledge of) the
secret. Ideally, no unauthorized person should ever gain knowledge
of the secrets. It is possible to achieve this with SNMP Security
Protocols [14], but such a mechanism is outside the scope of this
specification.
Other distribution methods are currently undergoing research and
experimentation. The SNMP Security document [14] also has an
excellent overview of threats to network protocols.
The User-Password hiding mechanism described in Section 5.2 has not
been subjected to significant amounts of cryptanalysis in the
published literature. Some in the IETF community are concerned that
this method might not provide sufficient confidentiality protection
[15] to passwords transmitted using RADIUS. Users should evaluate
their threat environment and consider whether additional security
mechanisms should be employed.
9. Change Log
The following changes have been made from RFC2138:
Strings should use UTF-8 instead of US-ASCII and should be handled as
8-bit data.
Integers and dates are now defined as 32 bit unsigned values.
Updated list of attributes that can be included in Access-Challenge
to be consistent with the table of attributes.
User-Name mentions Network Access Identifiers.
User-Name may now be sent in Access-Accept for use with accounting
and Rlogin.
Values added for Service-Type, Login-Service, Framed-Protocol,
Framed-Compression, and NAS-Port-Type.
NAS-Port can now use all 32 bits.
Examples now include hexadecimal displays of the packets.
Source UDP port must be used in conjunction with the Request
Identifier when identifying duplicates.
Multiple subattributes may be allowed in a Vendor-Specific attribute.
An Access-Request is now required to contain either a NAS-IP-Address
or NAS-Identifier (or may contain both).
Added notes under "Operations" with more information on proxy,
retransmissions, and keep-alives.
If multiple Attributes with the same Type are present, the order of
Attributes with the same Type MUST be preserved by any proxies.
Clarified Proxy-State.
Clarified that Attributes must not depend on position within the
packet, as long as Attributes of the same type are kept in order.
Added IANA Considerations section.
Updated section on "Proxy" under "Operations".
Framed-MTU can now be sent in Access-Request as a hint.
Updated Security Considerations.
Text strings identified as a subset of string, to clarify use of
UTF-8.
10. References
[1] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC2138, April
1997.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March, 1997.
[3] Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm",
RFC1321, April 1992.
[4] Postel, J., "User Datagram Protocol", STD 6, RFC768, August
1980.
[5] Rigney, C., "RADIUS Accounting", RFC2866, June 2000.
[6] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994.
[7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.
[8] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC
2486, January 1999.
[9] Kaufman, C., Perlman, R., and Speciner, M., "Network Security:
Private Communications in a Public World", Prentice Hall, March
1995, ISBN 0-13-061466-1.
[10] Jacobson, V., "Compressing TCP/IP headers for low-speed serial
links", RFC1144, February 1990.
[11] ISO 8859. International Standard -- Information Processing --
8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin
Alphabet No. 1, ISO 8859-1:1987.
[12] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T.
Coradetti, "The PPP Multilink Protocol (MP)", RFC1990, August
1996.
[13] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC2434, October
1998.
[14] Galvin, J., McCloghrie, K. and J. Davin, "SNMP Security
Protocols", RFC1352, July 1992.
[15] Dobbertin, H., "The Status of MD5 After a Recent Attack",
CryptoBytes Vol.2 No.2, Summer 1996.
11. Acknowledgements
RADIUS was originally developed by Steve Willens of Livingston
Enterprises for their PortMaster series of Network Access Servers.
12. Chair's Address
The working group can be contacted via the current chair:
Carl Rigney
Livingston Enterprises
4464 Willow Road
Pleasanton, California 94588
Phone: +1 925 737 2100
EMail: cdr@telemancy.com
13. Authors' Addresses
Questions about this memo can also be directed to:
Carl Rigney
Livingston Enterprises
4464 Willow Road
Pleasanton, California 94588
Phone: +1 925 737 2100
EMail: cdr@telemancy.com
Allan C. Rubens
Merit Network, Inc.
4251 Plymouth Road
Ann Arbor, Michigan 48105-2785
EMail: acr@merit.edu
William Allen Simpson
Daydreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan 48071
EMail: wsimpson@greendragon.com
Steve Willens
Livingston Enterprises
4464 Willow Road
Pleasanton, California 94588
EMail: steve@livingston.com
14. Full Copyright Statement
Copyright (C) The Internet Society (2000). 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.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.