Access-Accept packets. It MAY be used in an Access-Request packet
as a hint by the NAS to the server that it would prefer that
netmask, but the server is not required to honor the hint.
A summary of the Framed-IP-Netmask 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 | Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
9 for Framed-IP-Netmask.
Length
6
Address
The Address field is four octets specifying the IP netmask of the
user.
5.10. Framed-Routing
Description
This Attribute indicates the routing method for the user, when the
user is a router to a network. It is only used in Access-Accept
packets.
A summary of the Framed-Routing 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
10 for Framed-Routing.
Length
6
Value
The Value field is four octets.
0 None
1 Send routing packets
2 Listen for routing packets
3 Send and Listen
5.11. Filter-Id
Description
This Attribute indicates the name of the filter list for this
user. Zero or more Filter-Id attributes MAY be sent in an
Access-Accept packet.
Identifying a filter list by name allows the filter to be used on
different NASes without regard to filter-list implementation
details.
A summary of the Filter-Id 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
11 for Filter-Id.
Length
>= 3
String
The String field is one or more octets, and its contents are
implementation dependent. It is intended to be human readable and
MUST NOT affect operation of the protocol. It is recommended that
the message contain displayable ASCII characters from the range 32
through 126 decimal.
5.12. Framed-MTU
Description
This Attribute indicates the Maximum Transmission Unit to be
configured for the user, when it is not negotiated by some other
means (such as PPP). It is only used in Access-Accept packets.
A summary of the Framed-MTU 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
12 for Framed-MTU.
Length
6
Value
The Value field is four octets. Despite the size of the field,
values range from 64 to 65535.
5.13. Framed-Compression
Description
This Attribute indicates a compression protocol to be used for the
link. It MAY be used in Access-Accept packets. It MAY be used in
an Access-Request packet as a hint to the server that the NAS
would prefer to use that compression, but the server is not
required to honor the hint.
More than one compression protocol Attribute MAY be sent. It is
the responsibility of the NAS to apply the proper compression
protocol to appropriate link traffic.
A summary of the Framed-Compression 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
13 for Framed-Compression.
Length
6
Value
The Value field is four octets.
0 None
1 VJ TCP/IP header compression [5]
2 IPX header compression
5.14. Login-IP-Host
Description
This Attribute indicates the system with which to connect the
user, when the Login-Service Attribute is included. It MAY be
used in Access-Accept packets. It MAY be used in an Access-
Request packet as a hint to the server that the NAS would prefer
to use that host, but the server is not required to honor the
hint.
A summary of the Login-IP-Host 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 | Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
14 for Login-IP-Host.
Length
6
Address
The Address field is four octets. The value 0xFFFFFFFF indicates
that the NAS SHOULD allow the user to select an address. The
value 0 indicates that the NAS SHOULD select a host to connect the
user to. Other values indicate the address the NAS SHOULD connect
the user to.
5.15. Login-Service
Description
This Attribute indicates the service which should be used to
connect the user to the login host. It is only used in Access-
Accept packets.
A summary of the Login-Service 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
15 for Login-Service.
Length
6
Value
The Value field is four octets.
0 Telnet
1 Rlogin
2 TCP Clear
3 PortMaster (proprietary)
4 LAT
5.16. Login-TCP-Port
Description
This Attribute indicates the TCP port with which the user is to be
connected, when the Login-Service Attribute is also present. It
is only used in Access-Accept packets.
A summary of the Login-TCP-Port 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
16 for Login-TCP-Port.
Length
6
Value
The Value field is four octets. Despite the size of the field,
values range from 0 to 65535.
5.17. (unassigned)
Description
ATTRIBUTE TYPE 17 HAS NOT BEEN ASSIGNED.
5.18. Reply-Message
Description
This Attribute indicates text which MAY be displayed to the user.
When used in an Access-Accept, it is the success message.
When used in an Access-Reject, it is the failure message. It MAY
indicate a dialog message to prompt the user before another
Access-Request attempt.
When used in an Access-Challenge, it MAY indicate a dialog message
to prompt the user for a response.
Multiple Reply-Message's MAY be included and if any are displayed,
they MUST be displayed in the same order as they appear in the
packet.
A summary of the Reply-Message 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
18 for Reply-Message.
Length
>= 3
String
The String field is one or more octets, and its contents are
implementation dependent. It is intended to be human readable,
and MUST NOT affect operation of the protocol. It is recommended
that the message contain displayable ASCII characters from the
range 10, 13, and 32 through 126 decimal. Mechanisms for
extension to other character sets are beyond the scope of this
specification.
5.19. Callback-Number
Description
This Attribute indicates a dialing string to be used for callback.
It MAY be used in Access-Accept packets. It MAY be used in an
Access-Request packet as a hint to the server that a Callback
service is desired, but the server is not required to honor the
hint.
A summary of the Callback-Number 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
19 for Callback-Number.
Length
>= 3
String
The String field is one or more octets. The actual format of the
information is site or application specific, and a robust
implementation SHOULD support the field as undistinguished octets.
The codification of the range of allowed usage of this field is
outside the scope of this specification.
5.20. Callback-Id
Description
This Attribute indicates the name of a place to be called, to be
interpreted by the NAS. It MAY be used in Access-Accept packets.
A summary of the Callback-Id 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
20 for Callback-Id.
Length
>= 3
String
The String field is one or more octets. The actual format of the
information is site or application specific, and a robust
implementation SHOULD support the field as undistinguished octets.
The codification of the range of allowed usage of this field is
outside the scope of this specification.
5.21. (unassigned)
Description
ATTRIBUTE TYPE 21 HAS NOT BEEN ASSIGNED.
5.22. Framed-Route
Description
This Attribute provides routing information to be configured for
the user on the NAS. It is used in the Access-Accept packet and
can appear multiple times.
A summary of the Framed-Route 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 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
22 for Framed-Route.
Length
>= 3
String
The String field is one or more octets, and its contents are
implementation dependent. It is intended to be human readable and
MUST NOT affect operation of the protocol. It is recommended that
the message contain displayable ASCII characters from the range 32
through 126 decimal.
For IP routes, it SHOULD contain a destination prefix in dotted
quad form optionally followed by a slash and a decimal length
specifier stating how many high order bits of the prefix should be
used. That is followed by a space, a gateway address in dotted
quad form, a space, and one or more metrics separated by spaces.
For example, "192.168.1.0/24 192.168.1.1 1 2 -1 3 400". The length
specifier may be omitted in which case it should default to 8 bits
for class A prefixes, 16 bits for class B prefixes, and 24 bits
for class C prefixes. For example, "192.168.1.0 192.168.1.1 1".
Whenever the gateway address is specified as "0.0.0.0" the IP
address of the user SHOULD be used as the gateway address.
5.23. Framed-IPX-Network
Description
This Attribute indicates the IPX Network number to be configured
for the user. It is used in Access-Accept packets.
A summary of the Framed-IPX-Network 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
23 for Framed-IPX-Network.
Length
6
Value
The Value field is four octets. The value 0xFFFFFFFE indicates
that the NAS should select an IPX network for the user (e.g.
assigned from a pool of one or more IPX networks kept by the NAS).
Other values should be used as the IPX network for the link to the
user.
5.24. State
Description
This Attribute is available to be sent by the server to the client
in an Access-Challenge and MUST be sent unmodified from the client
to the server in the new Access-Request reply to that challenge,
if any.
This Attribute is available to be sent by the server to the client
in an Access-Accept that also includes a Termination-Action
Attribute with the value of RADIUS-Request. If the NAS performs
the Termination-Action by sending a new Access-Request upon
termination of the current session, it MUST include the State
attribute unchanged in that Access-Request.
In either usage, no interpretation by the client should be made.
A packet may have only one State Attribute. Usage of the State
Attribute is implementation dependent.
A summary of the State 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
24 for State.
Length
>= 3
String
The String field is one or more octets. The actual format of the
information is site or application specific, and a robust
implementation SHOULD support the field as undistinguished octets.
The codification of the range of allowed usage of this field is
outside the scope of this specification.
5.25. Class
Description
This Attribute is available to be sent by the server to the client
in an Access-Accept and should be sent unmodified by the client to
the accounting server as part of the Accounting-Request packet if
accounting is supported. No interpretation by the client should
be made.
A summary of the Class 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
25 for Class.
Length
>= 3
String
The String field is one or more octets. The actual format of the
information is site or application specific, and a robust
implementation SHOULD support the field as undistinguished octets.
The codification of the range of allowed usage of this field is
outside the scope of this specification.
5.26. Vendor-Specific
Description
This Attribute is available to allow vendors to support their own
extended Attributes not suitable for general usage. It MUST not
affect the operation of the RADIUS protocol.
Servers not equipped to interpret the vendor-specific information
sent by a client MUST ignore it (although it may be reported).
Clients which do not receive desired vendor-specific information
SHOULD make an attempt to operate without it, although they may do
so (and report they are doing so) in a degraded mode.
A summary of the Vendor-Specific 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 | Vendor-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont) | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
26 for Vendor-Specific.
Length
>= 7
Vendor-Id
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[3].
String
The String field is one or more octets. The actual format of the
information is site or application specific, and a robust
implementation SHOULD support the field as undistinguished octets.
The codification of the range of allowed usage of this field is
outside the scope of this specification.
It SHOULD be encoded as a sequence of vendor type / vendor length
/ value fields, as follows. The Attribute-Specific field is
dependent on the vendor's definition of that attribute. An
example encoding of the Vendor-Specific attribute using this
method follows:
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 | Vendor-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont) | Vendor type | Vendor length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute-Specific...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
5.27. Session-Timeout
Description
This Attribute sets the maximum number of seconds of service to be
provided to the user before termination of the session or prompt.
This Attribute is available to be sent by the server to the client
in an Access-Accept or Access-Challenge.
A summary of the Session-Timeout 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
27 for Session-Timeout.
Length
6
Value
The field is 4 octets, containing a 32-bit unsigned integer with
the maximum number of seconds this user should be allowed to
remain connected by the NAS.
5.28. Idle-Timeout
Description
This Attribute sets the maximum number of consecutive seconds of
idle connection allowed to the user before termination of the
session or prompt. This Attribute is available to be sent by the
server to the client in an Access-Accept or Access-Challenge.
A summary of the Idle-Timeout 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
28 for Idle-Timeout.
Length
6
Value
The field is 4 octets, containing a 32-bit unsigned integer with
the maximum number of consecutive seconds of idle time this user
should be permitted before being disconnected by the NAS.
5.29. Termination-Action
Description
This Attribute indicates what action the NAS should take when the
specified service is completed. It is only used in Access-Accept
packets.
A summary of the Termination-Action 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
29 for Termination-Action.
Length
6
Value
The Value field is four octets.
0 Default
1 RADIUS-Request
If the Value is set to RADIUS-Request, upon termination of the
specified service the NAS MAY send a new Access-Request to the
RADIUS server, including the State attribute if any.
5.30. Called-Station-Id
Description
This Attribute allows the NAS to send in the Access-Request packet
the phone number that the user called, using Dialed Number
Identification (DNIS) or similar technology. Note that this may be
different from the phone number the call comes in on. It is only
used in Access-Request packets.
A summary of the Called-Station-Id 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
30 for Called-Station-Id.
Length
>= 3
String
The String field is one or more octets, containing the phone
number that the user's call came in on.
The actual format of the information is site or application
specific. Printable ASCII is recommended, but a robust
implementation SHOULD support the field as undistinguished octets.
The codification of the range of allowed usage of this field is
outside the scope of this specification.
5.31. Calling-Station-Id
Description
This Attribute allows the NAS to send in the Access-Request packet
the phone number that the call came from, using Automatic Number
Identification (ANI) or similar technology. It is only used in
Access-Request packets.
A summary of the Calling-Station-Id 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
31 for Calling-Station-Id.
Length
>= 3
String
The String field is one or more octets, containing the phone
number that the user placed the call from.
The actual format of the information is site or application
specific. Printable ASCII is recommended, but a robust
implementation SHOULD support the field as undistinguished octets.
The codification of the range of allowed usage of this field is
outside the scope of this specification.
5.32. NAS-Identifier
Description
This Attribute contains a string identifying the NAS originating
the Access-Request. It is only used in Access-Request packets.
Either NAS-IP-Address or NAS-Identifier SHOULD be present in an
Access-Request packet.
A summary of the NAS-Identifier 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
32 for NAS-Identifier.
Length
>= 3
String
The String field is one or more octets, and should be unique to
the NAS within the scope of the RADIUS server. For example, a
fully qualified domain name would be suitable as a NAS-Identifier.
The actual format of the information is site or application
specific, and a robust implementation SHOULD support the field as
undistinguished octets.
The codification of the range of allowed usage of this field is
outside the scope of this specification.
5.33. Proxy-State
Description
This Attribute is available to be sent by a proxy server to
another server when forwarding an Access-Request and MUST be
returned unmodified in the Access-Accept, Access-Reject or
Access-Challenge. This attribute should be removed by the proxy
server before the response is forwarded to the NAS.
Usage of the Proxy-State Attribute is implementation dependent. A
description of its function is outside the scope of this
specification.
A summary of the Proxy-State 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
33 for Proxy-State.
Length
>= 3
String
The String field is one or more octets. The actual format of the
information is site or application specific, and a robust
implementation SHOULD support the field as undistinguished octets.
The codification of the range of allowed usage of this field is
outside the scope of this specification.
5.34. Login-LAT-Service
Description
This Attribute indicates the system 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.
Administrators use the service attribute when dealing with
clustered systems, such as a VAX or Alpha cluster. In such an
environment several different time sharing hosts share the same
resources (disks, printers, etc.), and administrators often
configure each to offer access (service) to each of the shared
resources. In this case, each host in the cluster advertises its
services through LAT broadcasts.
Sophisticated users often know which service providers (machines)
are faster and tend to use a node name when initiating a LAT
connection. Alternately, some administrators want particular
users to use certain machines as a primitive form of load
balancing (although LAT knows how to do load balancing itself).
A summary of the Login-LAT-Service 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
34 for Login-LAT-Service.
Length
>= 3
String
The String field is one or more octets, and contains the identity
of the LAT service 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 [6]. All LAT string
comparisons are case insensitive.
5.35. Login-LAT-Node
Description
This Attribute indicates the Node with which the user is to be
automatically 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-Node 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
35 for Login-LAT-Node.
Length
>= 3
String
The String field is one or more octets, and contains the identity
of the LAT Node to connect the user to. 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.36. Login-LAT-Group
Description
This Attribute contains a string identifying the LAT group codes
which this user is authorized to use. 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.
LAT supports 256 different group codes, which LAT uses as a form
of access rights. LAT encodes the group codes as a 256 bit
bitmap.
Administrators can assign one or more of the group code bits at
the LAT service provider; it will only accept LAT connections that
have these group codes set in the bit map. The administrators
assign a bitmap of authorized group codes to each user; LAT gets
these from the operating system, and uses these in its requests to
the service providers.
A summary of the Login-LAT-Group 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
36 for Login-LAT-Group.
Length
34
String
The String field is a 32 octet bit map, most significant octet
first. A robust implementation SHOULD support the field as
undistinguished octets.
The codification of the range of allowed usage of this field is
outside the scope of this specification.
5.37. Framed-AppleTalk-Link
Description
This Attribute indicates the AppleTalk network number which should
be used for the serial link to the user, which is another
AppleTalk router. It is only used in Access-Accept packets. It
is never used when the user is not another router.
A summary of the Framed-AppleTalk-Link 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
37 for Framed-AppleTalk-Link.
Length
6
Value
The Value field is four octets. Despite the size of the field,
values range from 0 to 65535. The special value of 0 indicates
that this is an unnumbered serial link. A value of 1-65535 means
that the serial line between the NAS and the user should be
assigned that value as an AppleTalk network number.
5.38. Framed-AppleTalk-Network
Description
This Attribute indicates the AppleTalk Network number which the
NAS should probe to allocate an AppleTalk node for the user. It
is only used in Access-Accept packets. It is never used when the
user is another router. Multiple instances of this Attribute
indicate that the NAS may probe using any of the network numbers
specified.
A summary of the Framed-AppleTalk-Network 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
38 for Framed-AppleTalk-Network.
Length
6
Value
The Value field is four octets. Despite the size of the field,
values range from 0 to 65535. The special value 0 indicates that
the NAS should assign a network for the user, using its default
cable range. A value between 1 and 65535 (inclusive) indicates
the AppleTalk Network the NAS should probe to find an address for
the user.
5.39. Framed-AppleTalk-Zone
Description
This Attribute indicates the AppleTalk Default Zone to be used for
this user. It is only used in Access-Accept packets. Multiple
instances of this attribute in the same packet are not allowed.
A summary of the Framed-AppleTalk-Zone 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 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
39 for Framed-AppleTalk-Zone.
Length
>= 3
String
The name of the Default AppleTalk Zone to be used for this user.
A robust implementation SHOULD support the field as
undistinguished octets.
The codification of the range of allowed usage of this field is
outside the scope of this specification.
5.40. CHAP-Challenge
Description
This Attribute contains the CHAP Challenge sent by the NAS to a
PPP Challenge-Handshake Authentication Protocol (CHAP) user. It
is only used in Access-Request packets.
If the CHAP challenge value is 16 octets long it MAY be placed in
the Request Authenticator field instead of using this attribute.
A summary of the CHAP-Challenge 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 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
60 for CHAP-Challenge.
Length
>= 7
String
The String field contains the CHAP Challenge.
5.41. NAS-Port-Type
Description
This Attribute indicates the type of the physical port of the NAS
which is authenticating the user. It can be used instead of or in
addition to the NAS-Port (5) attribute. It is only used in
Access-Request packets. Either NAS-Port (5) or NAS-Port-Type or
both SHOULD be present in an Access-Request packet, if the NAS
differentiates among its ports.
A summary of the NAS-Port-Type 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
61 for NAS-Port-Type.
Length
6
Value
The Value field is four octets. "Virtual" refers to a connection
to the NAS via some transport protocol, instead of through a
physical port. For example, if a user telnetted into a NAS to
authenticate himself as an Outbound-User, the Access-Request might
include NAS-Port-Type = Virtual as a hint to the RADIUS server
that the user was not on a physical port.
0 Async
1 Sync
2 ISDN Sync
3 ISDN Async V.120
4 ISDN Async V.110
5 Virtual
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 [7] 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
1 0 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
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 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
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
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, and MUST NOT contain 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. 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.
6.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.
Code = 1 (Access-Request)
ID = 0
Length = 56
Request Authenticator = {16 octet random number}
Attributes:
User-Name = "nemo"
User-Password = {16 octets of Password padded at end with nulls,
XORed with MD5(shared secret|Request Authenticator)}
NAS-IP-Address = 192.168.1.16
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.
Code = 2 (Access-Accept)
ID = 0 (same as in Access-Request)
Length = 38
Response Authenticator = {16-octet MD-5 checksum of the code (2),
id (0), Length (38), the Request Authenticator from
above, the attributes in this reply, and the shared
secret}
Attributes:
Service-Type = Login-User
Login-Service = Telnet
Login-Host = 192.168.1.3
6.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.
Code = 1 (Access-Request)
ID = 1
Length = 71
Request Authenticator = {16 octet random number also used as
CHAP challenge}
Attributes:
User-Name = "flopsy"
CHAP-Password = {1 octet CHAP ID followed by 16 octet
CHAP response}
NAS-IP-Address = 192.168.1.16
NAS-Port = 20
Service-Type = Framed-User
Framed-Protocol = PPP
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.
Code = 2 (Access-Accept)
ID = 1 (same as in Access-Request)
Length = 56
Response Authenticator = {16-octet MD-5 checksum of the code (2),
id (1), Length (56), the Request Authenticator from
above, the attributes in this reply, and the shared
secret}
Attributes:
Service-Type = Framed-User
Framed-Protocol = PPP
Framed-IP-Address = 255.255.255.254
Framed-Routing = None
Framed-Compression = 1 (VJ TCP/IP Header Compression)
Framed-MTU = 1500
6.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.
Code = 1 (Access-Request)
ID = 2
Length = 57
Request Authenticator = {16 octet random number}
Attributes:
User-Name = "mopsy"
User-Password = {16 octets of Password padded at end with nulls,
XORed with MD5(shared secret|Request Authenticator)}
NAS-IP-Address = 192.168.1.16
NAS-Port = 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.
Code = 11 (Access-Challenge}
ID = 2 (same as in Access-Request)
Length = 78
Response Authenticator = {16-octet MD-5 checksum of the code (11),
id (2), length (78), the Request Authenticator from
above, the attributes in this reply, and the shared
secret}
Attributes:
Reply-Message = "Challenge 32769430. Enter response at prompt."
State = {Magic Cookie to be returned along with user's response;
in this example 8 octets of data}
The user enters his response, and the NAS send a new Access-Request
with that response, and includes the State Attribute.
Code = 1 (Access-Request)
ID = 3 (Note that this changes)
Length = 67
Request Authenticator = {NEW 16 octet random number}
Attributes:
User-Name = "mopsy"
User-Password = {16 octets of Response padded at end with
nulls, XORed with MD5 checksum of shared secret
plus above Request Authenticator}
NAS-IP-Address = 192.168.1.16
NAS-Port = 7
State = {Magic Cookie from Access-Challenge packet, unchanged}
The Response was incorrect, so the RADIUS server tells the NAS to
reject the login attempt.
Code = 3 (Access-Reject)
ID = 3 (same as in Access-Request)
Length = 20
Response Authenticator = {16-octet MD-5 checksum of the code (3),
id (3), length(20), the Request Authenticator from
above, the attributes in this reply if any, and the
shared secret}
Attributes:
(none, although a Reply-Message could be sent)
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 [8], but such a mechanism is outside the scope of this
specification.
Other distribution methods are currently undergoing research and
experimentation. The SNMP Security document [8] also has an
excellent overview of threats to network protocols.
References
[1] Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm",
RFC1321, MIT Laboratory for Computer Science, RSA Data
Security Inc., April 1992.
[2] Postel, J., "User Datagram Protocol", STD 6, RFC768,
USC/Information Sciences Institute, August 1980.
[3] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1700, USC/Information Sciences Institute, October 1994.
[4] Kaufman, C., Perlman, R., and Speciner, M., "Network Security:
Private Communications in a Public World", Prentice Hall, March
1995, ISBN 0-13-061466-1.
[5] Jacobson, V., "Compressing TCP/IP headers for low-speed serial
links", RFC1144, Lawrence Berkeley Laboratory, February 1990.
[6] ISO 8859. International Standard -- Information Processing --
8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin
Alphabet No. 1, ISO 8859-1:1987.
<URL:http://www.iso.ch/cate/d16338.html>
[7] Sklower, K., Lloyd, B., McGregor, G., and Carr, D., "The PPP
Multilink Protocol (MP)", RFC1717, University of California
Berkeley, Lloyd Internetworking, Newbridge Networks
Corporation, November 1994.
[8] Galvin, J., McCloghrie, K., and Davin, J., "SNMP Security
Protocols", RFC1352, Trusted Information Systems, Inc., Hughes
LAN Systems, Inc., MIT Laboratory for Computer Science, July
1992.
[9] Rigney, C., "RADIUS Accounting", RFC2139, April 1997.
Acknowledgments
RADIUS was originally developed by Livingston Enterprises for their
PortMaster series of Network Access Servers.
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 510 426 0770
EMail: cdr@livingston.com
Authors' Addresses
Questions about this memo can also be directed to:
Carl Rigney
Livingston Enterprises
4464 Willow Road
Pleasanton, California 94588
Phone: +1 510 426 0770
EMail: cdr@livingston.com
Allan C. Rubens
Merit Network, Inc.
4251 Plymouth Road
Ann Arbor, Michigan 48105-2785
EMail: acr@merit.edu