draft-ietf-radius-ext-02.txt   draft-ietf-radius-ext-03.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
expires in six months October 1998 P Calhoun
Sun Microsystems
expires September 1999 February 1999
RADIUS Extensions RADIUS Extensions
draft-ietf-radius-ext-02.txt draft-ietf-radius-ext-03.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with
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.
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
This document is an Internet-Draft. Internet-Drafts are working Internet-Drafts are working documents of the Internet Engineering
documents of the Internet Engineering Task Force (IETF), its areas, Task Force (IETF), its areas, and its working groups. Note that
and its working groups. Note that other groups may also distribute other groups may also distribute working documents as Internet-
working documents as Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.'' material or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the The list of current Internet-Drafts can be accessed at
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow http://www.ietf.org/ietf/1id-abstracts.txt
Directories on on ftp.is.co.za (Africa), ftp.nordu.net,
ftp.nis.garr.it (Europe), munnari.oz.au (Pacific Rim), The list of Internet-Draft Shadow Directories can be accessed at
ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract Abstract
This document describes additional attributes for carrying This document describes additional attributes for carrying
authentication, authorization and accounting information between a authentication, authorization and accounting information between a
Network Access Server (NAS) and a shared Accounting Server using the Network Access Server (NAS) and a shared Accounting Server using the
Remote Authentication Dial In User Service (RADIUS) protocol Remote Authentication Dial In User Service (RADIUS) protocol
described in RFC 2138 and RFC 2139. described in RFC 2138 and RFC 2139.
Table of Contents Table of Contents
1. Introduction .......................................... 1 1. Introduction .......................................... 4
1.1 Specification of Requirements ................... 1 1.1 Specification of Requirements ................... 4
1.2 Terminology ..................................... 2 1.2 Terminology ..................................... 4
2. Operation ............................................. 3
2.1 RADIUS support for Interim Accounting Updates
2.2 RADIUS support for Apple Remote Access Protocol . 3
2.3 RADIUS Support for EAP .......................... 9
2.3.1 Protocol Overview ............................... 10
2.3.2 Retransmission .................................. 12
2.3.3 Fragmentation ................................... 12
2.3.4 Examples ........................................ 12
2.3.5 Alternative uses ................................ 17
3. Packet Format ......................................... 18 2. Operation ............................................. 5
2.1 RADIUS support for Interim Accounting Updates 5
2.2 RADIUS support for Apple Remote Access Protocol 6
2.3 RADIUS Support for Extensible Authentication
Protocol (EAP) ........................... 12
2.3.1 Protocol Overview ............................... 12
2.3.2 Retransmission .................................. 14
2.3.3 Fragmentation ................................... 15
2.3.4 Examples ........................................ 15
2.3.5 Alternative uses ................................ 20
4. Packet Types .......................................... 18 3. Packet Format ......................................... 20
5. Attributes ............................................ 18 4. Packet Types .......................................... 20
5.1 Acct-Input-Gigawords ............................ 20
5.2 Acct-Output-Gigawords ........................... 21
5.3 Event-Timestamp ................................. 21
5.4 ARAP-Password ................................... 22
5.5 ARAP-Features ................................... 23
5.6 ARAP-Zone-Access ................................ 24
5.7 ARAP-Security ................................... 25
5.8 ARAP-Security-Data .............................. 26
5.9 Password-Retry .................................. 27
5.10 Prompt .......................................... 28
5.11 Connect-Info .................................... 29
5.12 Configuration-Token ............................. 30
5.13 EAP-Message ..................................... 30
5.14 Signature ....................................... 32
5.15 ARAP-Challenge-Response ......................... 34
5.16 Acct-Interim-Interval ........................... 34
5.17 Table of Attributes ............................. 35
6. Security Considerations ............................... 36 5. Attributes ............................................ 20
6.1 Separation of EAP server and PPP authenticator .. 36 5.1 Acct-Input-Gigawords ............................ 22
6.2 Connection hijacking ............................ 37 5.2 Acct-Output-Gigawords ........................... 23
6.3 Man in the middle attacks ....................... 38 5.3 Event-Timestamp ................................. 24
6.4 Multiple databases .............................. 38 5.4 ARAP-Password ................................... 24
6.5 Negotiation attacks ............................. 38 5.5 ARAP-Features ................................... 25
5.6 ARAP-Zone-Access ................................ 27
5.7 ARAP-Security ................................... 28
5.8 ARAP-Security-Data .............................. 28
5.9 Password-Retry .................................. 29
5.10 Prompt .......................................... 30
5.11 Connect-Info .................................... 31
5.12 Configuration-Token ............................. 32
5.13 EAP-Message ..................................... 32
5.14 Signature ....................................... 34
5.15 ARAP-Challenge-Response ......................... 36
5.16 Acct-Interim-Interval ........................... 37
5.17 Table of Attributes ............................. 37
6. Security Considerations ............................... 38
6.1 Separation of EAP server and PPP authenticator
6.2 Connection hijacking ............................ 39
6.3 Man in the middle attacks ....................... 40
6.4 Multiple databases .............................. 40
6.5 Negotiation attacks ............................. 40
References ................................................... 40 7. References ............................................ 42
Acknowledgements ............................................. 41 8. Acknowledgements ...................................... 42
Chair's Address .............................................. 41 9. Chair's Address ....................................... 43
Author's Address ............................................. 41 10. Author's Address ...................................... 43
11. Full Copyright Statement .............................. 45
1. Introduction 1. Introduction
RFC 2138 [1] describes the RADIUS Protocol as it is implemented and RFC 2138 [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 2139 [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 Signature
attributes may be used for providing EAP support within RADIUS. attributes may be used for providing EAP support within RADIUS.
All attributes are comprised of variable length Type-Length-Value All attributes are comprised of variable length Type-Length-Value 3-
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
This specification uses the same words as [4] for defining the The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
significance of each particular requirement. These words are: "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [4].
MUST This word, or the adjectives "REQUIRED" or "SHALL", means
that the definition is an absolute requirement of the
specification.
MUST NOT This phrase, or the phrase "SHALL NOT", means that the
definition is an absolute prohibition of the specification.
SHOULD This word, or the adjective "RECOMMENDED", means that there
may exist valid reasons in particular circumstances to
ignore a particular item, but the full implications must be
understood and carefully weighed before choosing a
different course.
SHOULD NOT This phrase means that there may exist valid reasons in
particular circumstances when the particular behavior is
acceptable or even useful, but the full implications should
be understood and the case carefully weighed before
implementing any behavior described with this label.
MAY This word means that an item is truly optional. One vendor
may choose to include the item because a particular
marketplace requires it or because the vendor feels that it
enhances the product while another vendor may omit the same
item. An implementation which does not include a
particular option MUST be prepared to interoperate with
another implementation which does include the option,
though perhaps with reduced functionality. In the same vein
an implementation which does include a particular option
MUST be prepared to interoperate with another
implementation which does not include the option (except,
of course, for the feature the option provides).
An implementation is not compliant if it fails to satisfy one or more An implementation is not compliant if it fails to satisfy one or more
of the must or must not requirements for the protocols it implements. of the must or must not requirements for the protocols it implements.
An implementation that satisfies all the must, must not, should and An implementation that satisfies all the must, must not, should and
should not requirements for its protocols is said to be should not requirements for its protocols is said to be
"unconditionally compliant"; one that satisfies all the must and must "unconditionally compliant"; one that satisfies all the must and must
not requirements but not all the should or should not requirements not requirements but not all the should or should not requirements
for its protocols is said to be "conditionally compliant." for its protocols is said to be "conditionally compliant."
A NAS that does not implement a given service MUST NOT implement the A NAS that does not implement a given service MUST NOT implement the
skipping to change at page 21, line 42 skipping to change at page 24, line 18
Value Value
The Value field is four octets. The Value field is four octets.
5.3. Event-Timestamp 5.3. Event-Timestamp
Description Description
This attribute is included in an Accounting-Request packet to This attribute is included in an Accounting-Request packet to
record the time on the clock of the NAS that this event occured. record the time that this event occured on the NAS, in seconds
since January 1, 1970 00:00 UTC.
A summary of the Event-Timestamp attribute format is shown below. A summary of the Event-Timestamp attribute format is shown below.
The fields are transmitted from left to right. The fields are transmitted from left to right.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value | Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) | Value (cont) |
skipping to change at page 22, line 24 skipping to change at page 24, line 43
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 GMT. the number of seconds since January 1, 1970 00:00 UTC.
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.
A summary of the ARAP-Password attribute format is shown below. The A summary of the ARAP-Password attribute format is shown below. The
fields are transmitted from left to right. fields are transmitted from left to right.
0 1 2 3 0 1 2 3
skipping to change at page 29, line 35 skipping to change at page 31, line 38
Type Type
77 for Connect-Info. 77 for Connect-Info.
Length Length
>= 3 >= 3
String String
The String field is encoded as ASCII characters. The connection The String field is encoded as UTF-8 [6] characters. The
speed SHOULD be included at the beginning of the first Connect- connection speed SHOULD be included at the beginning of the first
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 receive speed first (the speed the NAS modem attribute with the transmit speed first (the speed the NAS modem
receives at), a slash (/), the transmit speed, then optionally transmits at), a slash (/), the receive speed, then optionally
other information. other information.
For example, "28800 V42BIS/LAPM" or "52000/33600 V90" For example, "28800 V42BIS/LAPM" or "52000/31200 V90"
More than one Connect-Info attribute may be present in an More than one Connect-Info attribute may be present in an
Accounting-Request packet to accommodate expected efforts by ITU Accounting-Request packet to accommodate expected efforts by ITU
to have modems report more connection information in a standard to have modems report more connection information in a standard
format that might exceed 252 octets. format that might exceed 252 octets.
5.12. Configuration-Token 5.12. Configuration-Token
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 22 skipping to change at page 35, line 26
80 for Signature. 80 for Signature.
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, Signature is an HMAC-MD5
[6] checksum of the entire Access-Request packet, including Type, [7] checksum of the entire Access-Request packet, including Type,
ID, Length and authenticator, using the shared secret as the key, ID, Length and authenticator, using the shared secret as the key,
as follows. as follows.
Signature = HMAC-MD5 (Type, Identifier, Length, Request Signature = HMAC-MD5 (Type, Identifier, Length, Request
Authenticator, Attributes) 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,
skipping to change at page 36, line 35 skipping to change at page 38, line 40
1 Exactly one instance of this attribute MUST be present. 1 Exactly one instance of this attribute MUST be present.
6. Security Considerations 6. Security Considerations
Security issues are the primary topic of this document. Security issues are the primary topic of this document.
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 the 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
6.1. Separation of the EAP server and PPP authenticator 6.1. Separation of EAP server and PPP authenticator
As described in [7] and [8], it is possible for the EAP endpoints to It is possible for the EAP endpoints to mutually authenticate,
mutually authenticate, negotiate a ciphersuite, and derive a session negotiate a ciphersuite, and derive a session key for subsequent use
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.
The situation may be more complex when EAP/RADIUS is used, since the The situation may be more complex when EAP/RADIUS is used, since the
PPP authenticator will typically not reside on the same machine as PPP authenticator will typically not reside on the same machine as
the EAP server. For example, the EAP server may be a backend security the EAP server. For example, the EAP server may be a backend security
server, or a module residing on the RADIUS server. server, or a module residing on the RADIUS server.
skipping to change at page 37, line 29 skipping to change at page 39, line 34
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 Signature attribute is required in EAP/RADIUS Access-
Requests sent from the NAS or tunnel server to the RADIUS server. Requests sent from the NAS or tunnel server to the RADIUS server.
Since the Signature attribute involves a HMAC-MD5 hash, it is Since the Signature attribute involves a HMAC-MD5 hash, it is
possible for the RADIUS server to verify the integrity of the possible for the RADIUS server to verify the integrity of the
Access-Request as well as the NAS or tunnel server's identity. Access-Request as well as the NAS or tunnel server's identity.
Similarly, Access-Challenge packets sent from the RADIUS server to Similarly, Access-Challenge packets sent from the RADIUS server to
the NAS are also authenticated and integrity protected using an the NAS are also authenticated and integrity protected using an
HMAC-MD5 hash, enabling the NAS or tunnel server to determine the HMAC-MD5 hash, enabling the NAS or tunnel server to determine the
integrity of the packet and verify the identity of the RADIUS server. integrity of the packet and verify the identity of the RADIUS server.
Morever, EAP packets sent via the methods described in [7] and [8] Morever, EAP packets sent via methods that contain their own
contain their own integrity protection, so that they cannot be integrity protection cannot be successfully modified by a rogue NAS
successfully modified by a rogue NAS or tunnel server. 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.
skipping to change at page 39, line 5 skipping to change at page 41, line 10
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 [9]. described in [8].
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 40, line 13 skipping to change at page 42, line 19
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.
References 7. 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 2138, April
1997. 1997.
[2] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997. [2] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
[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." 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] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
for Message Authentication", RFC 2104, February 1997. 2279, January 1998.
[7] Aboba, B., and Simon, D., "PPP EAP TLS Authentication
Protocol." Work in progress, draft-ietf-pppext-eaptls-03.txt,
Microsoft, April 1998.
[8] Carter, G., "PPP EAP ISAKMP Authentication Protocol." Work in [7] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
progress, draft-ietf-pppext-eapisakmp-00.txt, Entrust, November for Message Authentication", RFC 2104, February 1997.
1997.
[9] Slatalla, M., and Quittner, J., "Masters of Deception." [8] Slatalla, M., and Quittner, J., "Masters of Deception."
HarperCollins, New York, 1995. HarperCollins, New York, 1995.
Acknowledgments 8. Acknowledgements
RADIUS and RADIUS Accounting were originally developed by Livingston RADIUS and RADIUS Accounting were originally developed by Livingston
Enterprises (now Lucent Remote Access Business Unit) for their Enterprises (now Lucent Remote Access Business Unit) for their
PortMaster series of Network Access Servers. PortMaster 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.
Chair's Address 9. 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
Author's Address 10. 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
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:
skipping to change at page 42, line 16 skipping to change at page 44, line 10
Ward Willats Ward Willats
Cyno Technologies Cyno Technologies
1082 Glen Echo Ave 1082 Glen Echo Ave
San Jose, CA 95125 San Jose, CA 95125
Phone: +1 408 297 7766 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
Technology Development Network and Security Research Center
Sun Microsystems, Inc. Sun Microsystems, Inc.
15 Network Circle 15 Network Circle
Menlo Park, CA 94025 Menlo Park, CA 94025
Phone: +1 847 548 0926 Phone: +1 650 786 7733
E-Mail: pcalhoun@toast.net E-Mail: pcalhoun@eng.sun.com
Allan C. Rubens Allan C. Rubens
Merit Network, Inc. Merit Network, Inc.
4251 Plymouth Rd. 4251 Plymouth Rd.
Ann Arbor, MI 48105-2785 Ann Arbor, MI 48105-2785
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
11. Full Copyright Statement
Copyright (C) The Internet Society (1997). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Table of Contents
1. Introduction .......................................... 4
1.1 Specification of Requirements ................... 4
1.2 Terminology ..................................... 4
2. Operation ............................................. 5
2.1 RADIUS support for Interim Accounting Updates
2.2 RADIUS support for Apple Remote Access
Protocol .......................................................... 6
2.3 RADIUS Support for Extensible Authentication
Protocol (EAP) .................................................... 12
2.3.1 Protocol Overview ............................... 12
2.3.2 Retransmission .................................. 14
2.3.3 Fragmentation ................................... 15
2.3.4 Examples ........................................ 15
2.3.5 Alternative uses ................................ 20
3. Packet Format ......................................... 20
4. Packet Types .......................................... 20
5. Attributes ............................................ 20
5.1 Acct-Input-Gigawords ............................ 22
5.2 Acct-Output-Gigawords ........................... 23
5.3 Event-Timestamp ................................. 24
5.4 ARAP-Password ................................... 24
5.5 ARAP-Features ................................... 25
5.6 ARAP-Zone-Access ................................ 27
5.7 ARAP-Security ................................... 28
5.8 ARAP-Security-Data .............................. 28
5.9 Password-Retry .................................. 29
5.10 Prompt .......................................... 30
5.11 Connect-Info .................................... 31
5.12 Configuration-Token ............................. 32
5.13 EAP-Message ..................................... 32
5.14 Signature ....................................... 34
5.15 ARAP-Challenge-Response ......................... 36
5.16 Acct-Interim-Interval ........................... 37
5.17 Table of Attributes ............................. 37
6. Security Considerations ............................... 38
6.1 Separation of EAP server and PPP authenticator
6.2 Connection hijacking ............................ 39
6.3 Man in the middle attacks ....................... 40
6.4 Multiple databases .............................. 40
6.5 Negotiation attacks ............................. 40
7. References ............................................ 42
8. Acknowledgements ...................................... 42
9. Chair's Address ....................................... 43
10. Author's Address ...................................... 43
11. Full Copyright Statement .............................. 45
 End of changes. 38 change blocks. 
129 lines changed or deleted 103 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/