response, and can be found in Access-Challenge and Access-Request
packets.
A summary of the ARAP-Security-Data attribute format is shown below.
The fields are transmitted from left to right.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
74 for ARAP-Security-Data.
Length
>=3
String
The String field contains the security module challenge or
response associated with the ARAP Security Module specified in
ARAP-Security.
5.9. Password-Retry
Description
This attribute MAY be included in an Access-Reject to indicate how
many authentication attempts a user may be allowed to attempt
before being disconnected.
It is primarily intended for use with ARAP authentication.
A summary of the Password-Retry attribute format is shown below. The
fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
75 for Password-Retry.
Length
6
Value
The Value field is four octets, containing an integer specifying
the number of password retry attempts to permit the user.
5.10. Prompt
Description
This attribute is used only in Access-Challenge packets, and
indicates to the NAS whether it should echo the user's response as
it is entered, or not echo it.
A summary of the Prompt attribute format is shown below. The fields
are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
76 for Prompt.
Length
6
Value
The Value field is four octets.
0 No Echo
1 Echo
5.11. Connect-Info
Description
This attribute is sent from the NAS to indicate the nature of the
user's connection.
The NAS MAY send this attribute in an Access-Request or
Accounting-Request to indicate the nature of the user's
connection.
A summary of the Connect-Info attribute format is shown below. The
fields are transmitted from left to right.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Text...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
77 for Connect-Info.
Length
>= 3
Text
The Text field consists of UTF-8 encoded 10646 [8] characters.
The connection speed SHOULD be included at the beginning of the
first Connect-Info attribute in the packet. If the transmit and
receive connection speeds differ, they may both be included in the
first attribute with the transmit speed first (the speed the NAS
modem transmits at), a slash (/), the receive speed, then
optionally other information.
For example, "28800 V42BIS/LAPM" or "52000/31200 V90"
More than one Connect-Info attribute may be present in an
Accounting-Request packet to accommodate expected efforts by ITU
to have modems report more connection information in a standard
format that might exceed 252 octets.
5.12. Configuration-Token
Description
This attribute is for use in large distributed authentication
networks based on proxy. It is sent from a RADIUS Proxy Server to
a RADIUS Proxy Client in an Access-Accept to indicate a type of
user profile to be used. It should not be sent to a NAS.
A summary of the Configuration-Token attribute format is shown below.
The fields are transmitted from left to right.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
78 for Configuration-Token.
Length
>= 3
String
The String field is one or more octets. The actual format of the
information is site or application specific, and a robust
implementation SHOULD support the field as undistinguished octets.
The codification of the range of allowed usage of this field is
outside the scope of this specification.
5.13. EAP-Message
Description
This attribute encapsulates Extended Access Protocol [3] packets
so as to allow the NAS to authenticate dial-in users via EAP
without having to understand the EAP protocol.
The NAS places any EAP messages received from the user into one or
more EAP attributes and forwards them to the RADIUS Server as part
of the Access-Request, which can return EAP messages in Access-
Challenge, Access-Accept and Access-Reject packets.
A RADIUS Server receiving EAP messages that it does not understand
SHOULD return an Access-Reject.
The NAS places EAP messages received from the authenticating peer
into one or more EAP-Message attributes and forwards them to the
RADIUS Server within an Access-Request message. If multiple EAP-
Messages are contained within an Access-Request or Access-
Challenge packet, they MUST be in order and they MUST be
consecutive attributes in the Access-Request or Access-Challenge
packet. Access-Accept and Access-Reject packets SHOULD only have
ONE EAP-Message attribute in them, containing EAP-Success or EAP-
Failure.
It is expected that EAP will be used to implement a variety of
authentication methods, including methods involving strong
cryptography. In order to prevent attackers from subverting EAP by
attacking RADIUS/EAP, (for example, by modifying the EAP-Success
or EAP-Failure packets) it is necessary that RADIUS/EAP provide
integrity protection at least as strong as those used in the EAP
methods themselves.
Therefore the Message-Authenticator attribute MUST be used to
protect all Access-Request, Access-Challenge, Access-Accept, and
Access-Reject packets containing an EAP-Message attribute.
Access-Request packets including an EAP-Message attribute without
a Message-Authenticator attribute SHOULD be silently discarded by
the RADIUS server. A RADIUS Server supporting EAP-Message MUST
calculate the correct value of the Message-Authenticator and
silently discard the packet if it does not match the value sent.
A RADIUS Server not supporting EAP-Message MUST return an Access-
Reject if it receives an Access-Request containing an EAP-Message
attribute. A RADIUS Server receiving an EAP-Message attribute that
it does not understand MUST return an Access-Reject.
Access-Challenge, Access-Accept, or Access-Reject packets
including an EAP-Message attribute without a Message-Authenticator
attribute SHOULD be silently discarded by the NAS. A NAS
supporting EAP-Message MUST calculate the correct value of the
Message-Authenticator and silently discard the packet if it does
not match the value sent.
A summary of the EAP-Message attribute format is shown below. The
fields are transmitted from left to right.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
79 for EAP-Message.
Length
>= 3
String
The String field contains EAP packets, as defined in [3]. If
multiple EAP-Message attributes are present in a packet their
values should be concatenated; this allows EAP packets longer than
253 octets to be passed by RADIUS.
5.14. Message-Authenticator
Description
This attribute MAY be used to sign Access-Requests to prevent
spoofing Access-Requests using CHAP, ARAP or EAP authentication
methods. It MAY be used in any Access-Request. It MUST be used
in any Access-Request, Access-Accept, Access-Reject or Access-
Challenge that includes an EAP-Message attribute.
A RADIUS Server receiving an Access-Request with a Message-
Authenticator Attribute present MUST calculate the correct value
of the Message-Authenticator and silently discard the packet if it
does not match the value sent.
A RADIUS Client receiving an Access-Accept, Access-Reject or
Access-Challenge with a Message-Authenticator Attribute present
MUST calculate the correct value of the Message-Authenticator and
silently discard the packet 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 Message-Authenticator attribute format is shown
below. The fields are transmitted from left to right.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
80 for Message-Authenticator
Length
18
String
When present in an Access-Request packet, Message-Authenticator is
an HMAC-MD5 [9] checksum of the entire Access-Request packet,
including Type, ID, Length and authenticator, using the shared
secret as the key, as follows.
Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
Request Authenticator, Attributes)
When the checksum is calculated the signature string should be
considered to be sixteen octets of zero.
For Access-Challenge, Access-Accept, and Access-Reject packets,
the Message-Authenticator is calculated as follows, using the
Request-Authenticator from the Access-Request this packet is in
reply to:
Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
Request Authenticator, Attributes)
When the checksum is calculated the signature string should be
considered to be sixteen octets of zero. The shared secret is
used as the key for the HMAC-MD5 hash. The is calculated and
inserted in the packet before the Response Authenticator is
calculated.
This attribute is not needed if the User-Password attribute is
present, but is useful for preventing attacks on other types of
authentication. This attribute is intended to thwart attempts by
an attacker to setup a "rogue" NAS, and perform online dictionary
attacks against the RADIUS server. It does not afford protection
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
should be considered an interim measure.
5.15. ARAP-Challenge-Response
Description
This attribute is sent in an Access-Accept packet with Framed-
Protocol of ARAP, and contains the response to the dial-in
client's challenge.
A summary of the ARAP-Challenge-Response attribute format is shown
below. The fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
84 for ARAP-Challenge-Response.
Length
10
Value
The Value field contains an 8 octet response to the dial-in
client's challenge. The RADIUS server calculates this value by
taking the dial-in client's challenge from the high order 8 octets
of the ARAP-Password attribute and performing DES encryption on
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
is padded at the end with NULL octets to a length of 8 before
using it as a key.
5.16. Acct-Interim-Interval
Description
This attribute indicates the number of seconds between each
interim update in seconds for this specific session. This value
can only appear in the Access-Accept message.
A summary of the Acct-Interim-Interval attribute format is shown
below. The fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
85 for Acct-Interim-Interval.
Length
6
Value
The Value field contains the number of seconds between each
interim update to be sent from the NAS for this session. The value
MUST NOT be smaller than 60. The value SHOULD NOT be smaller than
600, and careful consideration should be given to its impact on
network traffic.
5.17. NAS-Port-Id
Description
This Attribute contains a text string which identifies the port of
the NAS which is authenticating the user. It is only used in
Access-Request and Accounting-Request packets. Note that this is
using "port" in its sense of a physical connection on the NAS, not
in the sense of a TCP or UDP port number.
Either NAS-Port or NAS-Port-Id SHOULD be present in an Access-
Request packet, if the NAS differentiates among its ports. NAS-
Port-Id is intended for use by NASes which cannot conveniently
number their ports.
A summary of the NAS-Port-Id Attribute format is shown below. The
fields are transmitted from left to right.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Text...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
87 for NAS-Port-Id.
Length
>= 3
Text
The Text field contains the name of the port using UTF-8 encoded
10646 [8] characters.
5.18. Framed-Pool
Description
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
not support multiple address pools, the NAS should ignore this
Attribute. Address pools are usually used for IP addresses, but
can be used for other protocols if the NAS supports pools for
those protocols.
A summary of the Framed-Pool Attribute format is shown below. The
fields are transmitted from left to right.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
88 for Framed-Pool
Length
>= 3
String
The string field contains the name of an assigned address pool
configured on the NAS.
5.19. Table of Attributes
The following table provides a guide to which attributes may be found
in which kind of packets. Acct-Input-Gigawords, Acct-Output-
Gigawords, Event-Timestamp, and NAS-Port-Id may have 0-1 instances in
an Accounting-Request packet. Connect-Info may have 0+ instances in
an Accounting-Request packet. The other attributes added in this
document must not be present in an Accounting-Request.
Request Accept Reject Challenge # Attribute
0-1 0 0 0 70 ARAP-Password [Note 1]
0 0-1 0 0-1 71 ARAP-Features
0 0-1 0 0 72 ARAP-Zone-Access
0-1 0 0 0-1 73 ARAP-Security
0+ 0 0 0+ 74 ARAP-Security-Data
0 0 0-1 0 75 Password-Retry
0 0 0 0-1 76 Prompt
0-1 0 0 0 77 Connect-Info
0 0+ 0 0 78 Configuration-Token
0+ 0+ 0+ 0+ 79 EAP-Message [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 85 Acct-Interim-Interval
0-1 0 0 0 87 NAS-Port-Id
0 0-1 0 0 88 Framed-Pool
Request Accept Reject Challenge # Attribute
[Note 1] An Access-Request that contains either a User-Password or
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
does not contain any of those four attributes, it SHOULD contain a
Message-Authenticator. If any packet type contains an EAP-Message
attribute it MUST also contain a Message-Authenticator.
The following table defines the above table entries.
0 This attribute MUST NOT be present
0+ Zero or more instances of this attribute MAY be present.
0-1 Zero or one instance of this attribute MAY be present.
1 Exactly one instance of this attribute MUST be present.
6. IANA Considerations
The Packet Type Codes, Attribute Types, and Attribute Values defined
in this document are registered by the Internet Assigned Numbers
Authority (IANA) from the RADIUS name spaces as described in the
"IANA Considerations" section of [1], in accordance with BCP 26 [10].
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
both the user and the NAS sending the Access-Request, because of the
way the shared secret between NAS and RADIUS server is used.
Access-Request packets with CHAP-Password or EAP-Message do not have
a User-Password attribute, so the Message-Authenticator attribute
should be used in access-request packets that do not have a User-
Password, in order to establish the identity of the NAS sending the
request.
7.2. EAP Security
Since the purpose of EAP is to provide enhanced security for PPP
authentication, it is critical that RADIUS support for EAP be secure.
In particular, the following issues must be addressed:
Separation of EAP server and PPP authenticator
Connection hijacking
Man in the middle attacks
Multiple databases
Negotiation attacks
7.2.1. Separation of EAP server and PPP authenticator
It is possible for the EAP endpoints to mutually authenticate,
negotiate a ciphersuite, and derive a session key for subsequent use
in PPP encryption.
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
EAP client module to pass the session key to the PPP encryption
module.
The situation is more complex when EAP is used with RADIUS, since the
PPP authenticator will typically not reside on the same machine as
the EAP server. For example, the EAP server may be a backend security
server, or a module residing on the RADIUS server.
In the case where the EAP server and PPP authenticator reside on
different machines, there are several implications for security.
Firstly, mutual authentication will occur between the peer and the
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
NAS or tunnel server that it is speaking to.
As described earlier, when EAP/RADIUS is used to encapsulate EAP
packets, the Message-Authenticator attribute is required in
EAP/RADIUS Access-Requests sent from the NAS or tunnel server to the
RADIUS server. Since the Message-Authenticator attribute involves a
HMAC-MD5 hash, it is possible for the RADIUS server to verify the
integrity of the Access-Request as well as the NAS or tunnel server's
identity. Similarly, Access-Challenge packets sent from the RADIUS
server to the NAS are also authenticated and integrity protected
using an HMAC-MD5 hash, enabling the NAS or tunnel server to
determine the integrity of the packet and verify the identity of the
RADIUS server. Moreover, EAP packets sent via methods that contain
their own integrity protection cannot be successfully modified by a
rogue NAS or tunnel server.
The second issue that arises in the case of an EAP server and PPP
authenticator residing on different machines is that the session key
negotiated between the peer and EAP server will need to be
transmitted to the authenticator. Therefore a mechanism needs to be
provided to transmit the session key from the EAP server to the
authenticator or tunnel server that needs to use the key. The
specification of this transit mechanism is outside the scope of this
document.
7.2.2. Connection hijacking
In this form of attack, the attacker attempts to inject packets into
the conversation between the NAS and the RADIUS server, or between
the RADIUS server and the backend security server. RADIUS does not
support encryption, and as described in [1], only Access-Reply and
Access-Challenge packets are integrity protected. Moreover, the
integrity protection mechanism described in [1] is weaker than that
likely to be used by some EAP methods, making it possible to subvert
those methods by attacking EAP/RADIUS.
In order to provide for authentication of all packets in the EAP
exchange, all EAP/RADIUS packets MUST be authenticated using the
Message-Authenticator attribute, as described previously.
7.2.3. Man in the middle attacks
Since RADIUS security is based on shared secrets, end-to-end security
is not provided in the case where authentication or accounting
packets are forwarded along a proxy chain. As a result, attackers
gaining control of a RADIUS proxy will be able to modify EAP packets
in transit.
7.2.4. Multiple databases
In many cases a backend security server will be deployed along with a
RADIUS server in order to provide EAP services. Unless the backend
security server also functions as a RADIUS server, two separate user
databases will exist, each containing information about the security
requirements for the user. This represents a weakness, since security
may be compromised by a successful attack on either of the servers,
or their backend databases. With multiple user databases, adding a
new user may require multiple operations, increasing the chances for
error. The problems are further magnified in the case where user
information is also being kept in an LDAP server. In this case, three
stores of user information may exist.
In order to address these threats, consolidation of databases is
recommended. This can be achieved by having both the RADIUS server
and backend security server store information in the same backend
database; by having the backend security server provide a full RADIUS
implementation; or by consolidating both the backend security server
and the RADIUS server onto the same machine.
7.2.5. Negotiation attacks
In a negotiation attack, a rogue NAS, tunnel server, RADIUS proxy or
RADIUS server causes the authenticating peer to choose a less secure
authentication method so as to make it easier to obtain the user's
password. For example, a session that would normally be authenticated
with EAP would instead authenticated via CHAP or PAP; alternatively,
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
rogue devices, once thought to be remote, has gained currency given
compromises of telephone company switching systems, such as those
described in [11].
Protection against negotiation attacks requires the elimination of
downward negotiations. This can be achieved via implementation of
per-connection policy on the part of the authenticating peer, and
per-user policy on the part of the RADIUS server.
For the authenticating peer, authentication policy should be set on a
per-connection basis. Per-connection policy allows an authenticating
peer to negotiate EAP when calling one service, while negotiating
CHAP for another service, even if both services are accessible via
the same phone number.
With per-connection policy, an authenticating peer will only attempt
to negotiate EAP for a session in which EAP support is expected. As a
result, there is a presumption that an authenticating peer selecting
EAP requires that level of security. If it cannot be provided, it is
likely that there is some kind of misconfiguration, or even that the
authenticating peer is contacting the wrong server. Should the NAS
not be able to negotiate EAP, or should the EAP-Request sent by the
NAS be of a different EAP type than what is expected, the
authenticating peer MUST disconnect. An authenticating peer expecting
EAP to be negotiated for a session MUST NOT negotiate CHAP or PAP.
For a NAS, it may not be possible to determine whether a user is
required to authenticate with EAP until the user's identity is known.
For example, for shared-uses NASes it is possible for one reseller to
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
every call. This avoids forcing an EAP-capable client to do more than
one authentication, which weakens security.
If CHAP is negotiated, the NAS will pass the User-Name and CHAP-
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
respond with an Access-Accept or Access-Reject packet as appropriate.
However, if CHAP has been negotiated but EAP is required, the RADIUS
server MUST respond with an Access-Reject, rather than an Access-
Challenge/EAP-Message/EAP-Request packet. The authenticating peer
MUST refuse to renegotiate authentication, even if the renegotiation
is from CHAP to EAP.
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.
In these cases, the NAS MUST send an LCP-Terminate and disconnect the
user. This is the correct behavior since the authenticating peer is
expecting EAP to be negotiated, and that expectation cannot be
fulfilled. An EAP-capable authenticating peer MUST refuse to
renegotiate the authentication protocol if EAP had initially been
negotiated. Note that problems with a non-EAP capable RADIUS proxy
could prove difficult to diagnose, since a user dialing in from one
location (with an EAP-capable proxy) might be able to successfully
authenticate via EAP, while the same user dialing into another
location (and encountering an EAP-incapable proxy) might be
consistently disconnected.
8. References
[1] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC2865, June
2000.
[2] Rigney, C., "RADIUS Accounting", RFC2866, June 2000.
[3] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
Protocol (EAP)", RFC2284, March 1998.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March, 1997.
[5] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC1700,
October 1994.
[6] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and
I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC
2868, June 2000.
[7] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting
Modifications for Tunnel Protocol Support", RFC2867, June 2000.
[8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.
[9] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC2104, February 1997.
[10] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC2434, October 1998.
[11] Slatalla, M., and Quittner, J., "Masters of Deception."
HarperCollins, New York, 1995.
9. Acknowledgements
RADIUS and RADIUS Accounting were originally developed by Livingston
Enterprises (now part of Lucent Technologies) for their PortMaster
series of Network Access Servers.
The section on ARAP is adopted with permission from "Using RADIUS to
Authenticate Apple Remote Access Connections" by Ward Willats of Cyno
Technologies (ward@cyno.com).
The section on Acct-Interim-Interval is adopted with permission from
an earlier work in progress by Pat Calhoun of Sun Microsystems, Mark
Beadles of Compuserve, and Alex Ratcliffe of UUNET Technologies.
The section on EAP is adopted with permission from an earlier work in
progress by Pat Calhoun of Sun Microsystems, Allan Rubens of Merit
Network, and Bernard Aboba of Microsoft. Thanks also to Dave Dawson
and Karl Fox of Ascend, and Glen Zorn and Narendra Gidwani of
Microsoft for useful discussions of this problem space.
10. Chair's Address
The RADIUS working group can be contacted via the current chair:
Carl Rigney
Livingston Enterprises
4464 Willow Road
Pleasanton, California 94588
Phone: +1 925 737 2100
EMail: cdr@telemancy.com
11. Authors' Addresses
Questions about this memo can also be directed to:
Carl Rigney
Livingston Enterprises
4464 Willow Road
Pleasanton, California 94588
EMail: cdr@telemancy.com
Questions on ARAP and RADIUS may be directed to:
Ward Willats
Cyno Technologies
1082 Glen Echo Ave
San Jose, CA 95125
Phone: +1 408 297 7766
EMail: ward@cyno.com
Questions on EAP and RADIUS may be directed to any of the following:
Pat R. Calhoun
Network and Security Research Center
Sun Microsystems, Inc.
15 Network Circle
Menlo Park, CA 94025
Phone: +1 650 786 7733
EMail: pcalhoun@eng.sun.com
Allan C. Rubens
Tut Systems, Inc.
220 E. Huron, Suite 260
Ann Arbor, MI 48104
Phone: +1 734 995 1697
EMail: arubens@tutsys.com
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: +1 425 936 6605
EMail: bernarda@microsoft.com
12. Full Copyright Statement
Copyright (C) The Internet Society (2000). 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 implementation 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.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.