draft-ietf-radius-ext-05.txt   draft-ietf-radius-ext-06.txt 
RADIUS Working Group C Rigney RADIUS Working Group C Rigney
INTERNET-DRAFT Livingston INTERNET-DRAFT Livingston
W Willats W Willats
Cyno Technologies Cyno Technologies
P Calhoun P Calhoun
Sun Microsystems Sun Microsystems
expires May 2000 December 1999 expires August 2000 February 2000
RADIUS Extensions RADIUS Extensions
draft-ietf-radius-ext-05.txt 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 document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
This document is a submission to the RADIUS Working Group of the This document is a submission to the RADIUS Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted Internet Engineering Task Force (IETF). Comments should be submitted
to the ietf-radius@livingston.com mailing list. to the ietf-radius@livingston.com mailing list.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
DRAFT RADIUS Extensions December 1999
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 2138 and RFC 2139. described in RFC xxxx [1] and RFC yyyy [2].
Table of Contents Table of Contents
1. Introduction .......................................... 4 1. Introduction .......................................... 4
1.1 Specification of Requirements ................... 4 1.1 Specification of Requirements ................... 4
1.2 Terminology ..................................... 4 1.2 Terminology ..................................... 4
2. Operation ............................................. 5 2. Operation ............................................. 5
2.1 RADIUS support for Interim Accounting Updates 2.1 RADIUS support for Interim Accounting Updates
2.2 RADIUS support for Apple Remote Access Protocol 6 2.2 RADIUS support for Apple Remote Access
Protocol ........................................ 6
2.3 RADIUS Support for Extensible Authentication 2.3 RADIUS Support for Extensible Authentication
Protocol (EAP) ........................... 12 Protocol (EAP) .................................. 12
2.3.1 Protocol Overview ............................... 12 2.3.1 Protocol Overview ............................... 12
2.3.2 Retransmission .................................. 14 2.3.2 Retransmission .................................. 14
2.3.3 Fragmentation ................................... 14 2.3.3 Fragmentation ................................... 15
2.3.4 Examples ........................................ 15 2.3.4 Examples ........................................ 15
2.3.5 Alternative uses ................................ 20 2.3.5 Alternative uses ................................ 20
3. Packet Format ......................................... 20 3. Packet Format ......................................... 20
4. Packet Types .......................................... 20 4. Packet Types .......................................... 20
5. Attributes ............................................ 20 5. Attributes ............................................ 20
5.1 Acct-Input-Gigawords ............................ 22 5.1 Acct-Input-Gigawords ............................ 23
5.2 Acct-Output-Gigawords ........................... 23 5.2 Acct-Output-Gigawords ........................... 23
5.3 Event-Timestamp ................................. 24 5.3 Event-Timestamp ................................. 24
5.4 ARAP-Password ................................... 25 5.4 ARAP-Password ................................... 25
5.5 ARAP-Features ................................... 26 5.5 ARAP-Features ................................... 26
5.6 ARAP-Zone-Access ................................ 27 5.6 ARAP-Zone-Access ................................ 27
5.7 ARAP-Security ................................... 28 5.7 ARAP-Security ................................... 28
5.8 ARAP-Security-Data .............................. 28 5.8 ARAP-Security-Data .............................. 29
5.9 Password-Retry .................................. 29 5.9 Password-Retry .................................. 29
5.10 Prompt .......................................... 30 5.10 Prompt .......................................... 30
5.11 Connect-Info .................................... 31 5.11 Connect-Info .................................... 31
5.12 Configuration-Token ............................. 32 5.12 Configuration-Token ............................. 32
5.13 EAP-Message ..................................... 32 5.13 EAP-Message ..................................... 33
5.14 Signature ....................................... 34 5.14 Message-Authenticator ........................... 34
5.15 ARAP-Challenge-Response ......................... 36 5.15 ARAP-Challenge-Response ......................... 36
5.16 Acct-Interim-Interval ........................... 37 5.16 Acct-Interim-Interval ........................... 37
5.17 NAS-Port-Id ..................................... 37 5.17 NAS-Port-Id ..................................... 38
5.18 Framed-Pool ..................................... 38 5.18 Framed-Pool ..................................... 39
5.19 Table of Attributes ............................. 39 5.19 Table of Attributes ............................. 40
DRAFT RADIUS Extensions December 1999
6. Security Considerations ............................... 40 6. IANA Considerations ................................... 41
6.1 Signature Security .............................. 40
6.2 EAP Security .................................... 40
6.2.1 Separation of EAP server and PPP authenticator
6.2.2 Connection hijacking ............................ 42
6.2.3 Man in the middle attacks ....................... 42
6.2.4 Multiple databases .............................. 42
6.2.5 Negotiation attacks ............................. 43
7. References ............................................ 44 7. Security Considerations ............................... 41
7.1 Message-Authenticator Security .................. 41
7.2 EAP Security .................................... 41
7.2.1 Separation of EAP server and PPP authenticator
7.2.2 Connection hijacking ............................ 43
7.2.3 Man in the middle attacks ....................... 43
7.2.4 Multiple databases .............................. 43
7.2.5 Negotiation attacks ............................. 44
8. Acknowledgements ...................................... 45 8. References ............................................ 45
9. Chair's Address ....................................... 45 9. Acknowledgements ...................................... 46
10. Author's Address ...................................... 45 10. Chair's Address ....................................... 46
11. Full Copyright Statement .............................. 47 11. Author's Address ...................................... 47
DRAFT RADIUS Extensions December 1999 12. Full Copyright Statement .............................. 48
1. Introduction 1. Introduction
RFC 2138 [1] describes the RADIUS Protocol as it is implemented and RFC xxxx [1] describes the RADIUS Protocol as it is implemented and
deployed today, and RFC 2139 [2] describes how Accounting can be deployed today, and RFC yyyy [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 Signature PPP. This memo describes how the EAP-Message and Message-
attributes may be used for providing EAP support within RADIUS. Authenticator attributes may be used for providing EAP support within
RADIUS.
All attributes are comprised of variable length Type-Length-Value 3- All attributes are comprised of variable length Type-Length-Value 3-
tuples. New attribute values can be added without disturbing tuples. New attribute values can be added without disturbing
existing implementations of the protocol. existing implementations of the protocol.
1.1. Specification of Requirements 1.1. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [4]. document are to be interpreted as described in RFC 2119 [4].
skipping to change at page 5, line 5 skipping to change at page 5, line 6
for ARAP. A NAS MUST treat a RADIUS access-request requesting an for ARAP. A NAS MUST treat a RADIUS access-request requesting an
unavailable service as an access-reject instead. unavailable service as an access-reject instead.
1.2. Terminology 1.2. Terminology
This document uses the following terms: This document uses the following terms:
service The NAS provides a service to the dial-in user, such as PPP service The NAS provides a service to the dial-in user, such as PPP
or Telnet. or Telnet.
DRAFT RADIUS Extensions December 1999
session Each service provided by the NAS to a dial-in user session Each service provided by the NAS to a dial-in user
constitutes a session, with the beginning of the session constitutes a session, with the beginning of the session
defined as the point where service is first provided and defined as the point where service is first provided and
the end of the session defined as the point where service the end of the session defined as the point where service
is ended. A user may have multiple sessions in parallel or is ended. A user may have multiple sessions in parallel or
series if the NAS supports that, with each session series if the NAS supports that, with each session
generating a separate start and stop accounting record. generating a separate start and stop accounting record.
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 2138 and 2139. Operation is identical to that defined in RFC xxxx [1] and RFC yyyy
[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.
It is also possible to statically configure an interim value on the It is also possible to statically configure an interim value on the
skipping to change at page 6, line 5 skipping to change at page 6, line 9
It is envisioned that an Interim Accounting record (with Acct- It is envisioned that an Interim Accounting record (with Acct-
Status-Type = Interim-Update (3)) would contain all of the attributes Status-Type = Interim-Update (3)) would contain all of the attributes
normally found in an Accounting Stop message with the exception of normally found in an Accounting Stop message with the exception of
the Acct-Term-Cause attribute. the Acct-Term-Cause attribute.
Since all the information is cumulative, a NAS MUST ensure that only Since all the information is cumulative, a NAS MUST ensure that only
a single generation of an interim Accounting message for a given a single generation of an interim Accounting message for a given
session is present in the retransmission queue at any given time. session is present in the retransmission queue at any given time.
DRAFT RADIUS Extensions December 1999
A NAS MAY use a fudge factor to add a random delay between Interim A NAS MAY use a fudge factor to add a random delay between Interim
Accounting messages for separate sessions. This will ensure that a Accounting messages for separate sessions. This will ensure that a
cycle where all messages are sent at once is prevented, such as might cycle where all messages are sent at once is prevented, such as might
otherwise occur if a primary link was recently restored and many otherwise occur if a primary link was recently restored and many
dial-up users were directed to the same NAS at once. dial-up users were directed to the same NAS at once.
The Network and NAS CPU load of using Interim Updates should be The Network and NAS CPU load of using Interim Updates should be
carefully considered, and appropriate values of Acct-Interim-Interval carefully considered, and appropriate values of Acct-Interim-Interval
chosen. chosen.
skipping to change at page 7, line 4 skipping to change at page 7, line 9
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 user's
screen. These are not part of authentication and do not belong screen. These are not part of authentication and do not belong
here. However, we note that a Reply-Message attribute in an here. However, we note that a Reply-Message attribute in an
DRAFT RADIUS Extensions December 1999
Access-Accept may be sent down to the user as a sign-on message of Access-Accept may be sent down to the user as a sign-on message of
the day string using the out-of-band channel. 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.
skipping to change at page 8, line 4 skipping to change at page 8, line 9
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 both
the client and server and are allowed to read and write arbitrary the client and server and are allowed to read and write arbitrary
DRAFT RADIUS Extensions December 1999
data across the communications link to perform additional 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.
skipping to change at page 8, line 39 skipping to change at page 8, line 41
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), Framed-
Protocol (set to 3, ARAP), ARAP-Password, and any additional 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. [Probably needs to make Octets 4-7 are the second random number.
ordering clearer.]
The ARAP-Password in the Access-Request contains a 16 octet random 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 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- 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- 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 bit numbers, 8 octets) and the low-order octets contain the dial-in
user's response to the NAS challenge (2 32-bit numbers, 8 octets). 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 Only one of User-Password, CHAP-Password, or ARAP-Password needs to
be present in an Access-Request, or one or more EAP-Messages. be present in an Access-Request, or one or more EAP-Messages.
If the RADIUS server does not support ARAP it SHOULD return an If the RADIUS server does not support ARAP it SHOULD return an
Access-Reject to the NAS. Access-Reject to the NAS.
DRAFT RADIUS Extensions December 1999
If the RADIUS server does support ARAP, it should verify the user's 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 response using the Challenge (from the lower order 8 octets of the
Request Authenticator) and the user's response (from the low order 8 Request Authenticator) and the user's response (from the low order 8
octets of the ARAP-Password). octets of the ARAP-Password).
If that authentication fails, the RADIUS server should return an If that authentication fails, the RADIUS server should return an
Access-Reject packet to the NAS, with optional Password-Retry and Access-Reject packet to the NAS, with optional Password-Retry and
Reply-Messages attributes. The presence of Password-Retry indicates Reply-Messages attributes. The presence of Password-Retry indicates
the ARAP NAS MAY choose to initiate another challenge-response cycle, 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 up to a total number of times equal to the integer value of the
skipping to change at page 10, line 4 skipping to change at page 10, line 7
Octet 0: If zero, user cannot change their password. If non- Octet 0: If zero, user cannot change their password. If non-
zero user can. (RADIUS does not handle the password changing, zero user can. (RADIUS does not handle the password changing,
just the attribute which indicates whether ARAP indicates they just the attribute which indicates whether ARAP indicates they
can.) can.)
Octet 1: Minimum acceptable password length (0-8). Octet 1: Minimum acceptable password length (0-8).
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
DRAFT RADIUS Extensions December 1999
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 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.
skipping to change at page 11, line 5 skipping to change at page 11, line 7
way. way.
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:
DRAFT RADIUS Extensions December 1999
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 on
the NAS. the 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 with
the Framed-AppleTalk-Zone attribute.) the Framed-AppleTalk-Zone attribute.)
skipping to change at page 12, line 4 skipping to change at page 12, line 7
ARAP-Security: a four octet security module signature, containing a ARAP-Security: a four octet security module signature, containing a
Macintosh OSType. Macintosh OSType.
ARAP-Security-Data, a string to carry the actual security module ARAP-Security-Data, a string to carry the actual security module
challenge and response. challenge and response.
When the security module finishes executing, the security module When the security module finishes executing, the security module
response is passed in an ARAP-Security-Data attribute from the NAS response is passed in an ARAP-Security-Data attribute from the NAS
to the RADIUS server in a second Access-Request, also including the to the RADIUS server in a second Access-Request, also including the
State from the Access-Challenge. The authenticator field contains no State from the Access-Challenge. The authenticator field contains no
DRAFT RADIUS Extensions December 1999
special information in this case, and this can be discerned by the special information in this case, and this can be discerned by the
presence of the State attribute. presence of the State attribute.
2.3. RADIUS Support for Extensible Authentication Protocol (EAP) 2.3. RADIUS Support for Extensible Authentication Protocol (EAP)
The Extensible Authentication Protocol (EAP), described in [3], The Extensible Authentication Protocol (EAP), described in [3],
provides a standard mechanism for support of additional provides a standard mechanism for support of additional
authentication methods within PPP. Through the use of EAP, support authentication methods within PPP. Through the use of EAP, support
for a number of authentication schemes may be added, including smart for a number of authentication schemes may be added, including smart
cards, Kerberos, Public Key, One Time Passwords, and others. In cards, Kerberos, Public Key, One Time Passwords, and others. In
order to provide for support of EAP within RADIUS, two new order to provide for support of EAP within RADIUS, two new
attributes, EAP-Message and Signature, are introduced in this attributes, EAP-Message and Message-Authenticator, are introduced in
document. This section describes how these new attributes may be used this document. This section describes how these new attributes may be
for providing EAP support within RADIUS. used for providing EAP support within RADIUS.
In the proposed scheme, the RADIUS server is used to shuttle RADIUS- In the proposed scheme, the RADIUS server is used to shuttle RADIUS-
encapsulated EAP Packets between the NAS and a backend security encapsulated EAP Packets between the NAS and a backend security
server. While the conversation between the RADIUS server and the server. While the conversation between the RADIUS server and the
backend security server will typically occur using a proprietary backend security server will typically occur using a proprietary
protocol developed by the backend security server vendor, it is also protocol developed by the backend security server vendor, it is also
possible to use RADIUS-encapsulated EAP via the EAP-Message possible to use RADIUS-encapsulated EAP via the EAP-Message
attribute. This has the advantage of allowing the RADIUS server to attribute. This has the advantage of allowing the RADIUS server to
support EAP without the need for authentication-specific code, which support EAP without the need for authentication-specific code, which
can instead reside on the backend security server. can instead reside on the backend security server.
skipping to change at page 13, line 4 skipping to change at page 13, line 7
In order to permit non-EAP aware RADIUS proxies to forward the In order to permit non-EAP aware RADIUS proxies to forward the
Access-Request packet, if the NAS sends the EAP-Request/Identity, the Access-Request packet, if the NAS sends the EAP-Request/Identity, the
NAS MUST copy the contents of the EAP-Response/Identity into the NAS MUST copy the contents of the EAP-Response/Identity into the
User-Name attribute and MUST include the EAP-Response/Identity in the User-Name attribute and MUST include the EAP-Response/Identity in the
User-Name attribute in every subsequent Access-Request. NAS-Port or User-Name attribute in every subsequent Access-Request. NAS-Port or
NAS-Port-Id SHOULD be included in the attributes issued by the NAS in NAS-Port-Id SHOULD be included in the attributes issued by the NAS in
the Access-Request packet, and either NAS-Identifier or NAS-IP- the Access-Request packet, and either NAS-Identifier or NAS-IP-
Address MUST be included. In order to permit forwarding of the Address MUST be included. In order to permit forwarding of the
Access-Reply by EAP-unaware proxies, if a User-Name attribute was Access-Reply by EAP-unaware proxies, if a User-Name attribute was
DRAFT RADIUS Extensions December 1999
included in an Access-Request, the RADIUS Server MUST include the included in an Access-Request, the RADIUS Server MUST include the
User-Name attribute in subsequent Access-Accept packets. Without the User-Name attribute in subsequent Access-Accept packets. Without the
User-Name attribute, accounting and billing becomes very difficult to User-Name attribute, accounting and billing becomes very difficult to
manage. manage.
If identity is determined via another means such as Called-Station-Id If identity is determined via another means such as Called-Station-Id
or Calling-Station-Id, the NAS MUST include these identifying or Calling-Station-Id, the NAS MUST include these identifying
attributes in every Access-Request. attributes in every Access-Request.
While this approach will save a round-trip, it cannot be universally While this approach will save a round-trip, it cannot be universally
skipping to change at page 14, line 4 skipping to change at page 14, line 7
Message attribute encapsulating EAP-Failure, MUST result in the NAS Message attribute encapsulating EAP-Failure, MUST result in the NAS
issuing an LCP Terminate Request to the authenticating peer. A issuing an LCP Terminate Request to the authenticating peer. A
RADIUS Access-Accept packet with an EAP-Message attribute RADIUS Access-Accept packet with an EAP-Message attribute
encapsulating EAP-Success successfully ends the authentication phase. encapsulating EAP-Success successfully ends the authentication phase.
The RADIUS Access-Accept/EAP-Message/EAP-Success packet MUST contain The RADIUS Access-Accept/EAP-Message/EAP-Success packet MUST contain
all of the expected attributes which are currently returned in an all of the expected attributes which are currently returned in an
Access-Accept packet. Access-Accept packet.
The above scenario creates a situation in which the NAS never needs The above scenario creates a situation in which the NAS never needs
to manipulate an EAP packet. An alternative may be used in to manipulate an EAP packet. An alternative may be used in
DRAFT RADIUS Extensions December 1999
situations where an EAP-Request/Identity message will always be sent situations where an EAP-Request/Identity message will always be sent
by the NAS to the authenticating peer. by the NAS to the authenticating peer.
For proxied RADIUS requests there are two methods of processing. If For proxied RADIUS requests there are two methods of processing. If
the domain is determined based on the Called-Station-Id, the RADIUS the domain is determined based on the Called-Station-Id, the RADIUS
Server may proxy the initial RADIUS Access-Request/EAP-Start. If the Server may proxy the initial RADIUS Access-Request/EAP-Start. If the
domain is determined based on the user's identity, the local RADIUS domain is determined based on the user's identity, the local RADIUS
Server MUST respond with a RADIUS Access-Challenge/EAP-Identity Server MUST respond with a RADIUS Access-Challenge/EAP-Identity
packet. The response from the authenticating peer MUST be proxied to packet. The response from the authenticating peer MUST be proxied to
the final authentication server. the final authentication server.
skipping to change at page 15, line 4 skipping to change at page 15, line 8
If Session-Timeout is present in an Access-Challenge packet that also If Session-Timeout is present in an Access-Challenge packet that also
contains an EAP-Message, the value of the Session-Timeout provides contains an EAP-Message, the value of the Session-Timeout provides
the NAS with the maximum number of seconds the NAS should wait for an the NAS with the maximum number of seconds the NAS should wait for an
EAP-Response before retransmitting the EAP-Message to the dial-in EAP-Response before retransmitting the EAP-Message to the dial-in
user. user.
2.3.3. Fragmentation 2.3.3. Fragmentation
Using the EAP-Message attribute, it is possible for the RADIUS server Using the EAP-Message attribute, it is possible for the RADIUS server
DRAFT RADIUS Extensions December 1999
to encapsulate an EAP packet that is larger than the MTU on the link to encapsulate an EAP packet that is larger than the MTU on the link
between the NAS and the peer. Since it is not possible for the RADIUS between the NAS and the peer. Since it is not possible for the RADIUS
server to use MTU discovery to ascertain the link MTU, the Framed-MTU server to use MTU discovery to ascertain the link MTU, the Framed-MTU
attribute may be included in an Access-Request packet containing an attribute may be included in an Access-Request packet containing an
EAP-Message attribute so as to provide the RADIUS server with this EAP-Message attribute so as to provide the RADIUS server with this
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
skipping to change at page 16, line 4 skipping to change at page 16, line 7
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
DRAFT RADIUS Extensions December 1999
(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
skipping to change at page 17, line 4 skipping to change at page 17, line 7
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)
DRAFT RADIUS Extensions December 1999
<- 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 Autheticating Peer NAS RADIUS Server
------------------- --- ------------- ------------------- --- -------------
skipping to change at page 18, line 5 skipping to change at page 18, line 7
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)
DRAFT RADIUS Extensions December 1999
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 EAP-
Message, the conversation would appear as follows: 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 ->
skipping to change at page 19, line 4 skipping to change at page 19, line 7
Identity Identity
(MyID) -> (MyID) ->
RADIUS RADIUS
Access-Request/ Access-Request/
EAP-Message/EAP-Response/ EAP-Message/EAP-Response/
(MyID) -> (MyID) ->
<- RADIUS <- RADIUS
Access-Reject Access-Reject
(proxied from remote (proxied from remote
RADIUS Server) RADIUS Server)
DRAFT RADIUS Extensions December 1999
<- PPP LCP Terminate <- PPP LCP Terminate
(User Disconnected) (User Disconnected)
In the case where the authenticating peer does not support EAP, but In the case where the authenticating peer does not support EAP, but
where EAP is required for that user, the conversation would appear as where EAP is required for that user, the conversation would appear as
follows: follows:
Authenticating Peer NAS RADIUS Server Authenticating Peer NAS RADIUS Server
------------------- --- ------------- ------------------- --- -------------
skipping to change at page 20, line 4 skipping to change at page 20, line 7
auth -> auth ->
<- PPP CHAP Challenge <- PPP CHAP Challenge
PPP CHAP Response -> PPP CHAP Response ->
RADIUS RADIUS
Access-Request/ Access-Request/
User-Name, User-Name,
CHAP-Password -> CHAP-Password ->
<- RADIUS <- RADIUS
Access-Reject Access-Reject
<- PPP LCP Terminate <- PPP LCP Terminate
DRAFT RADIUS Extensions December 1999
(User Disconnected) (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 20, line 33
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 2138 and 2139. Packet Format is identical to that defined in RFC xxxx [1] and yyyy
[2]
4. Packet Types 4. Packet Types
Packet types are identical to those defined in RFC 2138 and 2139. Packet types are identical to those defined in RFC xxxx [1] and yyyy
[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.
DRAFT RADIUS Extensions December 1999
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 2138 but is A summary of the attribute format is the same as in RFC xxxx [1] but
included here for ease of reference. The fields are transmitted from is included here for ease of reference. The fields are transmitted
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 2138, "RADIUS") 1-39 (refer to RFC xxxx [1], "RADIUS")
40-51 (refer to RFC 2139, "RADIUS Accounting") 40-51 (refer to RFC yyyy [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 2138, "RADIUS") 60-63 (refer to RFC xxxx [1], "RADIUS")
64-67 (refer to "RADIUS Attributes for Tunnel Protocol Support" draft) 64-67 (refer to [6])
68 (refer to "RADIUS Tunnel Accounting Support" draft) 68 (refer to [7])
69 (refer to "RADIUS Attributes for Tunnel Protocol Support" draft) 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
77 Connect-Info 77 Connect-Info
78 Configuration-Token 78 Configuration-Token
79 EAP-Message 79 EAP-Message
80 Signature 80 Message-Authenticator
81-83 (refer to "RADIUS Attributes for Tunnel Protocol Support" draft) 81-83 (refer to [6])
84 ARAP-Challenge-Response 84 ARAP-Challenge-Response
85 Acct-Interim-Interval 85 Acct-Interim-Interval
86 (refer to [7])
DRAFT RADIUS Extensions December 1999
86 (refer to "RADIUS Tunneling Accounting Support" draft)
87 NAS-Port-Id 87 NAS-Port-Id
88 Framed-Pool 88 Framed-Pool
89 Unused 89 Unused
90-91 (refer to "RADIUS Attributes for Tunnel Protocol Support" draft) 90-91 (refer to [6])
92-191 Unused 92-191 Unused
Length Length
The Length field is one octet, and indicates the length of this The Length field is one octet, and indicates the length of this
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
skipping to change at page 23, line 4 skipping to change at page 23, line 12
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
DRAFT RADIUS Extensions December 1999
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.
A summary of the Acct-Input-Gigawords attribute format is shown A summary of the Acct-Input-Gigawords attribute format is shown
below. The fields are transmitted from left to right. below. 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 24, line 5 skipping to change at page 24, line 13
below. The fields are transmitted from left to right. below. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) | Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DRAFT RADIUS Extensions December 1999
Type Type
53 for Acct-Output-Gigawords. 53 for Acct-Output-Gigawords.
Length Length
6 6
Value Value
skipping to change at page 24, line 41 skipping to change at page 25, line 4
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) | Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
55 for Event-Timestamp 55 for Event-Timestamp
Length Length
6 6
Value Value
The Value field is four octets encoding an unsigned integer with The Value field is four octets encoding an unsigned integer with
the number of seconds since January 1, 1970 00:00 UTC. the number of seconds since January 1, 1970 00:00 UTC.
DRAFT RADIUS Extensions December 1999
5.4. ARAP-Password 5.4. ARAP-Password
Description Description
This attribute is only present in an Access-Request packet This attribute is only present in an Access-Request packet
containing a Framed-Protocol of ARAP. containing a Framed-Protocol of ARAP.
Only one of User-Password, CHAP-Password, or ARAP-Password needs Only one of User-Password, CHAP-Password, or ARAP-Password needs
to be present in an Access-Request, or one or more EAP-Messages. to be present in an Access-Request, or one or more EAP-Messages.
skipping to change at page 26, line 5 skipping to change at page 26, line 14
Value Value
This attribute contains a 16 octet string, used to carry the 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 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) 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, 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 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 dial-in user's response to the NAS challenge (2 32-bit numbers, 8
octets). octets).
DRAFT RADIUS Extensions December 1999
5.5. ARAP-Features 5.5. ARAP-Features
Description Description
This attribute is sent in an Access-Accept packet with Framed- This attribute is sent in an Access-Accept packet with Framed-
Protocol of ARAP, and includes password information that the NAS Protocol of ARAP, and includes password information that the NAS
should sent to the user in an ARAP "feature flags" packet. should sent to the user in an ARAP "feature flags" packet.
A summary of the ARAP-Features attribute format is shown below. The A summary of the ARAP-Features attribute format is shown below. The
fields are transmitted from left to right. fields are transmitted from left to right.
skipping to change at page 27, line 5 skipping to change at page 27, line 17
the attribute which indicates whether ARAP indicates they can.) the attribute which indicates whether ARAP indicates they can.)
Value2: Minimum acceptable password length, from 0 to 8. Value2: Minimum acceptable password length, from 0 to 8.
Value3: Password creation date in Macintosh format, defined as Value3: Password creation date in Macintosh format, defined as
32 unsigned bits representing seconds since Midnight GMT 32 unsigned bits representing seconds since Midnight GMT
January 1, 1904. January 1, 1904.
Value4: Password Expiration Delta from create date in seconds. Value4: Password Expiration Delta from create date in seconds.
DRAFT RADIUS Extensions December 1999
Value5: Current RADIUS time in Macintosh format. Value5: Current RADIUS time in Macintosh format.
5.6. ARAP-Zone-Access 5.6. ARAP-Zone-Access
Description Description
This attribute is included in an Access-Accept packet with This attribute is included in an Access-Accept packet with
Framed-Protocol of ARAP to indicate how the ARAP zone list for the Framed-Protocol of ARAP to indicate how the ARAP zone list for the
user should be used. user should be used.
skipping to change at page 28, line 4 skipping to change at page 28, line 15
1 Only allow access to default zone 1 Only allow access to default zone
2 Use zone filter inclusively 2 Use zone filter inclusively
4 Use zone filter exclusively 4 Use zone filter exclusively
The value 3 is skipped, not because these are bit flags, but The value 3 is skipped, not because these are bit flags, but
because 3 in some ARAP implementations means "all zones" which is because 3 in some ARAP implementations means "all zones" which is
the same as not specifying a list at all under RADIUS. 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 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 Filter-Id must also be present to name a zone list filter to apply
DRAFT RADIUS Extensions December 1999
the access flag to. the access flag to.
5.7. ARAP-Security 5.7. ARAP-Security
Description Description
This attribute identifies the ARAP Security Module to be used in This attribute identifies the ARAP Security Module to be used in
an Access-Challenge packet. an Access-Challenge packet.
A summary of the ARAP-Security attribute format is shown below. The A summary of the ARAP-Security attribute format is shown below. The
skipping to change at page 29, line 5 skipping to change at page 29, line 14
integer) integer)
5.8. ARAP-Security-Data 5.8. ARAP-Security-Data
Description Description
This attribute contains the actual security module challenge or This attribute contains the actual security module challenge or
response, and can be found in Access-Challenge and Access-Request response, and can be found in Access-Challenge and Access-Request
packets. packets.
DRAFT RADIUS Extensions December 1999
A summary of the ARAP-Security-Data attribute format is shown below. A summary of the ARAP-Security-Data attribute format is shown below.
The fields are transmitted from left to right. The 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 | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
skipping to change at page 30, line 5 skipping to change at page 30, line 16
fields are transmitted from left to right. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) | Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DRAFT RADIUS Extensions December 1999
Type Type
75 for Password-Retry. 75 for Password-Retry.
Length Length
6 6
Value Value
skipping to change at page 31, line 5 skipping to change at page 31, line 16
76 for Prompt. 76 for Prompt.
Length Length
6 6
Value Value
The Value field is four octets. The Value field is four octets.
DRAFT RADIUS Extensions December 1999
0 No Echo 0 No Echo
1 Echo 1 Echo
5.11. Connect-Info 5.11. Connect-Info
Description Description
This attribute is sent from the NAS to indicate the nature of the This attribute is sent from the NAS to indicate the nature of the
user's connection. user's connection.
skipping to change at page 31, line 37 skipping to change at page 32, line 4
| Type | Length | String... | Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
77 for Connect-Info. 77 for Connect-Info.
Length Length
>= 3 >= 3
String String
The String field is encoded as UTF-8 [6] characters. The The String field is encoded as UTF-8 [8] characters. The
connection speed SHOULD be included at the beginning of the first connection speed SHOULD be included at the beginning of the first
Connect-Info attribute in the packet. If the transmit and receive Connect-Info attribute in the packet. If the transmit and receive
connection speeds differ, they may both be included in the first connection speeds differ, they may both be included in the first
attribute with the transmit speed first (the speed the NAS modem attribute with the transmit speed first (the speed the NAS modem
transmits at), a slash (/), the receive speed, then optionally transmits at), a slash (/), the receive speed, then optionally
other information. other information.
For example, "28800 V42BIS/LAPM" or "52000/31200 V90" For example, "28800 V42BIS/LAPM" or "52000/31200 V90"
DRAFT RADIUS Extensions December 1999
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
Description Description
This attribute is for use in large distributed authentication This attribute is for use in large distributed authentication
skipping to change at page 33, line 5 skipping to change at page 33, line 17
information is site or application specific, and a robust information is site or application specific, and a robust
implementation SHOULD support the field as undistinguished octets. implementation SHOULD support the field as undistinguished octets.
The codification of the range of allowed usage of this field is The codification of the range of allowed usage of this field is
outside the scope of this specification. outside the scope of this specification.
5.13. EAP-Message 5.13. EAP-Message
Description Description
DRAFT RADIUS Extensions December 1999
This attribute encapsulates Extended Access Protocol [3] packets This attribute encapsulates Extended Access Protocol [3] packets
so as to allow the NAS to authenticate dial-in users via EAP so as to allow the NAS to authenticate dial-in users via EAP
without having to understand the EAP protocol. without having to understand the EAP protocol.
The NAS places any EAP messages received from the user into one or 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 more EAP attributes and forwards them to the RADIUS Server as part
of the Access-Request, which can return EAP messages in Access- of the Access-Request, which can return EAP messages in Access-
Challenge, Access-Accept and Access-Reject packets. Challenge, Access-Accept and Access-Reject packets.
A RADIUS Server receiving EAP messages that it does not understand A RADIUS Server receiving EAP messages that it does not understand
skipping to change at page 33, line 37 skipping to change at page 33, line 47
Failure. Failure.
It is expected that EAP will be used to implement a variety of It is expected that EAP will be used to implement a variety of
authentication methods, including methods involving strong authentication methods, including methods involving strong
cryptography. In order to prevent attackers from subverting EAP by cryptography. In order to prevent attackers from subverting EAP by
attacking RADIUS/EAP, (for example, by modifying the EAP-Success attacking RADIUS/EAP, (for example, by modifying the EAP-Success
or EAP-Failure packets) it is necessary that RADIUS/EAP provide or EAP-Failure packets) it is necessary that RADIUS/EAP provide
integrity protection at least as strong as those used in the EAP integrity protection at least as strong as those used in the EAP
methods themselves. methods themselves.
Therefore the Signature attribute MUST be used to protect all Therefore the Message-Authenticator attribute MUST be used to
Access-Request, Access-Challenge, Access-Accept, and Access-Reject protect all Access-Request, Access-Challenge, Access-Accept, and
packets containing an EAP-Message attribute. Access-Reject packets containing an EAP-Message attribute.
Access-Request packets including an EAP-Message attribute without Access-Request packets including an EAP-Message attribute without
a Signature attribute SHOULD be silently discarded by the RADIUS a Message-Authenticator attribute SHOULD be silently discarded by
server. A RADIUS Server supporting EAP-Message MUST calculate the the RADIUS server. A RADIUS Server supporting EAP-Message MUST
correct value of the Signature and silently discard the packet if calculate the correct value of the Message-Authenticator and
it does not match the value sent. A RADIUS Server not supporting silently discard the packet if it does not match the value sent.
EAP-Message MUST return an Access-Reject if it receives an A RADIUS Server not supporting EAP-Message MUST return an Access-
Access-Request containing an EAP-Message attribute. A RADIUS Reject if it receives an Access-Request containing an EAP-Message
Server receiving an EAP-Message attribute that it does not attribute. A RADIUS Server receiving an EAP-Message attribute that
understand MUST return an Access-Reject. it does not understand MUST return an Access-Reject.
Access-Challenge, Access-Accept, or Access-Reject packets Access-Challenge, Access-Accept, or Access-Reject packets
including an EAP-Message attribute without a Signature attribute including an EAP-Message attribute without a Message-Authenticator
SHOULD be silently discarded by the NAS. A NAS supporting EAP- attribute SHOULD be silently discarded by the NAS. A NAS
Message MUST calculate the correct value of the Signature and supporting EAP-Message MUST calculate the correct value of the
Message-Authenticator and silently discard the packet if it does
DRAFT RADIUS Extensions December 1999 not match the value sent.
silently discard the packet if it does not match the value sent.
A summary of the EAP-Message attribute format is shown below. The A summary of the EAP-Message 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 | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 34, line 34 skipping to change at page 34, line 47
>= 3 (EAP packet enclosed) >= 3 (EAP packet enclosed)
= 2 (EAP-Start message) = 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. Signature 5.14. Message-Authenticator
Description Description
This attribute MAY be used to sign Access-Requests to prevent This attribute MAY be used to sign Access-Requests to prevent
dictionary attacks on CHAP, ARAP or EAP authentication methods. spoofing Access-Requests using CHAP, ARAP or EAP authentication
It MAY be used in any Access-Request. It MUST be used in any methods. It MAY be used in any Access-Request. It MUST be used
Access-Request, Access-Accept, Access-Reject or Access-Challenge in any Access-Request, Access-Accept, Access-Reject or Access-
that includes an EAP-Message attribute. Challenge that includes an EAP-Message attribute.
A RADIUS Server receiving an Access-Request with a Signature A RADIUS Server receiving an Access-Request with a Message-
Attribute present MUST calculate the correct value of the Authenticator Attribute present MUST calculate the correct value
Signature and silently discard the packet if it does not match the of the Message-Authenticator and silently discard the packet if it
value sent. does not match the value sent.
A RADIUS Client receiving an Access-Accept, Access-Reject or A RADIUS Client receiving an Access-Accept, Access-Reject or
Access-Challenge with a Signature Attribute present MUST calculate Access-Challenge with a Message-Authenticator Attribute present
the correct value of the Signature and silently discard the packet MUST calculate the correct value of the Message-Authenticator and
silently discard the packet if it does not match the value sent.
DRAFT RADIUS Extensions December 1999
if it does not match the value sent. Earlier drafts of this memo used "Signature" as the name of this
attribute, but Message-Authenticator is more precise. Its
operation has not changed, just the name.
A summary of the Signature attribute format is shown below. The A summary of the Message-Authenticator attribute format is shown
fields are transmitted from left to right. below. The 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 | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
80 for Signature. 80 for Message-Authenticator
Length Length
18 18
String String
When present in an Access-Request packet, Signature is an HMAC-MD5 When present in an Access-Request packet, Message-Authenticator is
[7] checksum of the entire Access-Request packet, including Type, an HMAC-MD5 [9] checksum of the entire Access-Request packet,
ID, Length and authenticator, using the shared secret as the key, including Type, ID, Length and authenticator, using the shared
as follows. secret as the key, as follows.
Signature = HMAC-MD5 (Type, Identifier, Length, Request
Authenticator, Attributes)
Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
Request Authenticator, Attributes)
When the checksum is calculated the signature string should be When the checksum is calculated the signature string should be
considered to be sixteen octets of zero. considered to be sixteen octets of zero.
For Access-Challenge, Access-Accept, and Access-Reject packets, For Access-Challenge, Access-Accept, and Access-Reject packets,
the Signature is calculated as follows, using the Request- the Message-Authenticator is calculated as follows, using the
Authenticator from the Access-Request this packet is in reply to: Request-Authenticator from the Access-Request this packet is in
reply to:
Signature = HMAC-MD5 (Type, Identifier, Length, Request Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
Authenticator, Attributes) Request Authenticator, Attributes)
When the checksum is calculated the signature string should be When the checksum is calculated the signature string should be
considered to be sixteen octets of zero. The shared secret is considered to be sixteen octets of zero. The shared secret is
used as the key for the HMAC-MD5 hash. The Signature is used as the key for the HMAC-MD5 hash. The is calculated and
calculated and inserted in the packet before the Response inserted in the packet before the Response Authenticator is
Authenticator is calculated. calculated.
This attribute is not needed if the User-Password attribute is This attribute is not needed if the User-Password attribute is
present, but is useful for preventing dictionary attacks on other present, but is useful for preventing attacks on other types of
authentication. This attribute is intended to thwart attempts by
DRAFT RADIUS Extensions December 1999 an attacker to setup a "rogue" NAS, and perform online dictionary
attacks against the RADIUS server. It does not afford protection
types of authentication. against "offline" attacks where the attacker intercepts packets
containing (for example) CHAP challenge and response, and performs
a dictionary attack against those packets offline.
IP Security will eventually make this attribute unnecessary, so it IP Security will eventually make this attribute unnecessary, so it
should be considered an interim measure. should be considered an interim measure.
5.15. ARAP-Challenge-Response 5.15. ARAP-Challenge-Response
Description Description
This attribute is sent in an Access-Accept packet with Framed- This attribute is sent in an Access-Accept packet with Framed-
Protocol of ARAP, and contains the response to the dial-in Protocol of ARAP, and contains the response to the dial-in
skipping to change at page 37, line 5 skipping to change at page 37, line 34
The Value field contains an 8 octet response to the dial-in The Value field contains an 8 octet response to the dial-in
client's challenge. The RADIUS server calculates this value by client's challenge. The RADIUS server calculates this value by
taking the dial-in client's challenge from the high order 8 octets taking the dial-in client's challenge from the high order 8 octets
of the ARAP-Password attribute and performing DES encryption on of the ARAP-Password attribute and performing DES encryption on
this value with the authenticating user's password as the key. If this value with the authenticating user's password as the key. If
the user's password is less than 8 octets in length, the password the user's password is less than 8 octets in length, the password
is padded at the end with NULL octets to a length of 8 before is padded at the end with NULL octets to a length of 8 before
using it as a key. using it as a key.
DRAFT RADIUS Extensions December 1999
5.16. Acct-Interim-Interval 5.16. Acct-Interim-Interval
Description Description
This attribute indicates the number of seconds between each This attribute indicates the number of seconds between each
interim update in seconds for this specific session. This value interim update in seconds for this specific session. This value
can only appear in the Access-Accept message. can only appear in the Access-Accept message.
A summary of the Acct-Interim-Interval attribute format is shown A summary of the Acct-Interim-Interval attribute format is shown
below. The fields are transmitted from left to right. below. The fields are transmitted from left to right.
skipping to change at page 38, line 5 skipping to change at page 38, line 39
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 string which identifies the port of the
NAS which is authenticating the user. It is only used in Access- NAS which is authenticating the user. It is only used in Access-
Request and Accounting-Request packets. Note that this is using Request and Accounting-Request packets. Note that this is using
"port" in its sense of a physical connection on the NAS, not in "port" in its sense of a physical connection on the NAS, not in
the sense of a TCP or UDP port number. the sense of a TCP or UDP port number.
DRAFT RADIUS Extensions December 1999
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
skipping to change at page 38, line 31 skipping to change at page 39, line 21
Type Type
87 for NAS-Port-Id. 87 for NAS-Port-Id.
Length Length
>= 3 >= 3
String String
The String field contains the name of the port in UTF-8 [6] The String field contains the name of the port in UTF-8 [8]
format. format.
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
those protocols. those protocols.
A summary of the Framed-Pool Attribute format is shown below. The A summary of the Framed-Pool Attribute format is shown below. The
fields are transmitted from left to right. fields are transmitted from left to right.
DRAFT RADIUS Extensions December 1999
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 | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
88 for Framed-Pool 88 for Framed-Pool
Length Length
>= 3 >= 3
String String
skipping to change at page 39, line 46 skipping to change at page 40, line 37
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 Signature [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
DRAFT RADIUS Extensions December 1999
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
Signature. If any packet type contains an EAP-Message attribute it Message-Authenticator. If any packet type contains an EAP-Message
MUST also contain a Signature. attribute it MUST also contain a Message-Authenticator.
The following table defines the above table entries. The following table defines the above table entries.
0 This attribute MUST NOT be present 0 This attribute MUST NOT be present
0+ Zero or more instances of this attribute MAY 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. 0-1 Zero or one instance of this attribute MAY be present.
1 Exactly one instance of this attribute MUST be present. 1 Exactly one instance of this attribute MUST be present.
6. Security Considerations 6. IANA Considerations
The attributes other than Signature and EAP-Message in this document The Packet Type Codes, Attribute Types, and Attribute Values defined
have no additional security considerations beyond those already in this document are registered by the Internet Assigned Numbers
identified in RFC 2138 [1]. Authority (IANA) from the RADIUS name spaces as described in the
"IANA Considerations" section of [1], in accordance with BCP 26 [10].
6.1. Signature Security 7. Security Considerations
The attributes other than Message-Authenticator and EAP-Message in
this document have no additional security considerations beyond those
already identified in [1].
7.1. Message-Authenticator Security
Access-Request packets with a User-Password establish the identity of Access-Request packets with a User-Password establish the identity of
both the user and the NAS sending the Access-Request, because of the both the user and the NAS sending the Access-Request, because of the
way the shared secret between NAS and RADIUS server is used. way the shared secret between NAS and RADIUS server is used.
Access-Request packets with CHAP-Password or EAP-Message do not have Access-Request packets with CHAP-Password or EAP-Message do not have
a User-Password attribute, so the Signature attribute should be used a User-Password attribute, so the Message-Authenticator attribute
in access-request packets that do not have a User-Password, in order should be used in access-request packets that do not have a User-
to establish the identity of the NAS sending the request. Password, in order to establish the identity of the NAS sending the
request.
6.2. EAP Security 7.2. EAP Security
Since the purpose of EAP is to provide enhanced security for PPP Since the purpose of EAP is to provide enhanced security for PPP
authentication, it is critical that RADIUS support for EAP be secure. authentication, it is critical that RADIUS support for EAP be secure.
In particular, the following issues must be addressed: In particular, the following issues must be addressed:
Separation of EAP server and PPP authenticator Separation of EAP server and PPP authenticator
Connection hijacking Connection hijacking
Man in the middle attacks Man in the middle attacks
Multiple databases Multiple databases
Negotiation attacks Negotiation attacks
DRAFT RADIUS Extensions December 1999 7.2.1. Separation of EAP server and PPP authenticator
6.2.1. Separation of EAP server and PPP authenticator
It is possible for the EAP endpoints to mutually authenticate, It is possible for the EAP endpoints to mutually authenticate,
negotiate a ciphersuite, and derive a session key for subsequent use negotiate a ciphersuite, and derive a session key for subsequent use
in PPP encryption. in PPP encryption.
This does not present an issue on the peer, since the peer and EAP This does not present an issue on the peer, since the peer and EAP
client reside on the same machine; all that is required is for the client reside on the same machine; all that is required is for the
EAP client module to pass the session key to the PPP encryption EAP client module to pass the session key to the PPP encryption
module. module.
skipping to change at page 41, line 31 skipping to change at page 42, line 29
server, or a module residing on the RADIUS server. server, or a module residing on the RADIUS server.
In the case where the EAP server and PPP authenticator reside on In the case where the EAP server and PPP authenticator reside on
different machines, there are several implications for security. different machines, there are several implications for security.
Firstly, mutual authentication will occur between the peer and the Firstly, mutual authentication will occur between the peer and the
EAP server, not between the peer and the authenticator. This means EAP server, not between the peer and the authenticator. This means
that it is not possible for the peer to validate the identity of the that it is not possible for the peer to validate the identity of the
NAS or tunnel server that it is speaking to. NAS or tunnel server that it is speaking to.
As described earlier, when EAP/RADIUS is used to encapsulate EAP As described earlier, when EAP/RADIUS is used to encapsulate EAP
packets, the Signature attribute is required in EAP/RADIUS Access- packets, the Message-Authenticator attribute is required in
Requests sent from the NAS or tunnel server to the RADIUS server. EAP/RADIUS Access-Requests sent from the NAS or tunnel server to the
Since the Signature attribute involves a HMAC-MD5 hash, it is RADIUS server. Since the Message-Authenticator attribute involves a
possible for the RADIUS server to verify the integrity of the HMAC-MD5 hash, it is possible for the RADIUS server to verify the
Access-Request as well as the NAS or tunnel server's identity. integrity of the Access-Request as well as the NAS or tunnel server's
Similarly, Access-Challenge packets sent from the RADIUS server to identity. Similarly, Access-Challenge packets sent from the RADIUS
the NAS are also authenticated and integrity protected using an server to the NAS are also authenticated and integrity protected
HMAC-MD5 hash, enabling the NAS or tunnel server to determine the using an HMAC-MD5 hash, enabling the NAS or tunnel server to
integrity of the packet and verify the identity of the RADIUS server. determine the integrity of the packet and verify the identity of the
Morever, EAP packets sent via methods that contain their own RADIUS server. Morever, EAP packets sent via methods that contain
integrity protection cannot be successfully modified by a rogue NAS their own integrity protection cannot be successfully modified by a
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
document. document.
DRAFT RADIUS Extensions December 1999 7.2.2. Connection hijacking
6.2.2. Connection hijacking
In this form of attack, the attacker attempts to inject packets into In this form of attack, the attacker attempts to inject packets into
the conversation between the NAS and the RADIUS server, or between the conversation between the NAS and the RADIUS server, or between
the RADIUS server and the backend security server. RADIUS does not the RADIUS server and the backend security server. RADIUS does not
support encryption, and as described in [1], only Access-Reply and support encryption, and as described in [1], only Access-Reply and
Access-Challenge packets are integrity protected. Moreover, the Access-Challenge packets are integrity protected. Moreover, the
integrity protection mechanism described in [1] is weaker than that integrity protection mechanism described in [1] is weaker than that
likely to be used by some EAP methods, making it possible to subvert likely to be used by some EAP methods, making it possible to subvert
those methods by attacking EAP/RADIUS. those methods by attacking EAP/RADIUS.
In order to provide for authentication of all packets in the EAP In order to provide for authentication of all packets in the EAP
exchange, all EAP/RADIUS packets MUST be authenticated using the exchange, all EAP/RADIUS packets MUST be authenticated using the
Signature attribute, as described previously. Message-Authenticator attribute, as described previously.
6.2.3. Man in the middle attacks 7.2.3. Man in the middle attacks
Since RADIUS security is based on shared secrets, end-to-end security Since RADIUS security is based on shared secrets, end-to-end security
is not provided in the case where authentication or accounting is not provided in the case where authentication or accounting
packets are forwarded along a proxy chain. As a result, attackers packets are forwarded along a proxy chain. As a result, attackers
gaining control of a RADIUS proxy will be able to modify EAP packets gaining control of a RADIUS proxy will be able to modify EAP packets
in transit. in transit.
6.2.4. Multiple databases 7.2.4. Multiple databases
In many cases a backend security server will be deployed along with a In many cases a backend security server will be deployed along with a
RADIUS server in order to provide EAP services. Unless the backend RADIUS server in order to provide EAP services. Unless the backend
security server also functions as a RADIUS server, two separate user security server also functions as a RADIUS server, two separate user
databases will exist, each containing information about the security databases will exist, each containing information about the security
requirements for the user. This represents a weakness, since security requirements for the user. This represents a weakness, since security
may be compromised by a successful attack on either of the servers, may be compromised by a successful attack on either of the servers,
or their backend databases. With multiple user databases, adding a or their backend databases. With multiple user databases, adding a
new user may require multiple operations, increasing the chances for new user may require multiple operations, increasing the chances for
error. The problems are further magnified in the case where user error. The problems are further magnified in the case where user
information is also being kept in an LDAP server. In this case, three information is also being kept in an LDAP server. In this case, three
stores of user information may exist. stores of user information may exist.
In order to address these threats, consolidation of databases is In order to address these threats, consolidation of databases is
recommended. This can be achieved by having both the RADIUS server recommended. This can be achieved by having both the RADIUS server
and backend security server store information in the same backend and backend security server store information in the same backend
database; by having the backend security server provide a full RADIUS database; by having the backend security server provide a full RADIUS
implementation; or by consolidating both the backend security server implementation; or by consolidating both the backend security server
and the RADIUS server onto the same machine. and the RADIUS server onto the same machine.
DRAFT RADIUS Extensions December 1999 7.2.5. Negotiation attacks
6.2.5. Negotiation attacks
In a negotiation attack, a rogue NAS, tunnel server, RADIUS proxy or In a negotiation attack, a rogue NAS, tunnel server, RADIUS proxy or
RADIUS server causes the authenticating peer to choose a less secure RADIUS server causes the authenticating peer to choose a less secure
authentication method so as to make it easier to obtain the user's authentication method so as to make it easier to obtain the user's
password. For example, a session that would normally be authenticated password. For example, a session that would normally be authenticated
with EAP would instead authenticated via CHAP or PAP; alternatively, with EAP would instead authenticated via CHAP or PAP; alternatively,
a connection that would normally be authenticated via one EAP type a connection that would normally be authenticated via one EAP type
occurs via a less secure EAP type, such as MD5. The threat posed by occurs via a less secure EAP type, such as MD5. The threat posed by
rogue devices, once thought to be remote, has gained currency given rogue devices, once thought to be remote, has gained currency given
compromises of telephone company switching systems, such as those compromises of telephone company switching systems, such as those
described in [8]. described in [11].
Protection against negotiation attacks requires the elimination of Protection against negotiation attacks requires the elimination of
downward negotiations. This can be achieved via implementation of downward negotiations. This can be achieved via implementation of
per-connection policy on the part of the authenticating peer, and per-connection policy on the part of the authenticating peer, and
per-user policy on the part of the RADIUS server. per-user policy on the part of the RADIUS server.
For the authenticating peer, authentication policy should be set on a For the authenticating peer, authentication policy should be set on a
per-connection basis. Per-connection policy allows an authenticating per-connection basis. Per-connection policy allows an authenticating
peer to negotiate EAP when calling one service, while negotiating peer to negotiate EAP when calling one service, while negotiating
CHAP for another service, even if both services are accessible via CHAP for another service, even if both services are accessible via
skipping to change at page 44, line 4 skipping to change at page 45, line 4
implement EAP while another does not. In such cases, if any users of implement EAP while another does not. In such cases, if any users of
the NAS MUST do EAP, then the NAS MUST attempt to negotiate EAP for the NAS MUST do EAP, then the NAS MUST attempt to negotiate EAP for
every call. This avoids forcing an EAP-capable client to do more than every call. This avoids forcing an EAP-capable client to do more than
one authentication, which weakens security. one authentication, which weakens security.
If CHAP is negotiated, the NAS will pass the User-Name and CHAP- If CHAP is negotiated, the NAS will pass the User-Name and CHAP-
Password attributes to the RADIUS Server in an Access-Request packet. Password attributes to the RADIUS Server in an Access-Request packet.
If the user is not required to use EAP, then the RADIUS Server will If the user is not required to use EAP, then the RADIUS Server will
respond with an Access-Accept or Access-Reject packet as appropriate. respond with an Access-Accept or Access-Reject packet as appropriate.
However, if CHAP has been negotiated but EAP is required, the RADIUS However, if CHAP has been negotiated but EAP is required, the RADIUS
DRAFT RADIUS Extensions December 1999
server MUST respond with an Access-Reject, rather than an Access- server MUST respond with an Access-Reject, rather than an Access-
Challenge/EAP-Message/EAP-Request packet. The authenticating peer Challenge/EAP-Message/EAP-Request packet. The authenticating peer
MUST refuse to renegotiate authentication, even if the renegotiation MUST refuse to renegotiate authentication, even if the renegotiation
is from CHAP to EAP. is from CHAP to EAP.
If EAP is negotiated but is not supported by the RADIUS proxy or If EAP is negotiated but is not supported by the RADIUS proxy or
server, then the server or proxy MUST respond with an Access-Reject. server, then the server or proxy MUST respond with an Access-Reject.
In these cases, the NAS MUST send an LCP-Terminate and disconnect the In these cases, the NAS MUST send an LCP-Terminate and disconnect the
user. This is the correct behavior since the authenticating peer is user. This is the correct behavior since the authenticating peer is
expecting EAP to be negotiated, and that expectation cannot be expecting EAP to be negotiated, and that expectation cannot be
fulfilled. An EAP-capable authenticating peer MUST refuse to fulfilled. An EAP-capable authenticating peer MUST refuse to
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.
7. References 8. References
[1] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote [1] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2138, April Authentication Dial In User Service (RADIUS)", RFC xxxx,
1997. February 2000.
[2] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997. [2] Rigney, C., "RADIUS Accounting", RFC yyyy, February 2000.
[3] Blunk, L., and Vollbrecht, J., "PPP Extensible Authentication [3] Blunk, L., and Vollbrecht, J., "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, Harvard University, 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, USC/Information Sciences Institute, October 1994. 1700, USC/Information Sciences Institute, October 1994.
[6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC [6] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M.,
and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support",
draft-ietf-radius-tunnel-auth-09.txt, August 1999.
[7] Zorn, G., Mitton, D., and B. Aboba, "RADIUS Accounting
Modifications for Tunnel Protocol Support" draft-ietf-radius-
tunnel-acct-05.txt, October 1999.
[8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998. 2279, January 1998.
[7] 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.
[8] Slatalla, M., and Quittner, J., "Masters of Deception." [10] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
HarperCollins, New York, 1995. Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.
DRAFT RADIUS Extensions December 1999 [11] Slatalla, M., and Quittner, J., "Masters of Deception."
HarperCollins, New York, 1995.
8. 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 Internet-Draft 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
Internet-Draft by Pat Calhoun of Sun Microsystems, Allan Rubens of Internet-Draft by Pat Calhoun of Sun Microsystems, Allan Rubens of
Merit Network, and Bernard Aboba of Microsoft. Thanks also to Dave Merit Network, and Bernard Aboba of Microsoft. Thanks also to Dave
Dawson and Karl Fox of Ascend, and Glen Zorn and Narendra Gidwani of Dawson 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.
9. 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 Phone: +1 925 737 2100
E-Mail: cdr@livingston.com E-Mail: cdr@livingston.com
10. Author's Address 11. Author's Address
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 E-Mail: cdr@livingston.com
Questions on ARAP and RADIUS may be directed to: Questions on ARAP and RADIUS may be directed to:
Ward Willats Ward Willats
DRAFT RADIUS Extensions December 1999
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 Phone: +1 408 297 7766
E-Mail: ward@cyno.com E-Mail: 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
skipping to change at page 47, line 5 skipping to change at page 48, line 5
Phone: +1 313 647 0417 Phone: +1 313 647 0417
E-Mail: acr@merit.edu E-Mail: acr@merit.edu
Bernard Aboba Bernard Aboba
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
Phone: +1 425 936 6605 Phone: +1 425 936 6605
E-Mail: bernarda@microsoft.com E-Mail: bernarda@microsoft.com
DRAFT RADIUS Extensions December 1999 12. Full Copyright Statement
11. Full Copyright Statement
Copyright (C) The Internet Society (1999). 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 implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are 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
 End of changes. 114 change blocks. 
257 lines changed or deleted 177 lines changed or added

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