RADIUS Working Group C Rigney
INTERNET-DRAFT Livingston
W Willats
Cyno Technologies
expires in six months January 1997
RADIUS Extensions
draft-ietf-radius-ext-00.txt
Status of this Memo
This document is a submission to the RADIUS Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the ietf-radius@livingston.com mailing list.
Distribution of this memo is unlimited.
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This document describes additional attributes for carrying
authentication, authorization and accounting information between a
Network Access Server (NAS) and a shared Accounting Server using the
Remote Authentication Dial In User Service (RADIUS) protocol
described in RFC 2058 and RFC 2059.
Rigney, et al. expires in six months [Page i]
DRAFT RADIUS Extensions January 1997
Table of Contents
1. Introduction .......................................... 1
1.1 Specification of Requirements ................... 1
1.2 Terminology ..................................... 1
2. Operation ............................................. 2
2.1 RADIUS support for Apple Remote Access .......... 2
3. Packet Format ......................................... 8
4. Packet Types .......................................... 8
5. Attributes ............................................ 8
5.1 Prompt .......................................... 10
5.2 Connect-Info .................................... 10
5.3 Signature ....................................... 11
5.4 EAP-Message ..................................... 12
5.5 Configuration-Token ............................. 13
5.6 Password-Retry .................................. 14
5.7 ARAP-Password ................................... 15
5.8 ARAP-Features ................................... 16
5.9 ARAP-Zone-Access ................................ 17
5.10 ARAP-Security ................................... 18
5.11 ARAP-Security-Data .............................. 18
5.12 Table of Attributes ............................. 19
Security Considerations ...................................... 20
References ................................................... 20
Acknowledgements ............................................. 20
Chair's Address .............................................. 21
Author's Addresses ........................................... 21
Rigney, et al. expires in six months [Page ii]
DRAFT RADIUS Extensions January 1997
1. Introduction
RFC 2058 [1] describes the RADIUS Protocol as it is implemented and
deployed today, and RFC 2059 [2] describes how Accounting can be
performed with RADIUS.
This Internet-Draft suggests several additional Attributes that can
be added to RADIUS to perform various useful functions. These
Attributes do not have extensive field experience yet and should
therefore be considered experimental.
All attributes are comprised of variable length Type-Length-Value
3-tuples. New attribute values can be added without disturbing
existing implementations of the protocol.
1.1. Specification of Requirements
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized.
MUST This word, or the adjective "required", means that the
definition is an absolute requirement of the specification.
MUST NOT This phrase means that the definition is an absolute
prohibition of the specification.
SHOULD This word, or the adjective "recommended", means that there
may exist valid reasons in particular circumstances to
ignore this item, but the full implications must be
understood and carefully weighed before choosing a
different course.
MAY This word, or the adjective "optional", means that this
item is one of an allowed set of alternatives. An
implementation which does not include this option MUST be
prepared to interoperate with another implementation which
does include the option.
1.2. Terminology
This document uses the following terms:
service The NAS provides a service to the dial-in user, such as PPP
or Telnet.
session Each service provided by the NAS to a dial-in user
Rigney, et al. expires in six months [Page 1]
DRAFT RADIUS Extensions January 1997
constitutes a session, with the beginning of the session
defined as the point where service is first provided and
the end of the session defined as the point where service
is ended. A user may have multiple sessions in parallel or
series if the NAS supports that, with each session
generating a separate start and stop accounting record.
silently discard
This means the implementation discards the packet without
further processing. The implementation SHOULD provide the
capability of logging the error, including the contents of
the silently discarded packet, and SHOULD record the event
in a statistics counter.
2. Operation
Operation is identical to that defined in RFC 2058 and 2059.
2.1. RADIUS support for Apple Remote Access
The RADIUS (Remote Authentication Dial-In User Service) protocol
provides a method that allows multiple dial-in Network Access Server
(NAS) devices to share a common authentication database.
The Apple Remote Access Protocol (ARAP) provides a method for sending
AppleTalk network traffic over point-to-point links, typically, but
not exclusively, asynchronous and ISDN switched-circuit connections.
Though Apple is moving toward ATCP on PPP for future remote access
services, ARAP is still a common way for the installed base of
Macintosh users to make remote network connections, and is likely to
remain so for some time.
ARAP is supported by several NAS vendors who also support PPP, IPX
and other protocols in the same NAS. ARAP connections in these
multi-protocol devices are often not authenticated with RADIUS, or if
they are, each vendor creates an individual solution to the problem.
This section describes the use of additional RADIUS attributes to
support ARAP. RADIUS client and server implementations that implement
this specification should be able to authenticate ARAP connections in
an interoperable manner.
This section assumes prior knowledge of RADIUS, and will go into some
detail on the operation of ARAP before entering a detailed discussion
of the proposed ARAP RADIUS attributes.
There are two features of ARAP this document does not address:
Rigney, et al. expires in six months [Page 2]
DRAFT RADIUS Extensions January 1997
1. User initiated password changing. This is not part of RADIUS,
but can be implemented through a software process other than
RADIUS.
2. Out-of-Band messages. At any time, the NAS can send messages to
an ARA client which appear in a dialog box on the dial-in user's
screen. These are not part of authentication and do not belong
here. However, we note that a Reply-Message attribute in an
Access-Accept may be sent down to the user as a sign-on message of
the day string using the out-of-band channel.
We have tried to respect the spirit of the existing RADIUS protocol
as much as possible, making design decisions compatible with prior
art. Further, we have tried to strike a balance between flooding the
RADIUS world with new attributes, and hiding all of ARAP operation
within a single multiplexed ARAP attribute string or within Extended
Authentication Protocol (EAP) [4] machinery.
However, we feel ARAP is enough of a departure from PPP to warrant a
small set of similarly named attributes of its own.
We have assumed that an ARAP-aware RADIUS server will be able to do
DES encryption and generate security module challenges. This is in
keeping with the general RADIUS goal of smart server / simple NAS.
ARAP authenticates a connection in two phases. The first is a "Two-
Way DES" random number exchange, using the user's password as a key.
We say "Two-Way" because the ARAP NAS challenges the dial-in client
to authenticate itself, and the dial-in client challenges the ARAP
NAS to authenticate itself.
Specifically, ARAP does the following:
1. The NAS sends two 32-bit random numbers to the dial-in client
in an ARAP msg_auth_challenge packet.
2. The dial-in client uses the user's password to DES encrypt the
two random numbers sent to it by the NAS. The dial-in client then
sends this result, the user's name and two 32-bit random numbers
of its own back to the NAS in an ARAP msg_auth_request packet.
3. The NAS verifies the encrypted random numbers sent by the
dial-in client are what it expected. If so, it encrypts the dial-
in client's challenge using the password and sends it back to the
dial-in client in an ARAP msg_auth_response packet.
Note that if the dial-in client's response was wrong, meaning the
user has the wrong password, the server can initiate a retry sequence
Rigney, et al. expires in six months [Page 3]
DRAFT RADIUS Extensions January 1997
up to the maximum amount of retries allowed by the NAS. In this case,
when the dial-in client receives the ARAP msg_auth_response packet it
will acknowledge it with an ARAP msg_auth_again packet.
After this first "DES Phase" the ARAP NAS MAY initiate a secondary
authentication phase using what Apple calls "Add-In Security
Modules." Security Modules are small pieces of code which run on both
the client and server and are allowed to read and write arbitrary
data across the communications link to perform additional
authentication functions. Various security token vendors use this
mechanism to authenticate ARA callers.
Although ARAP allows security modules to read and write anything they
like, all existing security modules use simple challenge and response
cycles, with perhaps some overall control information. This document
assumes all existing security modules can be supported with one or
more challenge/response cycles.
To complicate RADIUS and ARAP integration, ARAP sends down some
profile information after the DES Phase and before the Security
Module phase. This means that besides the responses to challenges,
this profile information must also be present, at somewhat unusual
times. Fortunately the information is only a few pieces of numeric
data related to passwords, which this document packs into a single
new attribute.
Presenting an Access-Request to RADIUS on behalf of an ARAP
connection is straightforward. The ARAP NAS generates the random
number challenge, and then receives the dial-in client's response,
the dial-in client's challenge, and the user's name. Assuming the
user is not a guest, the following information is forwarded in an
Access-Request packet: User-Name (up to 31 characters long), Framed-
Protocol (set to 3, ARAP), ARAP-Password, and any additional
attributes desired, such as Service-Type, NAS-IP-Address, NAS-Id,
NAS-Port-Type, NAS-Port, NAS-Port-Id, Connect-Info, etc.
The Request Authenticator is a NAS-generated 16 octet random number.
The low-order 8 octets of this number are sent to the dial-in user as
the two 4 octet random numbers required in the ARAP
msg_auth_challenge packet. Octets 0-3 are the first random number and
Octets 4-7 are the second random number. [Probably needs to make
ordering clearer.]
The ARAP-Password in the Access-Request contains a 16 octet random
number field, and is used to carry the dial-in user's response to the
NAS challenge and the client's own challenge to the NAS. The high-
order octets contain the dial-in user's challenge to the NAS (2 32-
bit numbers, 8 octets) and the low-order octets contain the dial-in
Rigney, et al. expires in six months [Page 4]
DRAFT RADIUS Extensions January 1997
user's response to the NAS challenge (2 32-bit numbers, 8 octets).
Only one of User-Password, CHAP-Password, or ARAP-Password needs to
be present in an Access-Request, or one or more EAP-Messages.
If the RADIUS server does not support ARAP it SHOULD return an
Access-Reject to the NAS.
If the RADIUS server does support ARAP, it should verify the user's
response using the Challenge (from the lower order 8 octets of the
Request Authenticator) and the user's response (from the low order 8
octets of the ARAP-Password).
If that authentication fails, the RADIUS server should return an
Access-Reject packet to the NAS, with optional Password-Retry and
Reply-Messages attributes. The presence of Password-Retry indicates
the ARAP NAS MAY choose to initiate another challenge-response cycle,
up to a total number of times equal to the integer value of the
Password-Retry attribute.
If the user is authenticated, the RADIUS server should return an
Access-Accept packet (Code 2) to the NAS, with ID and Response
Authenticator as usual, and attributes as follows:
Service-Type of Framed-Protocol.
Framed-Protocol of ARAP (3).
Session-Timeout with the maximum connect time for the user in
seconds. If the user is to be given unlimited time, Session-
Timeout should not be included in the Access-Accept packet, and
ARAP will treat that as an unlimited timeout (-1).
ARAP-Challenge-Response, containing 8 octets with the response to
the dial-in client's challenge (the high-order 8 octets of the
ARAP-Password).
ARAP-Features, containing information that the NAS should send to
the user in an ARAP "feature flags" packet.
Octet 0: If zero, user cannot change their password. If non-
zero user can. (RADIUS does not handle the password changing,
just the attribute which indicates whether ARAP indicates they
can.)
Octet 1: Minimum acceptable password length (0-8).
Octet 2-5: Password creation date in Macintosh format, defined
Rigney, et al. expires in six months [Page 5]
DRAFT RADIUS Extensions January 1997
as 32 bits unsigned representing seconds since Midnight GMT
January 1, 1904.
Octet 6-9 Password Expiration Delta from create date in
seconds.
Octet 10-13: Current RADIUS time in Macintosh format
Optionally, a single Reply-Message with a string up to 253
characters long which MAY be sent down to the user to be displayed
in a sign-on/message of the day dialog.
Framed-AppleTalk-Network may be included.
Framed-AppleTalk-Zone, up to 32 characters in length, may be
included.
ARAP defines the notion of a list of zones for a user. Along with
a list of zone names, a Zone Access Flag is defined (and used by
the NAS) which says how to use the list of zone names. That is,
the dial-in user may only be allowed to see the Default Zone, or
only the zones in the zone list (inclusive) or any zone except
those in the zone list (exclusive).
The ARAP NAS handles this by having a named filter which contains
(at least) zone names. This solves the problem where a single
RADIUS server is managing disparate NAS clients who may not be
able to "see" all of the zone names in a user zone list. Zone
names only have meaning "at the NAS." The disadvantage of this
approach is that zone filters must be set up on the NAS somehow,
then referenced by the RADIUS Filter-Id.
ARAP-Zone-Access contains an integer which specifies how the "zone
list" for this user should be used. If this attribute is present
and the value is 2 or 4 then a Filter-Id must also be present to
name a zone list filter to apply the access flag to.
The inclusion of a Callback-Number or Callback-Id attribute in the
Access-Accept MAY cause the ARAP NAS to disconnect after sending
the Feature Flags to begin callback processing in an ARAP specific
way.
Other attributes may be present in the Access-Accept packet as well.
An ARAP NAS will need other information to finish bringing up the
connection to the dial in client, but this information can be
provided by the ARAP NAS without any help from RADIUS, either through
configuration by SNMP, a NAS administration program, or deduced by
Rigney, et al. expires in six months [Page 6]
DRAFT RADIUS Extensions January 1997
the AppleTalk stack in the NAS. Specifically:
1. AppearAsNet and AppearAsNode values, sent to the client to tell
it what network and node numbers it should use in its datagram
packets. AppearAsNet can be taken from the Framed-AppleTalk-
Network attribute or from the configuration or AppleTalk stack on
the NAS.
2. The "default" zone - that is the name of the AppleTalk zone in
which the dial-in client will appear. (Or can be specified with
the Framed-AppleTalk-Zone attribute.)
3. Other very NAS specific stuff such as the name of the NAS, and
smartbuffering information. (Smartbuffering is an ARAP mechanism
for replacing common AppleTalk datagrams with small tokens, to
improve slow link performance in a few common traffic situations.)
4. "Zone List" information for this user. The ARAP specification
defines a "zone count" field which is actually unused.
RADIUS supports ARAP Security Modules in the following manner.
After DES authentication has been completed, the RADIUS server may
instruct the ARAP NAS to run one or more security modules for the
dial-in user. Although the underlying protocol supports executing
multiple security modules in series, in practice all current
implementations only allow executing one. Through the use of
multiple Access-Challenge requests, multiple modules can be
supported, but this facility will probably never be used.
We also assume that, even though ARAP allows a free-form dialog
between security modules on each end of the point-to-point link, in
actual practice all security modules can be reduced to a simple
challenge/response cycle.
If the RADIUS server wishes to instruct the ARAP NAS to run a
security module, it should send an Access-Challenge packet to the NAS
with (optionally) the State attribute, plus the ARAP-Challenge-
Response, ARAP-Features, and two more attributes:
ARAP-Security: a four octet security module signature, containing a
Macintosh OSType.
ARAP-Security-Data, a string to carry the actual security module
challenge and response.
When the security module finishes executing, the security module
response is passed in an ARAP-Security-Data attribute from the NAS
Rigney, et al. expires in six months [Page 7]
DRAFT RADIUS Extensions January 1997
to the RADIUS server in a second Access-Request, also including the
State from the Access-Challenge. The authenticator field contains no
special information in this case, and this can be discerned by the
presence of the State attribute.
3. Packet Format
Packet Format is identical to that defined in RFC 2058 and 2059.
4. Packet Types
Packet types are identical to those defined in RFC 2058 and 2059.
See "Table of Attributes" below to determine which types of packets
can contain which attributes defined here.
5. Attributes
RADIUS Attributes carry the specific authentication, authorization
and accounting details for the request and response.
Some attributes MAY be included more than once. The effect of this
is attribute specific, and is specified in each attribute
description. The order of attributes of the same type SHOULD be
preserved. The order of attributes of different types is not
required to be preserved.
The end of the list of attributes is indicated by the Length of the
RADIUS packet.
A summary of the attribute format is the same as in RFC 2058 but is
included here for ease of reference. 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 | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
The Type field is one octet. Up-to-date values of the RADIUS Type
field are specified in the most recent "Assigned Numbers" RFC [2].
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. This specification concerns
Rigney, et al. expires in six months [Page 8]
DRAFT RADIUS Extensions January 1997
the following values:
1-39 (refer to RFC 2058, "RADIUS")
40-51 (refer to RFC 2059, "RADIUS Accounting")
52-59 Unused
60-63 (refer to RFC 2058, "RADIUS")
64 Prompt
65 Connect-Info
66 Signature
67 EAP-Message
68 Configuration-Token
69 Password-Retry
70 ARAP-Password
71 ARAP-Features
72 ARAP-Zone-Access
73 ARAP-Security
74 ARAP-Security-Data
75-191 Unused
Length
The Length field is one octet, and indicates the length of this
attribute including the Type, Length and Value fields. If an
attribute is received in a packet with an invalid Length, the
entire request should be silently discarded.
Value
The Value field is zero or more octets and contains information
specific to the attribute. The format and length of the Value
field is determined by the Type and Length fields.
The format of the value field is one of four data types.
string 0-253 octets
address 32 bit value, most significant octet first.
integer 32 bit value, most significant octet first.
time 32 bit value, most significant octet first -- seconds
since 00:00:00 GMT, January 1, 1970. The standard
Attributes do not use this data type.
Rigney, et al. expires in six months [Page 9]
DRAFT RADIUS Extensions January 1997
5.1. Prompt
Description
This attribute is used only in Access-Challenge packets, and
indicates to the NAS whether it should echo the user's response as
it is entered, or not echo it.
A summary of the Prompt 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
64 for Prompt.
Length
6
Value
The Value field is four octets.
0 No Echo
1 Echo
5.2. Connect-Info
Description
This attribute is sent from the NAS to indicate the nature of the
user's connection.
The NAS MAY send this attribute in an Access-Request or
Accounting-Request to indicate the nature of the user's
Rigney, et al. expires in six months [Page 10]
DRAFT RADIUS Extensions January 1997
connection.
A summary of the Connect-Info 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
65 for Connect-Info.
Length
>= 3
String
The String field is encoded as a ASCII characters with the
connection speed at the beginning of the string.
For example, "28800 V42BIS/LAPM"
5.3. Signature
Description
This attribute MAY be used to sign Access-Requests to prevent
dictionary attacks on CHAP, ARAP or EAP authentication methods.
It MAY be used in any Access-Request.
A RADIUS Server receiving an Access-Request with a Signature
Attribute present SHOULD calculate the correct value of the
Signature and silently discard the packet if it does not match the
value sent.
A summary of the Signature attribute format is shown below. The
fields are transmitted from left to right.
Rigney, et al. expires in six months [Page 11]
DRAFT RADIUS Extensions January 1997
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
66 for Signature.
Length
18
String
Signature is an MD-5 [3] checksum of the shared secret followed by
the entire Access-Request packet, including Type, ID, Length and
authenticator. When the checksum is calculated the signature
string should be considered to be sixteen octets of zero.
This attribute is not needed if the User-Password attribute is
present, but is useful for preventing dictionary attacks on other
types of authentication. IP Security will eventually make this
attribute unnecessary, so it should be considered an interim
measure.
5.4. EAP-Message
Description
This attribute opaquely encodes Extended Access Protocol [4]
information to allow dial-in users to use EAP to authenticate
without having to implement EAP on the NAS.
The NAS places any EAP messages received from the user into one or
more EAP attributes and forwards them to the RADIUS Server as part
of the Access-Request, which can return EAP messages in Access-
Challenge, Access-Accept and Access-Reject packets.
A RADIUS Server receiving EAP messages that it does not understand
SHOULD return an Access-Reject.
A summary of the EAP-Message attribute format is shown below. The
Rigney, et al. expires in six months [Page 12]
DRAFT RADIUS Extensions January 1997
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
67 for EAP-Message.
Length
>= 3.
String
The String field contains undifferentiated octets. If multiple
EAP-Message attributes are present in a packet their values should
be concatenated; this allows EAP packets longer than 253 octets to
be passed by RADIUS.
5.5. Configuration-Token
Description
This attribute is for use in large distributed authentication
networks based on proxy. It is sent from a RADIUS Proxy Server to
a RADIUS Proxy Client in an Access-Request to indicate a type of
user profile to be used. It should not be sent to a NAS.
A summary of the Configuration-Token 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
68 for Configuration-Token.
Rigney, et al. expires in six months [Page 13]
DRAFT RADIUS Extensions January 1997
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.6. Password-Retry
Description
This attribute MAY be included in an Access-Reject to indicate how
many authentication attempts a user may be allowed to attempt
before being disconnected.
It is primarily intended for use with ARAP authentication.
A summary of the Password-Retry 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
69 for Password-Retry.
Length
6
Value
The Value field is four octets, containing an integer specifying
Rigney, et al. expires in six months [Page 14]
DRAFT RADIUS Extensions January 1997
the number of password retry attempts to permit the user.
5.7. ARAP-Password
Description
This attribute is only present in an Access-Request packet
containing a Framed-Protocol of ARAP.
Only one of User-Password, CHAP-Password, or ARAP-Password needs
to be present in an Access-Request, or one or more EAP-Messages.
A summary of the ARAP-Password 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 | Value1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
70 for ARAP-Password.
Length
18
Value
This attribute contains a 16 octet string, used to carry the
dial-in user's response to the NAS challenge and the client's own
challenge to the NAS. The high-order octets (Value1 and Value2)
contain the dial-in user's challenge to the NAS (2 32-bit numbers,
8 octets) and the low-order octets (Value3 and Value4) contain the
dial-in user's response to the NAS challenge (2 32-bit numbers, 8
octets).
Rigney, et al. expires in six months [Page 15]
DRAFT RADIUS Extensions January 1997
5.8. ARAP-Features
Description
This attribute is sent in an Access-Accept packet with Framed-
Protocol of ARAP, and includes password information that the NAS
should sent to the user in an ARAP "feature flags" packet.
A summary of the ARAP-Features 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 | Value1 | Value2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
71 for ARAP-Features.
Length
16
Value
The Value field is a compound string containing information the
NAS should send to the user in the ARAP "feature flags" packet.
Value1: If zero, user cannot change their password. If non-zero
user can. (RADIUS does not handle the password changing, just
the attribute which indicates whether ARAP indicates they can.)
Value2: Minimum acceptable password length, from 0 to 8.
Value3: Password creation date in Macintosh format, defined as
Rigney, et al. expires in six months [Page 16]
DRAFT RADIUS Extensions January 1997
32 unsigned bits representing seconds since Midnight GMT
January 1, 1904.
Value4: Password Expiration Delta from create date in seconds.
Value5: Current RADIUS time in Macintosh format.
5.9. ARAP-Zone-Access
Description
This attribute is included in an Access-Accept packet with
Framed-Protocol of ARAP to indicate how the ARAP zone list for the
user should be used.
A summary of the ARAP-Zone-Access 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
72 for ARAP-Zone-Access.
Length
6
Value
The Value field is four octets encoding an integer with one of the
following values:
1 Only allow access to default zone
2 Use zone filter inclusively
4 Use zone filter exclusively
The value 3 is skipped, not because these are bit flags, but
Rigney, et al. expires in six months [Page 17]
DRAFT RADIUS Extensions January 1997
because 3 in some ARAP implementations means "all zones" which is
the same as not specifying a list at all under RADIUS.
If this attribute is present and the value is 2 or 4 then a
Filter-Id must also be present to name a zone list filter to apply
the access flag to.
5.10. ARAP-Security
Description
This attribute identifies the ARAP Security Module to be used in
an Access-Challenge packet.
A summary of the ARAP-Security 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
73 for ARAP-Security.
Length
6
Value
The Value field is four octets, containing an integer specifying
the security module signature, which is a Macintosh OSType.
(Macintosh OSTypes are 4 ascii characters cast as a 32-bit
integer)
5.11. ARAP-Security-Data
Description
Rigney, et al. expires in six months [Page 18]
DRAFT RADIUS Extensions January 1997
This attribute contains the actual security module challenge or
response, and can be found in Access-Challenge and Access-Request
packets.
A summary of the ARAP-Security-Data 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
74 for ARAP-Security-Data.
Length
>=3
String
The String field contains the security module challenge or
response associated with the ARAP Security Module specified in
ARAP-Security.
5.12. Table of Attributes
The following table provides a guide to which attributes may be found
in which kind of packets. Connect-Info may have 0-1 instances in an
Accounting-Request packet, the other attributes added in this
document must not be present in an Accounting-Request.
Request Accept Reject Challenge # Attribute
0 0 0 0-1 64 Prompt
0-1 0 0 0 65 Connect-Info
0-1 0 0 0 66 Signature
0+ 0+ 0+ 0+ 67 EAP-Message [Note 1]
0 0+ 0 0 68 Configuration-Token
0 0 0-1 0 69 Password-Retry
0-1 0 0 0 70 ARAP-Password [Note 1]
0 0-1 0 0-1 71 ARAP-Features
0 0-1 0 0 72 ARAP-Zone-Access
Rigney, et al. expires in six months [Page 19]
DRAFT RADIUS Extensions January 1997
0-1 0 0 0-1 73 ARAP-Security
0+ 0 0 0+ 73 ARAP-Security-Data
Request Accept Reject Challenge # Attribute
[Note 1] An Access-Request MUST contain either a User-Password or
CHAP-Password or ARAP-Password or one or more EAP-Messages, and MUST
NOT contain more than one type of those four attributes.
The following table defines the above table entries.
0 This attribute MUST NOT be present
0+ Zero or more instances of this attribute MAY be present.
0-1 Zero or one instance of this attribute MAY be present.
1 Exactly one instance of this attribute MUST be present.
Security Considerations
Security issues are the primary topic of this document.
References
[1] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2058,
January 1997.
[2] Rigney, C., "RADIUS Accounting", RFC 2059, January 1997.
[3] Rivest, R., and Dusse, S., "The MD5 Message-Digest Algorithm",
RFC 1321, MIT Laboratory for Computer Science, RSA Data
Security Inc., April 1992.
[4] Blunk, L., and Vollbrecht, J., "PPP Extensible Authentication
Protocol (EAP)", draft-ietf-pppext-eap-auth-02.txt, June 1996.
Acknowledgments
RADIUS and RADIUS Accounting were originally developed by Livingston
Enterprises for their PortMaster series of Network Access Servers.
The section on ARAP is adopted with permission from "Using RADIUS to
Authenticate Apple Remote Access Connections" by Ward Willats of Cyno
Technologies (ward@cyno.com).
Rigney, et al. expires in six months [Page 20]
DRAFT RADIUS Extensions January 1997
Chair's Address
The RADIUS working group can be contacted via the current chair:
Carl Rigney
Livingston Enterprises
4464 Willow Road
Pleasanton, California 94588
Phone: +1 510 426 0770
E-Mail: cdr@livingston.com
Author's Addresses
Questions about this memo can also be directed to:
Carl Rigney
Livingston Enterprises
4464 Willow Road
Pleasanton, California 94566
E-Mail: cdr@livingston.com
Questions on ARAP and RADIUS may be directed to:
Ward Willats
Cyno Technologies
1082 Glen Echo Ave
San Jose, CA 95125
Phone: +1 408 297 7766
Email: ward@cyno.com
Rigney, et al. expires in six months [Page 21]
