draft-ietf-radius-ext-06.txt   rfc2869.txt 
RADIUS Working Group C Rigney
INTERNET-DRAFT Livingston Network Working Group C. Rigney
W Willats Request for Comments: 2869 Livingston
Cyno Technologies Category: Informational W. Willats
P Calhoun Cyno Technologies
Sun Microsystems P. Calhoun
expires August 2000 February 2000 Sun Microsystems
June 2000
RADIUS Extensions RADIUS Extensions
draft-ietf-radius-ext-06.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This memo provides information for the Internet community. It does
all provisions of Section 10 of RFC 2026. not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
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.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract Abstract
This document describes additional attributes for carrying This document describes additional attributes for carrying
authentication, authorization and accounting information between a authentication, authorization and accounting information between a
Network Access Server (NAS) and a shared Accounting Server using the Network Access Server (NAS) and a shared Accounting Server using the
Remote Authentication Dial In User Service (RADIUS) protocol Remote Authentication Dial In User Service (RADIUS) protocol
described in RFC xxxx [1] and RFC yyyy [2]. described in RFC 2865 [1] and RFC 2866 [2].
Table of Contents Table of Contents
1. Introduction .......................................... 4 1. Introduction .......................................... 2
1.1 Specification of Requirements ................... 4 1.1 Specification of Requirements ................... 3
1.2 Terminology ..................................... 4 1.2 Terminology ..................................... 3
2. Operation ............................................. 4
2. Operation ............................................. 5 2.1 RADIUS support for Interim Accounting Updates.... 4
2.1 RADIUS support for Interim Accounting Updates 2.2 RADIUS support for Apple Remote Access
2.2 RADIUS support for Apple Remote Access Protocol ........................................ 5
Protocol ........................................ 6 2.3 RADIUS Support for Extensible Authentication
2.3 RADIUS Support for Extensible Authentication Protocol (EAP) .................................. 11
Protocol (EAP) .................................. 12 2.3.1 Protocol Overview ............................... 11
2.3.1 Protocol Overview ............................... 12 2.3.2 Retransmission .................................. 13
2.3.2 Retransmission .................................. 14 2.3.3 Fragmentation ................................... 14
2.3.3 Fragmentation ................................... 15 2.3.4 Examples ........................................ 14
2.3.4 Examples ........................................ 15 2.3.5 Alternative uses ................................ 19
2.3.5 Alternative uses ................................ 20 3. Packet Format ......................................... 19
4. Packet Types .......................................... 19
3. Packet Format ......................................... 20 5. Attributes ............................................ 20
5.1 Acct-Input-Gigawords ............................ 22
4. Packet Types .......................................... 20 5.2 Acct-Output-Gigawords ........................... 23
5.3 Event-Timestamp ................................. 23
5. Attributes ............................................ 20 5.4 ARAP-Password ................................... 24
5.1 Acct-Input-Gigawords ............................ 23 5.5 ARAP-Features ................................... 25
5.2 Acct-Output-Gigawords ........................... 23 5.6 ARAP-Zone-Access ................................ 26
5.3 Event-Timestamp ................................. 24 5.7 ARAP-Security ................................... 27
5.4 ARAP-Password ................................... 25 5.8 ARAP-Security-Data .............................. 28
5.5 ARAP-Features ................................... 26 5.9 Password-Retry .................................. 28
5.6 ARAP-Zone-Access ................................ 27 5.10 Prompt .......................................... 29
5.7 ARAP-Security ................................... 28 5.11 Connect-Info .................................... 30
5.8 ARAP-Security-Data .............................. 29 5.12 Configuration-Token ............................. 31
5.9 Password-Retry .................................. 29 5.13 EAP-Message ..................................... 32
5.10 Prompt .......................................... 30 5.14 Message-Authenticator ........................... 33
5.11 Connect-Info .................................... 31 5.15 ARAP-Challenge-Response ......................... 35
5.12 Configuration-Token ............................. 32 5.16 Acct-Interim-Interval ........................... 36
5.13 EAP-Message ..................................... 33 5.17 NAS-Port-Id ..................................... 37
5.14 Message-Authenticator ........................... 34 5.18 Framed-Pool ..................................... 37
5.15 ARAP-Challenge-Response ......................... 36 5.19 Table of Attributes ............................. 38
5.16 Acct-Interim-Interval ........................... 37 6. IANA Considerations ................................... 39
5.17 NAS-Port-Id ..................................... 38 7. Security Considerations ............................... 39
5.18 Framed-Pool ..................................... 39 7.1 Message-Authenticator Security .................. 39
5.19 Table of Attributes ............................. 40 7.2 EAP Security .................................... 39
7.2.1 Separation of EAP server and PPP authenticator .. 40
6. IANA Considerations ................................... 41 7.2.2 Connection hijacking ............................ 41
7.2.3 Man in the middle attacks ....................... 41
7. Security Considerations ............................... 41 7.2.4 Multiple databases .............................. 41
7.1 Message-Authenticator Security .................. 41 7.2.5 Negotiation attacks ............................. 42
7.2 EAP Security .................................... 41 8. References ............................................ 43
7.2.1 Separation of EAP server and PPP authenticator 9. Acknowledgements ...................................... 44
7.2.2 Connection hijacking ............................ 43 10. Chair's Address ....................................... 44
7.2.3 Man in the middle attacks ....................... 43 11. Authors' Addresses .................................... 45
7.2.4 Multiple databases .............................. 43 12. Full Copyright Statement .............................. 47
7.2.5 Negotiation attacks ............................. 44
8. References ............................................ 45
9. Acknowledgements ...................................... 46
10. Chair's Address ....................................... 46
11. Author's Address ...................................... 47
12. Full Copyright Statement .............................. 48
1. Introduction 1. Introduction
RFC xxxx [1] describes the RADIUS Protocol as it is implemented and RFC 2865 [1] describes the RADIUS Protocol as it is implemented and
deployed today, and RFC yyyy [2] describes how Accounting can be deployed today, and RFC 2866 [2] describes how Accounting can be
performed with RADIUS. performed with RADIUS.
This memo suggests several additional Attributes that can be added to This memo suggests several additional Attributes that can be added to
RADIUS to perform various useful functions. These Attributes do not RADIUS to perform various useful functions. These Attributes do not
have extensive field experience yet and should therefore be have extensive field experience yet and should therefore be
considered experimental. considered experimental.
The Extensible Authentication Protocol (EAP) [3] is a PPP extension The Extensible Authentication Protocol (EAP) [3] is a PPP extension
that provides support for additional authentication methods within that provides support for additional authentication methods within
PPP. This memo describes how the EAP-Message and Message- PPP. This memo describes how the EAP-Message and Message-
skipping to change at page 5, line 23 skipping to change at page 4, line 17
silently discard silently discard
This means the implementation discards the packet without This means the implementation discards the packet without
further processing. The implementation SHOULD provide the further processing. The implementation SHOULD provide the
capability of logging the error, including the contents of capability of logging the error, including the contents of
the silently discarded packet, and SHOULD record the event the silently discarded packet, and SHOULD record the event
in a statistics counter. in a statistics counter.
2. Operation 2. Operation
Operation is identical to that defined in RFC xxxx [1] and RFC yyyy Operation is identical to that defined in RFC 2865 [1] and RFC 2866
[2]. [2].
2.1. RADIUS support for Interim Accounting Updates 2.1. RADIUS support for Interim Accounting Updates
When a user is authenticated, a RADIUS server issues an Access-Accept When a user is authenticated, a RADIUS server issues an Access-Accept
in response to a successful Access-Request. If the server wishes to in response to a successful Access-Request. If the server wishes to
receive interim accounting messages for the given user it must receive interim accounting messages for the given user it must
include the Acct-Interim-Interval RADIUS attribute in the message, include the Acct-Interim-Interval RADIUS attribute in the message,
which indicates the interval in seconds between interim messages. which indicates the interval in seconds between interim messages.
skipping to change at page 6, line 50 skipping to change at page 5, line 46
this specification should be able to authenticate ARAP connections in this specification should be able to authenticate ARAP connections in
an interoperable manner. an interoperable manner.
This section assumes prior knowledge of RADIUS, and will go into some This section assumes prior knowledge of RADIUS, and will go into some
detail on the operation of ARAP before entering a detailed discussion detail on the operation of ARAP before entering a detailed discussion
of the proposed ARAP RADIUS attributes. of the proposed ARAP RADIUS attributes.
There are two features of ARAP this document does not address: There are two features of ARAP this document does not address:
1. User initiated password changing. This is not part of RADIUS, 1. User initiated password changing. This is not part of RADIUS,
but can be implemented through a software process other than but can be implemented through a software process other than
RADIUS. RADIUS.
2. Out-of-Band messages. At any time, the NAS can send messages to 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 an ARA client which appear in a dialog box on the dial-in
screen. These are not part of authentication and do not belong user's screen. These are not part of authentication and do not
here. However, we note that a Reply-Message attribute in an belong here. However, we note that a Reply-Message attribute in
Access-Accept may be sent down to the user as a sign-on message of an Access-Accept may be sent down to the user as a sign-on
the day string using the out-of-band channel. message of the day string using the out-of-band channel.
We have tried to respect the spirit of the existing RADIUS protocol We have tried to respect the spirit of the existing RADIUS protocol
as much as possible, making design decisions compatible with prior as much as possible, making design decisions compatible with prior
art. Further, we have tried to strike a balance between flooding the art. Further, we have tried to strike a balance between flooding the
RADIUS world with new attributes, and hiding all of ARAP operation RADIUS world with new attributes, and hiding all of ARAP operation
within a single multiplexed ARAP attribute string or within Extended within a single multiplexed ARAP attribute string or within Extended
Authentication Protocol (EAP) [3] machinery. Authentication Protocol (EAP) [3] machinery.
However, we feel ARAP is enough of a departure from PPP to warrant a However, we feel ARAP is enough of a departure from PPP to warrant a
small set of similarly named attributes of its own. small set of similarly named attributes of its own.
skipping to change at page 7, line 35 skipping to change at page 6, line 30
ARAP authenticates a connection in two phases. The first is a "Two- 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. 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 We say "Two-Way" because the ARAP NAS challenges the dial-in client
to authenticate itself, and the dial-in client challenges the ARAP to authenticate itself, and the dial-in client challenges the ARAP
NAS to authenticate itself. NAS to authenticate itself.
Specifically, ARAP does the following: Specifically, ARAP does the following:
1. The NAS sends two 32-bit random numbers to the dial-in client 1. The NAS sends two 32-bit random numbers to the dial-in client
in an ARAP msg_auth_challenge packet. in an ARAP msg_auth_challenge packet.
2. The dial-in client uses the user's password to DES encrypt the 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 two random numbers sent to it by the NAS. The dial-in client
sends this result, the user's name and two 32-bit random numbers then sends this result, the user's name and two 32-bit random
of its own back to the NAS in an ARAP msg_auth_request packet. 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 3. The NAS verifies the encrypted random numbers sent by the
dial-in client are what it expected. If so, it encrypts the dial- dial-in client are what it expected. If so, it encrypts the
in client's challenge using the password and sends it back to the dial-in client's challenge using the password and sends it back
dial-in client in an ARAP msg_auth_response packet. 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 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 user has the wrong password, the server can initiate a retry sequence
up to the maximum amount of retries allowed by the NAS. In this case, 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 when the dial-in client receives the ARAP msg_auth_response packet it
will acknowledge it with an ARAP msg_auth_again packet. will acknowledge it with an ARAP msg_auth_again packet.
After this first "DES Phase" the ARAP NAS MAY initiate a secondary After this first "DES Phase" the ARAP NAS MAY initiate a secondary
authentication phase using what Apple calls "Add-In Security authentication phase using what Apple calls "Add-In Security
Modules." Security Modules are small pieces of code which run on both Modules." Security Modules are small pieces of code which run on
the client and server and are allowed to read and write arbitrary both the client and server and are allowed to read and write
data across the communications link to perform additional arbitrary data across the communications link to perform additional
authentication functions. Various security token vendors use this authentication functions. Various security token vendors use this
mechanism to authenticate ARA callers. mechanism to authenticate ARA callers.
Although ARAP allows security modules to read and write anything they Although ARAP allows security modules to read and write anything they
like, all existing security modules use simple challenge and response like, all existing security modules use simple challenge and response
cycles, with perhaps some overall control information. This document cycles, with perhaps some overall control information. This document
assumes all existing security modules can be supported with one or assumes all existing security modules can be supported with one or
more challenge/response cycles. more challenge/response cycles.
To complicate RADIUS and ARAP integration, ARAP sends down some To complicate RADIUS and ARAP integration, ARAP sends down some
skipping to change at page 8, line 32 skipping to change at page 7, line 28
this profile information must also be present, at somewhat unusual this profile information must also be present, at somewhat unusual
times. Fortunately the information is only a few pieces of numeric times. Fortunately the information is only a few pieces of numeric
data related to passwords, which this document packs into a single data related to passwords, which this document packs into a single
new attribute. new attribute.
Presenting an Access-Request to RADIUS on behalf of an ARAP Presenting an Access-Request to RADIUS on behalf of an ARAP
connection is straightforward. The ARAP NAS generates the random connection is straightforward. The ARAP NAS generates the random
number challenge, and then receives the dial-in client's response, number challenge, and then receives the dial-in client's response,
the dial-in client's challenge, and the user's name. Assuming the 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 user is not a guest, the following information is forwarded in an
Access-Request packet: User-Name (up to 31 characters long), Framed- Access-Request packet: User-Name (up to 31 characters long),
Protocol (set to 3, ARAP), ARAP-Password, and any additional Framed-Protocol (set to 3, ARAP), ARAP-Password, and any additional
attributes desired, such as Service-Type, NAS-IP-Address, NAS-Id, attributes desired, such as Service-Type, NAS-IP-Address, NAS-Id,
NAS-Port-Type, NAS-Port, NAS-Port-Id, Connect-Info, etc. NAS-Port-Type, NAS-Port, NAS-Port-Id, Connect-Info, etc.
The Request Authenticator is a NAS-generated 16 octet random number. 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 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 the two 4 octet random numbers required in the ARAP
msg_auth_challenge packet. Octets 0-3 are the first random number and msg_auth_challenge packet. Octets 0-3 are the first random number and
Octets 4-7 are the second random number. Octets 4-7 are the second random number.
The ARAP-Password in the Access-Request contains a 16 octet random The ARAP-Password in the Access-Request contains a 16 octet random
skipping to change at page 9, line 29 skipping to change at page 8, line 26
If the user is authenticated, the RADIUS server should return an If the user is authenticated, the RADIUS server should return an
Access-Accept packet (Code 2) to the NAS, with ID and Response Access-Accept packet (Code 2) to the NAS, with ID and Response
Authenticator as usual, and attributes as follows: Authenticator as usual, and attributes as follows:
Service-Type of Framed-Protocol. Service-Type of Framed-Protocol.
Framed-Protocol of ARAP (3). Framed-Protocol of ARAP (3).
Session-Timeout with the maximum connect time for the user in Session-Timeout with the maximum connect time for the user in
seconds. If the user is to be given unlimited time, Session- seconds. If the user is to be given unlimited time,
Timeout should not be included in the Access-Accept packet, and Session-Timeout should not be included in the Access-Accept
ARAP will treat that as an unlimited timeout (-1). packet, and ARAP will treat that as an unlimited timeout (-1).
ARAP-Challenge-Response, containing 8 octets with the response to ARAP-Challenge-Response, containing 8 octets with the response to
the dial-in client's challenge. The RADIUS server calculates this the dial-in client's challenge. The RADIUS server calculates this
value by taking the dial-in client's challenge from the high order value by taking the dial-in client's challenge from the high order
8 octets of the ARAP-Password attribute and performing DES 8 octets of the ARAP-Password attribute and performing DES
encryption on this value with the authenticating user's password encryption on this value with the authenticating user's password
as the key. If the user's password is less than 8 octets in as the key. If the user's password is less than 8 octets in
length, the password is padded at the end with NULL octets to a length, the password is padded at the end with NULL octets to a
length of 8 before using it as a key. If the user's password is length of 8 before using it as a key. If the user's password is
greater than 8 octets in length, an Access-Reject MUST be sent greater than 8 octets in length, an Access-Reject MUST be sent
skipping to change at page 10, line 14 skipping to change at page 9, line 14
Octet 2-5: Password creation date in Macintosh format, defined Octet 2-5: Password creation date in Macintosh format, defined
as 32 bits unsigned representing seconds since Midnight GMT as 32 bits unsigned representing seconds since Midnight GMT
January 1, 1904. January 1, 1904.
Octet 6-9 Password Expiration Delta from create date in Octet 6-9 Password Expiration Delta from create date in
seconds. seconds.
Octet 10-13: Current RADIUS time in Macintosh format Octet 10-13: Current RADIUS time in Macintosh format
Optionally, a single Reply-Message with a string up to 253 Optionally, a single Reply-Message with a text string up to 253
characters long which MAY be sent down to the user to be displayed characters long which MAY be sent down to the user to be displayed
in a sign-on/message of the day dialog. in a sign-on/message of the day dialog.
Framed-AppleTalk-Network may be included. Framed-AppleTalk-Network may be included.
Framed-AppleTalk-Zone, up to 32 characters in length, may be Framed-AppleTalk-Zone, up to 32 characters in length, may be
included. included.
ARAP defines the notion of a list of zones for a user. Along with 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 a list of zone names, a Zone Access Flag is defined (and used by
skipping to change at page 11, line 8 skipping to change at page 10, line 14
Other attributes may be present in the Access-Accept packet as well. Other attributes may be present in the Access-Accept packet as well.
An ARAP NAS will need other information to finish bringing up the An ARAP NAS will need other information to finish bringing up the
connection to the dial in client, but this information can be connection to the dial in client, but this information can be
provided by the ARAP NAS without any help from RADIUS, either through provided by the ARAP NAS without any help from RADIUS, either through
configuration by SNMP, a NAS administration program, or deduced by configuration by SNMP, a NAS administration program, or deduced by
the AppleTalk stack in the NAS. Specifically: the AppleTalk stack in the NAS. Specifically:
1. AppearAsNet and AppearAsNode values, sent to the client to tell 1. AppearAsNet and AppearAsNode values, sent to the client to tell
it what network and node numbers it should use in its datagram it what network and node numbers it should use in its datagram
packets. AppearAsNet can be taken from the Framed-AppleTalk- packets. AppearAsNet can be taken from the Framed-AppleTalk-
Network attribute or from the configuration or AppleTalk stack on Network attribute or from the configuration or AppleTalk stack
the NAS. onthe NAS.
2. The "default" zone - that is the name of the AppleTalk zone in 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 which the dial-in client will appear. (Or can be specified
the Framed-AppleTalk-Zone attribute.) with the Framed-AppleTalk-Zone attribute.)
3. Other very NAS specific stuff such as the name of the NAS, and 3. Other very NAS specific stuff such as the name of the NAS, and
smartbuffering information. (Smartbuffering is an ARAP mechanism smartbuffering information. (Smartbuffering is an ARAP
for replacing common AppleTalk datagrams with small tokens, to mechanism for replacing common AppleTalk datagrams with small
improve slow link performance in a few common traffic situations.) tokens, to improve slow link performance in a few common
traffic situations.)
4. "Zone List" information for this user. The ARAP specification 4. "Zone List" information for this user. The ARAP specification
defines a "zone count" field which is actually unused. defines a "zone count" field which is actually unused.
RADIUS supports ARAP Security Modules in the following manner. RADIUS supports ARAP Security Modules in the following manner.
After DES authentication has been completed, the RADIUS server may After DES authentication has been completed, the RADIUS server may
instruct the ARAP NAS to run one or more security modules for the instruct the ARAP NAS to run one or more security modules for the
dial-in user. Although the underlying protocol supports executing dial-in user. Although the underlying protocol supports executing
multiple security modules in series, in practice all current multiple security modules in series, in practice all current
implementations only allow executing one. Through the use of implementations only allow executing one. Through the use of
multiple Access-Challenge requests, multiple modules can be multiple Access-Challenge requests, multiple modules can be
supported, but this facility will probably never be used. supported, but this facility will probably never be used.
skipping to change at page 15, line 23 skipping to change at page 14, line 29
information. information.
2.3.4. Examples 2.3.4. Examples
The example below shows the conversation between the authenticating The example below shows the conversation between the authenticating
peer, NAS, and RADIUS server, for the case of a One Time Password peer, NAS, and RADIUS server, for the case of a One Time Password
(OTP) authentication. OTP is used only for illustrative purposes; (OTP) authentication. OTP is used only for illustrative purposes;
other authentication protocols could also have been used, although other authentication protocols could also have been used, although
they might show somewhat different behavior. they might show somewhat different behavior.
Authenticating Peer NAS RADIUS Server Authenticating Peer NAS RADIUS Server
------------------- --- ------------- ------------------- --- -------------
------------------ --- ------------- <- PPP LCP Request-EAP
<- PPP LCP Request-EAP auth
auth PPP LCP ACK-EAP
PPP LCP ACK-EAP auth ->
auth -> <- PPP EAP-Request/
<- PPP EAP-Request/ Identity
Identity PPP EAP-Response/
PPP EAP-Response/ Identity (MyID) ->
Identity (MyID) -> RADIUS
RADIUS Access-Request/
Access-Request/ EAP-Message/
EAP-Message/ EAP-Response/
EAP-Response/ (MyID) ->
(MyID) -> <- RADIUS
<- RADIUS Access-Challenge/
Access-Challenge/ EAP-Message/EAP-Request
EAP-Message/EAP-Request OTP/OTP Challenge
OTP/OTP Challenge <- PPP EAP-Request/
<- PPP EAP-Request/ OTP/OTP Challenge
OTP/OTP Challenge PPP EAP-Response/
PPP EAP-Response/ OTP, OTPpw ->
OTP, OTPpw -> RADIUS
RADIUS Access-Request/
Access-Request/ EAP-Message/
EAP-Message/ EAP-Response/
EAP-Response/ OTP, OTPpw ->
OTP, OTPpw -> <- RADIUS
<- RADIUS Access-Accept/
Access-Accept/ EAP-Message/EAP-Success
EAP-Message/EAP-Success (other attributes)
(other attributes) <- PPP EAP-Success
<- PPP EAP-Success PPP Authentication
PPP Authentication Phase complete,
Phase complete, NCP Phase starts
NCP Phase starts
In the case where the NAS first sends an EAP-Start packet to the In the case where the NAS first sends an EAP-Start packet to the
RADIUS server, the conversation would appear as follows: RADIUS server, the conversation would appear as follows:
Authenticating Peer NAS RADIUS Server Authenticating Peer NAS RADIUS Server
------------------- --- ------------- ------------------- --- -------------
------------------ --- ------------- <- PPP LCP Request-EAP
<- PPP LCP Request-EAP auth
auth PPP LCP ACK-EAP
PPP LCP ACK-EAP auth ->
auth -> RADIUS
RADIUS Access-Request/
Access-Request/ EAP-Message/Start ->
EAP-Message/Start -> <- RADIUS
<- RADIUS Access-Challenge/
Access-Challenge/ EAP-Message/Identity
EAP-Message/Identity <- PPP EA-Request/
<- PPP EA-Request/ Identity
Identity PPP EAP-Response/
PPP EAP-Response/ Identity (MyID) ->
Identity (MyID) -> RADIUS
RADIUS Access-Request/
Access-Request/ EAP-Message/
EAP-Message/ EAP-Response/
EAP-Response/ (MyID) ->
(MyID) -> <- RADIUS
<- RADIUS Access-Challenge/
Access-Challenge/ EAP-Message/EAP-Request
EAP-Message/EAP-Request OTP/OTP Challenge
OTP/OTP Challenge <- PPP EAP-Request/
<- PPP EAP-Request/ OTP/OTP Challenge
OTP/OTP Challenge PPP EAP-Response/
PPP EAP-Response/ OTP, OTPpw ->
OTP, OTPpw -> RADIUS
RADIUS Access-Request/
Access-Request/ EAP-Message/
EAP-Message/ EAP-Response/
EAP-Response/ OTP, OTPpw ->
OTP, OTPpw -> <- RADIUS
<- RADIUS Access-Accept/
Access-Accept/ EAP-Message/EAP-Success
EAP-Message/EAP-Success (other attributes)
(other attributes) <- PPP EAP-Success
<- PPP EAP-Success PPP Authentication
PPP Authentication Phase complete,
Phase complete, NCP Phase starts
NCP Phase starts
In the case where the client fails EAP authentication, the In the case where the client fails EAP authentication, the
conversation would appear as follows: conversation would appear as follows:
Autheticating Peer NAS RADIUS Server Authenticating Peer NAS RADIUS Server
------------------- --- ------------- ------------------- --- -------------
------------------ --- ------------- <- PPP LCP Request-EAP
<- PPP LCP Request-EAP auth
auth PPP LCP ACK-EAP
PPP LCP ACK-EAP auth ->
auth -> Access-Request/
Access-Request/ EAP-Message/Start ->
EAP-Message/Start -> <- RADIUS
<- RADIUS Access-Challenge/
Access-Challenge/ EAP-Message/Identity
EAP-Message/Identity <- PPP EAP-Request/
<- PPP EAP-Request/ Identity
Identity PPP EAP-Response/
PPP EAP-Response/ Identity (MyID) ->
Identity (MyID) -> RADIUS
RADIUS Access-Request/
Access-Request/ EAP-Message/
EAP-Message/ EAP-Response/
EAP-Response/ (MyID) ->
(MyID) -> <- RADIUS
<- RADIUS Access-Challenge/
Access-Challenge/ EAP-Message/EAP-Request
EAP-Message/EAP-Request OTP/OTP Challenge
OTP/OTP Challenge <- PPP EAP-Request/
<- PPP EAP-Request/ OTP/OTP Challenge
OTP/OTP Challenge PPP EAP-Response/
PPP EAP-Response/ OTP, OTPpw ->
OTP, OTPpw -> RADIUS
RADIUS Access-Request/
Access-Request/ EAP-Message/
EAP-Message/ EAP-Response/
EAP-Response/ OTP, OTPpw ->
OTP, OTPpw -> <- RADIUS
<- RADIUS Access-Reject/
Access-Reject/ EAP-Message/EAP-Failure
EAP-Message/EAP-Failure
<- PPP EAP-Failure <- PPP EAP-Failure
(client disconnected) (client disconnected)
In the case that the RADIUS server or proxy does not support EAP- In the case that the RADIUS server or proxy does not support
Message, the conversation would appear as follows: EAP-Message, the conversation would appear as follows:
Authenticating Peer NAS RADIUS Server Authenticating Peer NAS RADIUS Server
------------------- --- ------------- ------------------- --- -------------
------------------ --- ------------- <- PPP LCP Request-EAP
<- PPP LCP Request-EAP auth
auth PPP LCP ACK-EAP
PPP LCP ACK-EAP auth ->
auth -> RADIUS
RADIUS Access-Request/
Access-Request/ EAP-Message/Start ->
EAP-Message/Start -> <- RADIUS
<- RADIUS Access-Reject
Access-Reject <- PPP LCP Terminate
<- PPP LCP Terminate (User Disconnected)
(User Disconnected)
In the case where the local RADIUS Server does support EAP-Message, In the case where the local RADIUS Server does support EAP-Message,
but the remote RADIUS Server does not, the conversation would appear but the remote RADIUS Server does not, the conversation would appear
as follows: as follows:
Authenticating Peer NAS RADIUS Server Authenticating Peer NAS RADIUS Server
------------------- --- ------------- ------------------- --- -------------
------------------ --- ------------- <- PPP LCP Request-EAP
<- PPP LCP Request-EAP auth
auth PPP LCP ACK-EAP
PPP LCP ACK-EAP auth ->
auth -> RADIUS
RADIUS Access-Request/
Access-Request/ EAP-Message/Start ->
EAP-Message/Start -> <- RADIUS
<- RADIUS Access-Challenge/
Access-Challenge/ EAP-Message/Identity
EAP-Message/Identity <- PPP EAP-Request/
<- PPP EAP-Request/ Identity
Identity
PPP EAP-Response/
Identity
(MyID) ->
RADIUS
Access-Request/
EAP-Message/EAP-Response/
(MyID) ->
<- RADIUS
Access-Reject
(proxied from remote
RADIUS Server)
<- PPP LCP Terminate
(User Disconnected)
In the case where the authenticating peer does not support EAP, but PPP EAP-Response/
where EAP is required for that user, the conversation would appear as Identity
follows: (MyID) ->
RADIUS
Access-Request/
EAP-Message/EAP-Response/
(MyID) ->
<- RADIUS
Access-Reject
(proxied from remote
RADIUS Server)
<- PPP LCP Terminate
(User Disconnected)
Authenticating Peer NAS RADIUS Server In the case where the authenticating peer does not support EAP, but
------------------- --- ------------- where EAP is required for that user, the conversation would appear as
follows:
<- PPP LCP Request-EAP Authenticating Peer NAS RADIUS Server
auth ------------------- --- -------------
PPP LCP NAK-EAP
auth ->
<- PPP LCP Request-CHAP
auth
PPP LCP ACK-CHAP
auth ->
<- PPP CHAP Challenge
PPP CHAP Response ->
RADIUS
Access-Request/
User-Name,
CHAP-Password ->
<- RADIUS
Access-Reject
<- PPP LCP Terminate
(User Disconnected)
In the case where the NAS does not support EAP, but where EAP is <- PPP LCP Request-EAP
required for that user, the conversation would appear as follows: auth
PPP LCP NAK-EAP
auth ->
<- PPP LCP Request-CHAP
auth
PPP LCP ACK-CHAP
auth ->
<- PPP CHAP Challenge
PPP CHAP Response ->
RADIUS
Access-Request/
User-Name,
CHAP-Password ->
<- RADIUS
Access-Reject
<- PPP LCP Terminate
(User Disconnected)
Authenticating Peer NAS RADIUS Server In the case where the NAS does not support EAP, but where EAP is
---------------- --- ------------- required for that user, the conversation would appear as follows:
<- PPP LCP Request-CHAP Authenticating Peer NAS RADIUS Server
auth ------------------- --- -------------
PP LCP ACK-CHAP
auth -> <- PPP LCP Request-CHAP
<- PPP CHAP Challenge auth
PPP CHAP Response ->
RADIUS PP LCP ACK-CHAP
Access-Request/ auth ->
User-Name, <- PPP CHAP Challenge
CHAP-Password -> PPP CHAP Response ->
<- RADIUS RADIUS
Access-Reject Access-Request/
<- PPP LCP Terminate User-Name,
(User Disconnected) CHAP-Password ->
<- RADIUS
Access-Reject
<- PPP LCP Terminate
(User Disconnected)
2.3.5. Alternative uses 2.3.5. Alternative uses
Currently the conversation between the backend security server and Currently the conversation between the backend security server and
the RADIUS server is proprietary because of lack of standardization. the RADIUS server is proprietary because of lack of standardization.
In order to increase standardization and provide interoperability In order to increase standardization and provide interoperability
between Radius vendors and backend security vendors, it is between Radius vendors and backend security vendors, it is
recommended that RADIUS-encapsulated EAP be used for this recommended that RADIUS-encapsulated EAP be used for this
conversation. conversation.
skipping to change at page 20, line 33 skipping to change at page 19, line 43
In the case where RADIUS-encapsulated EAP is used in a conversation In the case where RADIUS-encapsulated EAP is used in a conversation
between a RADIUS server and a backend security server, the security between a RADIUS server and a backend security server, the security
server will typically return an Access-Accept/EAP-Success message server will typically return an Access-Accept/EAP-Success message
without inclusion of the expected attributes currently returned in an without inclusion of the expected attributes currently returned in an
Access-Accept. This means that the RADIUS server MUST add these Access-Accept. This means that the RADIUS server MUST add these
attributes prior to sending an Access-Accept/EAP-Success message to attributes prior to sending an Access-Accept/EAP-Success message to
the NAS. the NAS.
3. Packet Format 3. Packet Format
Packet Format is identical to that defined in RFC xxxx [1] and yyyy Packet Format is identical to that defined in RFC 2865 [1] and 2866
[2] [2].
4. Packet Types 4. Packet Types
Packet types are identical to those defined in RFC xxxx [1] and yyyy Packet types are identical to those defined in RFC 2865 [1] and 2866
[2]. [2].
See "Table of Attributes" below to determine which types of packets See "Table of Attributes" below to determine which types of packets
can contain which attributes defined here. can contain which attributes defined here.
5. Attributes 5. Attributes
RADIUS Attributes carry the specific authentication, authorization RADIUS Attributes carry the specific authentication, authorization
and accounting details for the request and response. and accounting details for the request and response.
Some attributes MAY be included more than once. The effect of this Some attributes MAY be included more than once. The effect of this
is attribute specific, and is specified in each attribute is attribute specific, and is specified in each attribute
description. The order of attributes of the same type SHOULD be description. The order of attributes of the same type SHOULD be
preserved. The order of attributes of different types is not preserved. The order of attributes of different types is not
required to be preserved. required to be preserved.
The end of the list of attributes is indicated by the Length of the The end of the list of attributes is indicated by the Length of the
RADIUS packet. RADIUS packet.
A summary of the attribute format is the same as in RFC xxxx [1] but A summary of the attribute format is the same as in RFC 2865 [1] but
is included here for ease of reference. The fields are transmitted is included here for ease of reference. The fields are transmitted
from left to right. from left to right.
0 1 2 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 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 | Length | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
The Type field is one octet. Up-to-date values of the RADIUS 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 [5]. field are specified in the most recent "Assigned Numbers" RFC [5].
Values 192-223 are reserved for experimental use, values 224-240 Values 192-223 are reserved for experimental use, values 224-240
are reserved for implementation-specific use, and values 241-255 are reserved for implementation-specific use, and values 241-255
are reserved and should not be used. This specification concerns are reserved and should not be used. This specification concerns
the following values: the following values:
1-39 (refer to RFC xxxx [1], "RADIUS") 1-39 (refer to RFC 2865 [1], "RADIUS")
40-51 (refer to RFC yyyy [2], "RADIUS Accounting") 40-51 (refer to RFC 2866 [2], "RADIUS Accounting")
52 Acct-Input-Gigawords 52 Acct-Input-Gigawords
53 Acct-Output-Gigawords 53 Acct-Output-Gigawords
54 Unused 54 Unused
55 Event-Timestamp 55 Event-Timestamp
56-59 Unused 56-59 Unused
60-63 (refer to RFC xxxx [1], "RADIUS") 60-63 (refer to RFC 2865 [1], "RADIUS")
64-67 (refer to [6]) 64-67 (refer to [6])
68 (refer to [7]) 68 (refer to [7])
69 (refer to [6]) 69 (refer to [6])
70 ARAP-Password 70 ARAP-Password
71 ARAP-Features 71 ARAP-Features
72 ARAP-Zone-Access 72 ARAP-Zone-Access
73 ARAP-Security 73 ARAP-Security
74 ARAP-Security-Data 74 ARAP-Security-Data
75 Password-Retry 75 Password-Retry
76 Prompt 76 Prompt
skipping to change at page 22, line 29 skipping to change at page 21, line 35
attribute including the Type, Length and Value fields. If an attribute including the Type, Length and Value fields. If an
attribute is received in a packet with an invalid Length, the attribute is received in a packet with an invalid Length, the
entire request should be silently discarded. entire request should be silently discarded.
Value Value
The Value field is zero or more octets and contains information The Value field is zero or more octets and contains information
specific to the attribute. The format and length of the Value specific to the attribute. The format and length of the Value
field is determined by the Type and Length fields. field is determined by the Type and Length fields.
Note that a "string" in RADIUS does not terminate with a NUL (hex Note that none of the types in RADIUS terminate with a NUL (hex
00). The Attribute has a length field and does not use a 00). In particular, types "text" and "string" in RADIUS do not
terminator. Strings may contain UTF-8 characters or 8-bit binary terminate with a NUL (hex 00). The Attribute has a length field
data and servers and clients should be able to deal with embedded and does not use a terminator. Text contains UTF-8 encoded 10646
nulls. RADIUS implementers using C are cautioned not to use [8] characters and String contains 8-bit binary data. Servers and
strcpy() when handling strings. servers and clients MUST be able to deal with embedded nulls.
RADIUS implementers using C are cautioned not to use strcpy() when
handling strings.
The format of the value field is one of four data types. The format of the value field is one of five data types. Note
that type "text" is a subset of type "string."
string 1-253 octets. Strings of length zero (0) MUST NOT be text 1-253 octets containing UTF-8 encoded 10646 [8]
sent; omit the entire attribute instead. characters. Text of length zero (0) MUST NOT be sent;
omit the entire attribute instead.
string 1-253 octets containing binary data (values 0 through
255 decimal, inclusive). Strings of length zero (0) MUST
NOT be sent; omit the entire attribute instead.
address 32 bit unsigned value, most significant octet first. address 32 bit unsigned value, most significant octet first.
integer 32 bit unsigned value, most significant octet first. integer 32 bit unsigned value, most significant octet first.
time 32 bit unsigned value, most significant octet first -- time 32 bit unsigned value, most significant octet first --
seconds since 00:00:00 UTC, January 1, 1970. seconds since 00:00:00 UTC, January 1, 1970.
5.1. Acct-Input-Gigawords 5.1. Acct-Input-Gigawords
Description Description
This attribute indicates how many times the Acct-Input-Octets This attribute indicates how many times the Acct-Input-Octets
counter has wrapped around 2^32 over the course of this service counter has wrapped around 2^32 over the course of this service
being provided, and can only be present in Accounting-Request being provided, and can only be present in Accounting-Request
records where the Acct-Status-Type is set to Stop or Interim- records where the Acct-Status-Type is set to Stop or Interim-
Update. Update.
skipping to change at page 24, line 30 skipping to change at page 23, line 42
Value Value
The Value field is four octets. The Value field is four octets.
5.3. Event-Timestamp 5.3. Event-Timestamp
Description Description
This attribute is included in an Accounting-Request packet to This attribute is included in an Accounting-Request packet to
record the time that this event occured on the NAS, in seconds record the time that this event occurred on the NAS, in seconds
since January 1, 1970 00:00 UTC. since January 1, 1970 00:00 UTC.
A summary of the Event-Timestamp attribute format is shown below. A summary of the Event-Timestamp attribute format is shown below.
The fields are transmitted from left to right. The fields are transmitted from left to right.
0 1 2 3 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 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 | Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 31, line 36 skipping to change at page 30, line 33
The NAS MAY send this attribute in an Access-Request or The NAS MAY send this attribute in an Access-Request or
Accounting-Request to indicate the nature of the user's Accounting-Request to indicate the nature of the user's
connection. connection.
A summary of the Connect-Info attribute format is shown below. The A summary of the Connect-Info attribute format is shown below. The
fields are transmitted from left to right. fields are transmitted from left to right.
0 1 2 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 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 | Length | Text...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
77 for Connect-Info. 77 for Connect-Info.
Length Length
>= 3 >= 3
String Text
The String field is encoded as UTF-8 [8] characters. The The Text field consists of UTF-8 encoded 10646 [8] characters.
connection speed SHOULD be included at the beginning of the first The connection speed SHOULD be included at the beginning of the
Connect-Info attribute in the packet. If the transmit and receive first Connect-Info attribute in the packet. If the transmit and
connection speeds differ, they may both be included in the first receive connection speeds differ, they may both be included in the
attribute with the transmit speed first (the speed the NAS modem first attribute with the transmit speed first (the speed the NAS
transmits at), a slash (/), the receive speed, then optionally modem transmits at), a slash (/), the receive speed, then
other information. optionally other information.
For example, "28800 V42BIS/LAPM" or "52000/31200 V90" For example, "28800 V42BIS/LAPM" or "52000/31200 V90"
More than one Connect-Info attribute may be present in an More than one Connect-Info attribute may be present in an
Accounting-Request packet to accommodate expected efforts by ITU Accounting-Request packet to accommodate expected efforts by ITU
to have modems report more connection information in a standard to have modems report more connection information in a standard
format that might exceed 252 octets. format that might exceed 252 octets.
5.12. Configuration-Token 5.12. Configuration-Token
skipping to change at page 34, line 37 skipping to change at page 33, line 27
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String... | Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
79 for EAP-Message. 79 for EAP-Message.
Length Length
>= 3 (EAP packet enclosed) >= 3
= 2 (EAP-Start message)
String String
The String field contains EAP packets, as defined in [3]. If The String field contains EAP packets, as defined in [3]. If
multiple EAP-Message attributes are present in a packet their multiple EAP-Message attributes are present in a packet their
values should be concatenated; this allows EAP packets longer than values should be concatenated; this allows EAP packets longer than
253 octets to be passed by RADIUS. 253 octets to be passed by RADIUS.
5.14. Message-Authenticator 5.14. Message-Authenticator
skipping to change at page 38, line 33 skipping to change at page 37, line 9
The Value field contains the number of seconds between each The Value field contains the number of seconds between each
interim update to be sent from the NAS for this session. The value interim update to be sent from the NAS for this session. The value
MUST NOT be smaller than 60. The value SHOULD NOT be smaller than MUST NOT be smaller than 60. The value SHOULD NOT be smaller than
600, and careful consideration should be given to its impact on 600, and careful consideration should be given to its impact on
network traffic. network traffic.
5.17. NAS-Port-Id 5.17. NAS-Port-Id
Description Description
This Attribute contains a string which identifies the port of the This Attribute contains a text string which identifies the port of
NAS which is authenticating the user. It is only used in Access- the NAS which is authenticating the user. It is only used in
Request and Accounting-Request packets. Note that this is using Access-Request and Accounting-Request packets. Note that this is
"port" in its sense of a physical connection on the NAS, not in using "port" in its sense of a physical connection on the NAS, not
the sense of a TCP or UDP port number. in the sense of a TCP or UDP port number.
Either NAS-Port or NAS-Port-Id SHOULD be present in an Access- Either NAS-Port or NAS-Port-Id SHOULD be present in an Access-
Request packet, if the NAS differentiates among its ports. NAS- Request packet, if the NAS differentiates among its ports. NAS-
Port-Id is intended for use by NASes which cannot conveniently Port-Id is intended for use by NASes which cannot conveniently
number their ports. number their ports.
A summary of the NAS-Port-Id Attribute format is shown below. The A summary of the NAS-Port-Id Attribute format is shown below. The
fields are transmitted from left to right. fields are transmitted from left to right.
0 1 2 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 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 | Length | Text...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
87 for NAS-Port-Id. 87 for NAS-Port-Id.
Length Length
>= 3 >= 3
String Text
The String field contains the name of the port in UTF-8 [8] The Text field contains the name of the port using UTF-8 encoded
format. 10646 [8] characters.
5.18. Framed-Pool 5.18. Framed-Pool
Description Description
This Attribute contains the name of an assigned address pool that This Attribute contains the name of an assigned address pool that
SHOULD be used to assign an address for the user. If a NAS does SHOULD be used to assign an address for the user. If a NAS does
not support multiple address pools, the NAS should ignore this not support multiple address pools, the NAS should ignore this
Attribute. Address pools are usually used for IP addresses, but Attribute. Address pools are usually used for IP addresses, but
can be used for other protocols if the NAS supports pools for can be used for other protocols if the NAS supports pools for
skipping to change at page 40, line 26 skipping to change at page 38, line 36
5.19. Table of Attributes 5.19. Table of Attributes
The following table provides a guide to which attributes may be found The following table provides a guide to which attributes may be found
in which kind of packets. Acct-Input-Gigawords, Acct-Output- in which kind of packets. Acct-Input-Gigawords, Acct-Output-
Gigawords, Event-Timestamp, and NAS-Port-Id may have 0-1 instances in Gigawords, Event-Timestamp, and NAS-Port-Id may have 0-1 instances in
an Accounting-Request packet. Connect-Info may have 0+ instances in an Accounting-Request packet. Connect-Info may have 0+ instances in
an Accounting-Request packet. The other attributes added in this an Accounting-Request packet. The other attributes added in this
document must not be present in an Accounting-Request. document must not be present in an Accounting-Request.
Request Accept Reject Challenge # Attribute Request Accept Reject Challenge # Attribute
0-1 0 0 0 70 ARAP-Password [Note 1] 0-1 0 0 0 70 ARAP-Password [Note 1]
0 0-1 0 0-1 71 ARAP-Features 0 0-1 0 0-1 71 ARAP-Features
0 0-1 0 0 72 ARAP-Zone-Access 0 0-1 0 0 72 ARAP-Zone-Access
0-1 0 0 0-1 73 ARAP-Security 0-1 0 0 0-1 73 ARAP-Security
0+ 0 0 0+ 74 ARAP-Security-Data 0+ 0 0 0+ 74 ARAP-Security-Data
0 0 0-1 0 75 Password-Retry 0 0 0-1 0 75 Password-Retry
0 0 0 0-1 76 Prompt 0 0 0 0-1 76 Prompt
0-1 0 0 0 77 Connect-Info 0-1 0 0 0 77 Connect-Info
0 0+ 0 0 78 Configuration-Token 0 0+ 0 0 78 Configuration-Token
0+ 0+ 0+ 0+ 79 EAP-Message [Note 1] 0+ 0+ 0+ 0+ 79 EAP-Message [Note 1]
0-1 0-1 0-1 0-1 80 Message-Authenticator [Note 1] 0-1 0-1 0-1 0-1 80 Message-Authenticator [Note 1]
0 0-1 0 0-1 84 ARAP-Challenge-Response 0 0-1 0 0-1 84 ARAP-Challenge-Response
0 0-1 0 0 85 Acct-Interim-Interval 0 0-1 0 0 85 Acct-Interim-Interval
0-1 0 0 0 87 NAS-Port-Id 0-1 0 0 0 87 NAS-Port-Id
0 0-1 0 0 88 Framed-Pool 0 0-1 0 0 88 Framed-Pool
Request Accept Reject Challenge # Attribute Request Accept Reject Challenge # Attribute
[Note 1] An Access-Request that contains either a User-Password or [Note 1] An Access-Request that contains either a User-Password or
CHAP-Password or ARAP-Password or one or more EAP-Message attributes CHAP-Password or ARAP-Password or one or more EAP-Message attributes
MUST NOT contain more than one type of those four attributes. If it MUST NOT contain more than one type of those four attributes. If it
does not contain any of those four attributes, it SHOULD contain a does not contain any of those four attributes, it SHOULD contain a
Message-Authenticator. If any packet type contains an EAP-Message Message-Authenticator. If any packet type contains an EAP-Message
attribute it MUST also contain a Message-Authenticator. attribute it MUST also contain a Message-Authenticator.
The following table defines the above table entries. The following table defines the above table entries.
skipping to change at page 42, line 38 skipping to change at page 40, line 39
As described earlier, when EAP/RADIUS is used to encapsulate EAP As described earlier, when EAP/RADIUS is used to encapsulate EAP
packets, the Message-Authenticator attribute is required in packets, the Message-Authenticator attribute is required in
EAP/RADIUS Access-Requests sent from the NAS or tunnel server to the EAP/RADIUS Access-Requests sent from the NAS or tunnel server to the
RADIUS server. Since the Message-Authenticator attribute involves a RADIUS server. Since the Message-Authenticator attribute involves a
HMAC-MD5 hash, it is possible for the RADIUS server to verify the HMAC-MD5 hash, it is possible for the RADIUS server to verify the
integrity of the Access-Request as well as the NAS or tunnel server's integrity of the Access-Request as well as the NAS or tunnel server's
identity. Similarly, Access-Challenge packets sent from the RADIUS identity. Similarly, Access-Challenge packets sent from the RADIUS
server to the NAS are also authenticated and integrity protected server to the NAS are also authenticated and integrity protected
using an HMAC-MD5 hash, enabling the NAS or tunnel server to using an HMAC-MD5 hash, enabling the NAS or tunnel server to
determine the integrity of the packet and verify the identity of the determine the integrity of the packet and verify the identity of the
RADIUS server. Morever, EAP packets sent via methods that contain RADIUS server. Moreover, EAP packets sent via methods that contain
their own integrity protection cannot be successfully modified by a their own integrity protection cannot be successfully modified by a
rogue NAS or tunnel server. rogue NAS or tunnel server.
The second issue that arises in the case of an EAP server and PPP The second issue that arises in the case of an EAP server and PPP
authenticator residing on different machines is that the session key authenticator residing on different machines is that the session key
negotiated between the peer and EAP server will need to be negotiated between the peer and EAP server will need to be
transmitted to the authenticator. Therefore a mechanism needs to be transmitted to the authenticator. Therefore a mechanism needs to be
provided to transmit the session key from the EAP server to the provided to transmit the session key from the EAP server to the
authenticator or tunnel server that needs to use the key. The authenticator or tunnel server that needs to use the key. The
specification of this transit mechanism is outside the scope of this specification of this transit mechanism is outside the scope of this
skipping to change at page 45, line 25 skipping to change at page 43, line 25
renegotiate the authentication protocol if EAP had initially been renegotiate the authentication protocol if EAP had initially been
negotiated. Note that problems with a non-EAP capable RADIUS proxy negotiated. Note that problems with a non-EAP capable RADIUS proxy
could prove difficult to diagnose, since a user dialing in from one could prove difficult to diagnose, since a user dialing in from one
location (with an EAP-capable proxy) might be able to successfully location (with an EAP-capable proxy) might be able to successfully
authenticate via EAP, while the same user dialing into another authenticate via EAP, while the same user dialing into another
location (and encountering an EAP-incapable proxy) might be location (and encountering an EAP-incapable proxy) might be
consistently disconnected. consistently disconnected.
8. References 8. References
[1] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote [1] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC xxxx, Authentication Dial In User Service (RADIUS)", RFC 2865, June
February 2000. 2000.
[2] Rigney, C., "RADIUS Accounting", RFC yyyy, February 2000. [2] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[3] Blunk, L., and Vollbrecht, J., "PPP Extensible Authentication [3] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
Protocol (EAP)", RFC 2284, March 1998. Protocol (EAP)", RFC 2284, March 1998.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels." BCP 14, RFC 2119, Harvard University, March, 1997. Levels", BCP 14, RFC 2119, March, 1997.
[5] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC [5] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
1700, USC/Information Sciences Institute, October 1994. October 1994.
[6] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., [6] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and
and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC
draft-ietf-radius-tunnel-auth-09.txt, August 1999. 2868, June 2000.
[7] Zorn, G., Mitton, D., and B. Aboba, "RADIUS Accounting [7] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting
Modifications for Tunnel Protocol Support" draft-ietf-radius- Modifications for Tunnel Protocol Support", RFC 2867, June 2000.
tunnel-acct-05.txt, October 1999.
[8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC [8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998. 2279, January 1998.
[9] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing [9] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997. for Message Authentication", RFC 2104, February 1997.
[10] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA [10] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
1998.
[11] Slatalla, M., and Quittner, J., "Masters of Deception." [11] Slatalla, M., and Quittner, J., "Masters of Deception."
HarperCollins, New York, 1995. HarperCollins, New York, 1995.
9. Acknowledgements 9. Acknowledgements
RADIUS and RADIUS Accounting were originally developed by Livingston RADIUS and RADIUS Accounting were originally developed by Livingston
Enterprises (now part of Lucent Technologies) for their PortMaster Enterprises (now part of Lucent Technologies) for their PortMaster
series of Network Access Servers. series of Network Access Servers.
The section on ARAP is adopted with permission from "Using RADIUS to The section on ARAP is adopted with permission from "Using RADIUS to
Authenticate Apple Remote Access Connections" by Ward Willats of Cyno Authenticate Apple Remote Access Connections" by Ward Willats of Cyno
Technologies (ward@cyno.com). Technologies (ward@cyno.com).
The section on Acct-Interim-Interval is adopted with permission from The section on Acct-Interim-Interval is adopted with permission from
an earlier Internet-Draft by Pat Calhoun of Sun Microsystems, Mark an earlier work in progress by Pat Calhoun of Sun Microsystems, Mark
Beadles of Compuserve, and Alex Ratcliffe of UUNET Technologies. Beadles of Compuserve, and Alex Ratcliffe of UUNET Technologies.
The section on EAP is adopted with permission from an earlier The section on EAP is adopted with permission from an earlier work in
Internet-Draft by Pat Calhoun of Sun Microsystems, Allan Rubens of progress by Pat Calhoun of Sun Microsystems, Allan Rubens of Merit
Merit Network, and Bernard Aboba of Microsoft. Thanks also to Dave Network, and Bernard Aboba of Microsoft. Thanks also to Dave Dawson
Dawson and Karl Fox of Ascend, and Glen Zorn and Narendra Gidwani of and Karl Fox of Ascend, and Glen Zorn and Narendra Gidwani of
Microsoft for useful discussions of this problem space. Microsoft for useful discussions of this problem space.
10. Chair's Address 10. Chair's Address
The RADIUS working group can be contacted via the current chair: The RADIUS working group can be contacted via the current chair:
Carl Rigney Carl Rigney
Livingston Enterprises Livingston Enterprises
4464 Willow Road 4464 Willow Road
Pleasanton, California 94588 Pleasanton, California 94588
Phone: +1 925 737 2100
E-Mail: cdr@livingston.com
11. Author's Address Phone: +1 925 737 2100
EMail: cdr@telemancy.com
11. Authors' Addresses
Questions about this memo can also be directed to: Questions about this memo can also be directed to:
Carl Rigney Carl Rigney
Livingston Enterprises Livingston Enterprises
4464 Willow Road 4464 Willow Road
Pleasanton, California 94588 Pleasanton, California 94588
E-Mail: cdr@livingston.com EMail: cdr@telemancy.com
Questions on ARAP and RADIUS may be directed to: Questions on ARAP and RADIUS may be directed to:
Ward Willats Ward Willats
Cyno Technologies Cyno Technologies
1082 Glen Echo Ave 1082 Glen Echo Ave
San Jose, CA 95125 San Jose, CA 95125
Phone: +1 408 297 7766
E-Mail: ward@cyno.com
Phone: +1 408 297 7766
EMail: ward@cyno.com
Questions on EAP and RADIUS may be directed to any of the following: Questions on EAP and RADIUS may be directed to any of the following:
Pat R. Calhoun Pat R. Calhoun
Network and Security Research Center Network and Security Research Center
Sun Microsystems, Inc. Sun Microsystems, Inc.
15 Network Circle 15 Network Circle
Menlo Park, CA 94025 Menlo Park, CA 94025
Phone: +1 650 786 7733
E-Mail: pcalhoun@eng.sun.com
Allan C. Rubens Phone: +1 650 786 7733
Merit Network, Inc. EMail: pcalhoun@eng.sun.com
4251 Plymouth Rd.
Ann Arbor, MI 48105-2785
Phone: +1 313 647 0417
E-Mail: acr@merit.edu
Bernard Aboba Allan C. Rubens
Microsoft Corporation Tut Systems, Inc.
One Microsoft Way 220 E. Huron, Suite 260
Redmond, WA 98052 Ann Arbor, MI 48104
Phone: +1 425 936 6605
E-Mail: bernarda@microsoft.com Phone: +1 734 995 1697
EMail: arubens@tutsys.com
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: +1 425 936 6605
EMail: bernarda@microsoft.com
12. Full Copyright Statement 12. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and or assist in its implementation may be prepared, copied, published
distributed, in whole or in part, without restriction of any kind, and distributed, in whole or in part, without restriction of any
provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 85 change blocks. 
467 lines changed or deleted 444 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/