[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: (RFC 2869) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 RFC 3579

Network Working Group                                           B. Aboba
INTERNET-DRAFT                                                 Microsoft
Category: Informational                                       P. Calhoun
<draft-aboba-radius-rfc2869bis-10.txt>                         Airespace
21 March 2003
Updates: RFC 2869


      RADIUS Support For Extensible Authentication Protocol (EAP)

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other groups
may also distribute working documents as Internet- Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet Drafts as reference material
or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Copyright Notice

Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

This document defines RADIUS support for the Extensible Authentication
Protocol (EAP), an authentication framework which supports multiple
authentication mechanisms. While EAP was originally developed for use
with PPP, it is also now in use with IEEE 802.

This document updates RFC 2869.











Aboba & Calhoun               Informational                     [Page 1]


INTERNET-DRAFT                RADIUS & EAP                 21 March 2003


Table of Contents

1.     Introduction ..........................................    3
   1.1       Specification of Requirements ...................    3
   1.2       Terminology .....................................    4
2.     RADIUS support for EAP ................................    5
   2.1       Protocol overview ...............................    5
   2.2       Invalid packets .................................    9
   2.3       Retransmission ..................................   10
   2.4       Fragmentation ...................................   10
   2.5       Alternative uses ................................   10
   2.6       Usage guidelines ................................   11
3.     Attributes ............................................   14
   3.1       EAP-Message .....................................   14
   3.2       Message-Authenticator ...........................   15
   3.3       Table of attributes .............................   17
4.     Security considerations ...............................   18
   4.1       Security requirements ...........................   18
   4.2       Security protocol ...............................   19
   4.3       Security issues ................................    21
5.     IANA considerations ..................................    28
6.     Normative references ..................................   28
7.     Informative references ................................   29
Appendix A - Examples ........................................   31
Appendix B - Change log ......................................   39
ACKNOWLEDGMENTS ..............................................   40
AUTHORS' ADDRESSES ...........................................   40
Intellectual property statement ..............................   40
Full Copyright Statement .....................................   41






















Aboba & Calhoun               Informational                     [Page 2]


INTERNET-DRAFT                RADIUS & EAP                 21 March 2003


1.  Introduction

The Remote Authentication Dial In User Service (RADIUS) is an
authentication, authorization and accounting protocol used to control
network access.  RADIUS authentication and authorization is specified in
[RFC2865],  and RADIUS accounting is specified in [RFC2866].

The Extensible Authentication Protocol (EAP), defined in [RFC2284], is
an authentication framework which supports multiple authentication
mechanisms.  EAP may be used on dedicated links as well as switched
circuits, and wired as well as wireless links.

To date, EAP has been implemented with hosts and routers that connect
via switched circuits or dial-up lines using PPP [RFC1661]. It has also
been implemented with switches supporting [IEEE802].  EAP encapsulation
on IEEE 802 wired media is described in [IEEE8021X].

This specification describes RADIUS attributes supporting the Extensible
Authentication Protocol (EAP): EAP-Message and Message-Authenticator.
These attributes now have extensive field experience, and so the purpose
of this document is to provide clarification and resolve
interoperability issues.

As noted in [RFC2865], a Network Access Server (NAS) that does not
implement a given service MUST NOT implement the RADIUS attributes for
that service.  This implies that a NAS that is unable to offer EAP
service MUST NOT implement the RADIUS attributes for EAP.  A NAS MUST
treat a RADIUS Access-Accept requesting an unavailable service as an
Access-Reject instead.

All attributes are comprised of variable length Type-Length-Value
3-tuples.  New attribute values can be added without disturbing existing
implementations of the protocol.

1.1.  Specification of Requirements

In this document, several words are used to signify the requirements of
the specification.  These words are often capitalized.  The key words
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this document are to be
interpreted as described in [RFC2119].










Aboba & Calhoun               Informational                     [Page 3]


INTERNET-DRAFT                RADIUS & EAP                 21 March 2003


1.2.  Terminology

This document frequently uses the following terms:

authenticator
          The end of the link requiring the authentication.

peer      The other end of the point-to-point link (PPP), point-to-point
          LAN segment (IEEE 802.1X) or wireless link, which is being
          authenticated by the authenticator. In IEEE 802.1X, this end
          is known as the Supplicant. Throughout this specification, the
          term "user" is used synonymously with peer.

authentication server
          An authentication server is an entity that provides an
          authentication service to an authenticator. This service
          verifies from the credentials provided by the peer, the claim
          of identity made by the peer.

Port Access Entity (PAE)
          The protocol entity associated with a physical or virtual
          Port.  A given PAE may support the protocol functionality
          associated with the authenticator, peer or both.

silently discard
          This means the implementation discards the packet without
          further processing.  The implementation SHOULD provide the
          capability of logging the error, including the contents of the
          silently discarded packet, and SHOULD record the event in a
          statistics counter.

displayable message
          This is interpreted to be a human readable string of
          characters, and MUST NOT affect operation of the protocol.
          The message encoding MUST follow the UTF-8 transformation
          format [RFC2279].

Network Access Server (NAS)
          The device providing access to the network.

service   The NAS provides a service to the user, such as IEEE 802 or
          PPP.

session   Each service provided by the NAS to a peer constitutes a
          session, with the beginning of the session defined as the
          point where service is first provided and the end of the
          session defined as the point where service is ended.  A peer
          may have multiple sessions in parallel or series if the NAS



Aboba & Calhoun               Informational                     [Page 4]


INTERNET-DRAFT                RADIUS & EAP                 21 March 2003


          supports that, with each session generating a separate start
          and stop accounting record.

2.  RADIUS Support for EAP

The Extensible Authentication Protocol (EAP), described in [RFC2284],
provides a standard mechanism for support of additional authentication
methods without requiring additional functionality on the NAS.  Through
the use of EAP, support for a number of authentication schemes may be
added, including smart cards, Kerberos [RFC1510], Public Key [RFC2716],
One Time Passwords [RFC2284], and others.

One of the advantages of the EAP architecture is its flexibility.  EAP
is used to select a specific authentication mechanism. Rather than
requiring the NAS to be updated to support each new authentication
method, EAP permits the use of an authentication server which may
implement some or all authentication methods, with the NAS acting as a
pass-through for some or all methods and peers.

A NAS MAY authenticate local users while at the same time acting as a
pass-through for non-local users and authentication methods it does not
implement locally. This means that a NAS implementing RADIUS/EAP is not
required to use RADIUS to authenticate every peer. However, once the NAS
begins acting as a pass-through for a particular session, it can no
longer perform local authentication for that session.

In order to support EAP within RADIUS, two new attributes, EAP-Message
and Message-Authenticator, are introduced in this document. This section
describes how these new attributes may be used for providing EAP support
within RADIUS.

2.1.  Protocol Overview

In RADIUS/EAP, RADIUS is used to shuttle RADIUS-encapsulated EAP Packets
between the NAS and an authentication server.

The authenticating peer and the NAS begin the EAP conversation by
negotiating use of EAP. Once EAP has been negotiated, the NAS SHOULD
send an initial EAP-Request message to the authenticating peer.  This
will typically be an EAP-Request/Identity, although an EAP-Request for
an authentication method (Types 4 and greater) is possible. For example,
a NAS might be configured to initiate with a default authentication
method. This could be useful in cases where the identity is determined
by another means (such as the Called-Station-Id or Calling-Station-Id),
a single authentication method is required (so that the identity is not
needed to determine the method), or where identity hiding is desired, so
that the identity is not requested until after a protected channel has
been set up.



Aboba & Calhoun               Informational                     [Page 5]


INTERNET-DRAFT                RADIUS & EAP                 21 March 2003


The peer replies with an EAP-Response.  EAP is a 'lock step' protocol,
so that other than the initial Request, a new Request cannot be sent
prior to receiving a valid Response. Success and Failure packets MUST
NOT be sent as the result of a timeout.  The NAS MAY determine from the
Response that it should proceed with local authentication.
Alternatively, it MAY act as a pass-through, encapsulating the EAP-
Response within EAP-Message attribute(s) within a RADIUS Access-Request
packet, sent to the RADIUS server.

For example, if an EAP-Request/Identity message is sent by the NAS as
the first packet, the peer responds with an EAP-Response/Identity. The
NAS may determine that the user is local and proceed with local
authentication. If no match is found against the list of local users,
the NAS encapsulates the EAP-Response/Identity message within EAP-
Message attribute(s), enclosed within an Access-Request sent to the
RADIUS server.

On receiving a valid Access-Request packet containing EAP-Message
attribute(s), a RADIUS server supporting and wishing to authenticate
with EAP MUST respond with an Access-Challenge packet containing EAP-
Message attribute(s). If the RADIUS server does not support EAP or does
not wish to authenticate with EAP, it MUST respond with an Access-
Reject.  The EAP-Message attribute(s) encapsulate a single EAP packet
which the NAS decapsulates and passes on to the authenticating peer.
The conversation continues until either a RADIUS Access-Reject or
Access-Accept packet is received from the RADIUS server.  Reception of a
RADIUS Access-Reject packet MUST result in the NAS denying access to the
authenticating peer.  A RADIUS Access-Accept packet successfully ends
the authentication phase.

Using RADIUS, the NAS can act as a pass-through for an EAP conversation
between the peer and  authentication server, without needing to
implement the EAP method used between them.  Where the NAS initiates the
conversation by sending an EAP-Request for an authentication method, it
may not be required that the NAS fully implement the EAP method sent in
the first packet. Depending on the initial method, it may be sufficient
for the NAS to be configured with the initial packet to be sent to the
peer, and for the NAS to act as a pass-through for subsequent messages.
However, this only works well for methods where the initial Request is
largely static; otherwise the NAS will need to fully implement the
method so as to be able to authenticate the user locally.

Where an initial EAP-Request for an authentication Type (4 or greater)
is sent by the NAS, the peer may respond with a Nak indicating that it
would prefer another authentication method that is not implemented
locally.  In this case, Access-Request sent by the NAS MAY include an
EAP-message attribute encapsulating the received EAP-Response/Nak. This
provides the RADIUS server with a hint about the authentication



Aboba & Calhoun               Informational                     [Page 6]


INTERNET-DRAFT                RADIUS & EAP                 21 March 2003


method(s) preferred by the peer, although it does not provide
information on the Type of the original Request. In order to evaluate
whether the alternatives preferred by the peer are allowed, the RADIUS
server will typically need to determine the peer identity, so as to be
able to retrieve the associated authentication policy.

In order to permit non-EAP aware RADIUS proxies to forward the Access-
Request packet, if the NAS initially sends an EAP-Request/Identity
message to the peer, the NAS MUST copy the contents of the Type-Data
field of the EAP-Response/Identity received from the peer into the User-
Name attribute and MUST include the Type-Data field of the EAP-
Response/Identity in the User-Name attribute in every subsequent Access-
Request. Since RADIUS proxies are assumed to act as a pass-through, they
cannot be expected to parse an EAP-Response/Identity encapsulated within
EAP-Message attribute(s).

The NAS-Port or NAS-Port-Id attributes SHOULD be included by the NAS in
the Access-Request packet, and either NAS-Identifier or NAS-IP-Address
attributes MUST be included.  In order to permit forwarding of the
Access-Reply by EAP-unaware proxies, if a User-Name attribute was
included in an Access-Request, the RADIUS server MUST include the User-
Name attribute in subsequent Access-Accept packets.  Without the User-
Name attribute, accounting and billing becomes difficult to manage.  If
the identity is determined by another means, such as the Calling-
Station-Id, the NAS MUST include these identifying attributes in every
Access-Request, and the RADIUS server MUST copy these identifying
attributes into subsequent Access-Challenge, Access-Accept or Access-
Reject packets.

Having the NAS send the initial EAP-Request packet has a number of
advantages:

[1]  It saves a round trip between the NAS and RADIUS server.

[2]  An Access-Request is only sent to the RADIUS server if the
     authenticating peer sends an EAP-Response, confirming that it
     supports EAP. In situations where peers may be EAP unaware (such as
     in the case of a switch implementing [IEEE8021X], where there are
     IEEE 802.1X-unaware hosts), initiating a RADIUS Access-Request on a
     "carrier sense" or "media up" indication may initiate many
     authentication exchanges that cannot complete successfully.

[3]  It allows some users to be authenticated locally.

Although having the NAS send the initial EAP-Request packet has
substantial advantages, this technique cannot be universally employed.
There are circumstances in which the user's identity is already known
(such as when authentication and accounting is handled based on Called-



Aboba & Calhoun               Informational                     [Page 7]


INTERNET-DRAFT                RADIUS & EAP                 21 March 2003


Station-Id or Calling-Station-Id), but where the appropriate EAP method
may vary based on that identity.

Rather than sending an initial EAP-Request packet to the authenticating
peer, on detecting the presence of the peer, the NAS MAY send an Access-
Request packet to the RADIUS server containing an EAP-Message attribute
signifying EAP-Start.  The NAS also MAY send an Access-Request packet
containing an EAP-Start if, after sending an initial Request for an
authentication Type, the peer responds with a Nak.  This allows the
RADIUS server to take over the task of negotiating a more suitable
method. Typically the RADIUS server will respond with an Access-
Challenge containing an EAP-Message attribute with an encapsulated EAP-
Request/Identity.  On receiving an Access-Request containing an
encapsulated EAP-Response/Identity, the RADIUS server can retrieve the
authentication policy for the peer, in order to choose a suitable
method. However, because the RADIUS server is not provided with the
contents of the EAP-Response/Nak, it is possible for the RADIUS server
to choose an unacceptable method, and for the peer to respond with
another Nak.

EAP-Start is indicated by sending an EAP-Message attribute with a length
of 2 (no data). The Calling-Station-Id SHOULD be included in the User-
Name attribute.  This results in a RADIUS Access-Request being sent by
the NAS to the RADIUS server without first confirming that the peer
supports EAP.  Since this technique can result in a large number of
uncompleted RADIUS conversations, in situations where EAP unaware peers
are common, it SHOULD NOT be employed by default.  EAP-Message
attributes containing EAP-Start and an EAP-Response/Nak packets MUST NOT
be sent together within the same Access-Request.

Where the NAS initiates the RADIUS exchange by sending an Access-Request
to the server containing an EAP-Start, the Access-Challenge sent by the
RADIUS server will typically contain EAP-Message attribute(s)
encapsulating an EAP-Request/Identity packet,  requesting the peer to
identify itself. However, an Access-Challenge containing an EAP-Message
attribute encapsulating an EAP-Request for an authentication method
(Type 4 or greater) MAY also be sent. The NAS will decapsulate the EAP
packet contained within the EAP-Message attribute, send it to the peer,
and receive an EAP-Response packet from the peer in return. The NAS will
then send a RADIUS Access-Request packet to the RADIUS server,
containing EAP-Message attribute(s) encapsulating the EAP-Response
packet.

For proxied RADIUS requests, there are two methods of processing.  If
the domain is determined based on the Calling-Station-Id and Called-
Station-Id, the RADIUS Server may proxy the initial RADIUS Access-
Request/EAP-Start. If the domain is determined based on the user's
identity, the local RADIUS Server MUST respond with a RADIUS Access-



Aboba & Calhoun               Informational                     [Page 8]


INTERNET-DRAFT                RADIUS & EAP                 21 March 2003


Challenge/EAP-Identity packet.  The response from the authenticating
peer MUST be proxied to the final  authentication server.

For proxied RADIUS requests, the NAS may receive an Access-Reject packet
in response to the initial Access-Request packet.  This would occur if
the message was proxied to a RADIUS server which does not support the
EAP-Message attribute. On receiving an Access-Reject, the NAS MUST deny
access to the authenticating peer.

2.2.  Invalid packets

While the NAS is expected to validate portions of the EAP header (Code,
Identifier, Length) prior to forwarding an EAP packet to the RADIUS
server, it is still possible for an invalid EAP packet to be received by
the RADIUS server.  A RADIUS server receiving EAP-Message attribute(s)
it does not understand MAY return an Access-Reject. In order for the
RADIUS server to communicate that an invalid EAP packet has been
received, but that the problem is non-fatal, an Access-Challenge
containing a Service-Type=Packet-Reject MAY be sent. In some cases, the
EAP method may make the determination of whether the error is fatal or
non-fatal.

A NAS compliant with this specification, on receiving an Access-
Challenge with a Service-Type=Packet-Reject, SHOULD discard the current
EAP packet, and check whether it has received additional EAP Response
packets with an Identifier matching that of the last Request. If so, a
new EAP Response packet, if available, MUST be sent to the RADIUS server
within an Access-Request packet. In order to provide protection against
Denial of Service (DoS) attacks, it is advisable for the authenticator
to allocate a finite Response buffer, and to discard packets according
to an appropriate policy once that buffer has been exceeded.

Once the RADIUS server responds with a packet containing a non-null EAP-
Message attribute, the NAS updates the Identifier value, and any pending
Responses that do not match this value can be discarded. If another EAP
Response packet is not available, then the retransmission timer is reset
and the NAS retransmits the outstanding Request to the peer.

A NAS that does not support inclusion of a Service-Type attribute within
an Access-Challenge, or that does not support a value of Packet-Reject
behaves as specified in [RFC2865], Section 5.6:

   A NAS is not required to implement all of these service types, and
   MUST treat unknown or unsupported Service-Types as though an Access-
   Reject had been received instead.






Aboba & Calhoun               Informational                     [Page 9]


INTERNET-DRAFT                RADIUS & EAP                 21 March 2003


2.3.  Retransmission

As noted in [RFC2284], the EAP authenticator (NAS) is responsible for
retransmission of packets between the authenticating peer and the NAS.
If an EAP packet is lost in transit between the authenticating peer and
the NAS (or vice versa), the NAS will retransmit. As in RADIUS
[RFC2865], the RADIUS client is responsible for retransmission of
packets between the RADIUS client and the RADIUS server.

It may be necessary to adjust retransmission strategies and
authentication timeouts in certain cases. For example, when a token card
is used additional time may be required to allow the user to find the
card and enter the token. Since the NAS will typically not have
knowledge of the required parameters, these need to be provided by the
RADIUS server. This can be accomplished by inclusion of Session-Timeout
attribute within the Access-Challenge packet.

If Session-Timeout is present in an Access-Challenge packet that also
contains an EAP-Message, the value of the Session-Timeout is used to set
the EAP retransmission timer for that EAP Request, and that Request
alone. Once the EAP-Request has been sent, the NAS sets the
retransmission timer, and if it expires without having received an EAP-
Response corresponding to the Request, then the EAP-Request is
retransmitted.

2.4.  Fragmentation

Using the EAP-Message attribute, it is possible for the RADIUS server 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
server to use MTU discovery to ascertain the link MTU, the Framed-MTU
attribute may be included in an Access-Request packet containing an EAP-
Message attribute so as to provide the RADIUS server with this
information.

2.5.  Alternative uses

Currently the conversation between  security servers and the RADIUS
server is often proprietary because of lack of standardization.  In
order to increase standardization and provide interoperability between
RADIUS vendors and  security vendors, it is recommended that RADIUS-
encapsulated EAP be used for this conversation.

This has the advantage of allowing the RADIUS server to support EAP
without the need for authentication-specific  code within the RADIUS
server. Authentication-specific code can then reside on a security
server instead.




Aboba & Calhoun               Informational                    [Page 10]


INTERNET-DRAFT                RADIUS & EAP                 21 March 2003


In the case where RADIUS-encapsulated EAP is used in a conversation
between a RADIUS server and a  security server, the security server will
typically return an Access-Accept message without inclusion of the
expected attributes currently returned in an Access-Accept. This means
that the RADIUS server MUST add these attributes prior to sending an
Access-Accept message to the NAS.

2.6.  Usage guidelines

2.6.1.  Identifier space

In EAP, each session has its own unique Identifier space.  RADIUS server
implementations MUST be able to distinguish between EAP Responses with
the same Identifier existing within distinct sessions. For this purpose,
sessions can be distinguished based upon the NAS-Port, User-Name,
Called-Station-Id, and Calling-Station-Id attributes, in addition to the
identity of the NAS (as defined by the NAS-Identifier, NAS-IPv6-Address
or NAS-IPv4-Address attributes).

2.6.2.  Role reversal

Since EAP is a peer-to-peer protocol, an independent and simultaneous
authentication may take place in the reverse direction. Both peers may
act as authenticators and authenticatees at the same time.

However, role reversal is not supported by this specification. A RADIUS
server MUST respond to an Access-Request encapsulating an EAP-Request
with an Access-Reject. In order to avoid retransmissions by the peer,
the Access-Reject MAY include an EAP-Response/Nak packet indicating no
preferred method, encapsulated within EAP-Message attribute(s).

2.6.3.  Conflicting messages

Access-Accept packets SHOULD have only ONE EAP-Message attribute in
them, containing EAP Success; similarly, Access-Reject packets SHOULD
only have ONE EAP-Message attribute in them, containing EAP Failure.

Where the authentication result implied by the encapsulated EAP packet
does not match the result implies by the RADIUS Packet Type, the
authenticator MUST make its access control decision based on the RADIUS
Packet Type (Access-Accept/Access-Reject), and not based on the contents
of the EAP packet encapsulated in one or more EAP-Message attributes, if
present.

Where the encapsulated EAP packet does not match the result implied by
the RADIUS Packet Type, the combination is likely to cause confusion,
because the NAS and peer will arrive at different conclusions as to the
outcome of the authentication.



Aboba & Calhoun               Informational                    [Page 11]


INTERNET-DRAFT                RADIUS & EAP                 21 March 2003


For example, an EAP Failure packet may be encapsulated within an Access-
Accept and an EAP Success packet may be encapsulated within an Access-
Reject. Alternatively, an EAP-Message attribute may not be included
within a RADIUS Access-Accept or Access-Reject.

If the NAS receives an Access-Reject with an encapsulated EAP Success,
it will not grant access to the peer. However, on receiving the EAP
Success, the peer will be lead to believe that it authenticated
successfully.

If the NAS receives an Access-Accept with an encapsulated EAP Failure,
it will grant access to the peer. However, on receiving an EAP Failure,
the peer will be lead to believe that it failed authentication. If no
EAP-Message attribute is included within an Access-Accept or Access-
Reject, then the peer may not be informed as to the outcome of the
authentication, while the NAS will take action to allow or deny access.

As described in [RFC2284], the EAP Success and Failure packets are not
acknowledged, and these packets terminate the EAP conversation. As a
result, if these packets are encapsulated within an Access-Challenge, no
response will be received, and therefore the NAS will send no further
Access-Requests to the RADIUS server. As a result, the NAS will not be
given an indication of whether to allow or deny access while the peer
will be informed as to the outcome of the authentication.

To avoid these conflicts, the following combinations SHOULD NOT be sent
by a RADIUS server:

   Access-Accept/EAP-Message/EAP Failure
   Access-Accept/no EAP-Message attribute
   Access-Accept/EAP-Start
   Access-Reject/EAP-Message/EAP Success
   Access-Reject/no EAP-Message attribute
   Access-Reject/EAP-Start
   Access-Challenge/EAP-Message/EAP Success
   Access-Challenge/EAP-Message/EAP Failure
   Access-Challenge/no EAP-Message attribute
   Access-Challenge/EAP-Start

The only exception to this is an Access-Challenge packet that contains a
Service-Type attribute with a value of Packet-Reject.  Such a packet may
contain no EAP-Message attribute.

Since the responsibility for avoiding conflicts lies with the RADIUS
server, the NAS MUST NOT "manufacture" EAP packets in order to correct
contradictory messages that it receives. This behavior, originally
mandated within [IEEE8021X], is now deprecated.




Aboba & Calhoun               Informational                    [Page 12]


INTERNET-DRAFT                RADIUS & EAP                 21 March 2003


2.6.4.  Priority

In addition to containing EAP-Message attributes, RADIUS messages may
also contain other attributes. In order to ensure the correct processing
of RADIUS messages, on receiving an Access-Accept, Access-Reject or
Access-Challenge, the NAS SHOULD process other attributes first, then
decapsulate EAP-Message attribute(s), reconstitute the EAP packet and
send it to the peer.

2.6.5.  Displayable messages

The Reply-Message attribute, defined in [RFC2865], Section 5.18,
indicates text which may be displayed to the user. This is similar in
concept to EAP Notification, defined in [RFC2284].  When sending a
displayable message to a NAS during an EAP conversation, the RADIUS
server MUST encapsulate displayable messages within EAP-Message/EAP-
Request/Notification attribute(s).  Reply-Message attribute(s) MUST NOT
be included in any RADIUS message containing an EAP-Message attribute.
An EAP-Message/EAP-Request/Notification SHOULD NOT be included within an
Access-Accept or Access-Reject packet.

In some existing implementations, a NAS receiving Reply-Message
attribute(s) copies the Text field(s) into the Type-Data field of an
EAP-Request/Notification packet, fills in the Identifier field, and
sends this to the peer. However, several issues arise from this:

[1]  Unexpected Responses. On receiving an EAP-Request/Notification, the
     peer will send an EAP-Response/Notification, and the NAS will pass
     this on to the RADIUS server, encapsulated within EAP-Message
     attribute(s).  However, the RADIUS server may not be expecting an
     Access-Request containing an EAP-Message/EAP-Response/Notification
     attribute.

     For example, consider what happens when a Reply-Message is included
     within an Access-Accept or Access-Reject packet with no EAP-Message
     attribute(s) present.  If the value of the Reply-Message attribute
     is copied into the Type-Data of an EAP-Request/Notification and
     sent to the peer, this will result in an Access-Request containing
     an EAP-Message/EAP-Response/Notification attribute being sent by
     the NAS to the RADIUS server. Since an Access-Accept or Access-
     Reject packet terminates the RADIUS conversation, such an Access-
     Request would not be expected, and could be interpreted as the
     start of another conversation.

[2]  Identifier conflicts. While the EAP-Request/Notification is an EAP
     packet containing an Identifier field, the Reply-Message attribute
     does not contain an Identifier field. As a result, a NAS receiving
     a Reply-Message attribute and wishing to translate this to an EAP-



Aboba & Calhoun               Informational                    [Page 13]


INTERNET-DRAFT                RADIUS & EAP                 21 March 2003


     Request/Notification will need to choose an Identifier value. It is
     possible that the chosen Identifier value will conflict with a
     value chosen by the RADIUS server for another packet within the EAP
     conversation, potentially causing confusion between a new packet
     and a retransmission.

In order to avoid these problems, a NAS in pass-through mode receiving a
Reply-Message attribute from the RADIUS server SHOULD silently discard
the attribute.

3.  Attributes

3.1.  EAP-Message

Description

   This attribute encapsulates EAP [RFC2284] packets so as to allow the
   NAS to authenticate users via EAP without having to understand the
   EAP method it is passing through.

   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-
   Message attributes  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.  The
   RADIUS server can return EAP-Message attributes in Access-Challenge,
   Access-Accept and Access-Reject packets.

   When RADIUS is used to enable EAP authentication, Access-Request,
   Access-Challenge, Access-Accept, and Access-Reject packets SHOULD
   contain one or more EAP-Message attributes. Where more than one EAP-
   Message attribute is included, it is assumed that the attributes are
   to be concatenated to form a single EAP packet.  As a result,
   multiple EAP packets MUST NOT be encoded within EAP-Message
   attributes contained within a single Access-Challenge, Access-Accept,
   Access-Reject or Access-Request packet.

   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 EAP Success or EAP
   Failure packets) it is necessary that RADIUS/EAP provide integrity
   protection.

   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.



Aboba & Calhoun               Informational                    [Page 14]


INTERNET-DRAFT                RADIUS & EAP                 21 March 2003


   Access-Request packets including EAP-Message attribute(s) without a
   Message-Authenticator attribute SHOULD be silently discarded by the
   RADIUS server.  A RADIUS server supporting the EAP-Message attribute
   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 the EAP-Message attribute MUST return an
   Access-Reject if it receives an Access-Request containing an EAP-
   Message attribute.

   Access-Challenge, Access-Accept, or Access-Reject packets including
   EAP-Message attribute(s) without a Message-Authenticator attribute
   SHOULD be silently discarded by the NAS. A NAS supporting the EAP-
   Message attribute 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 an EAP packet, as defined in [RFC2284].  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 transported by RADIUS.

3.2.  Message-Authenticator

Description

   This attribute MAY be used to authenticate and integrity-protect
   Access-Requests in order to prevent spoofing. 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-



Aboba & Calhoun               Informational                    [Page 15]


INTERNET-DRAFT                RADIUS & EAP                 21 March 2003


   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.

   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 [RFC2104] hash 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 message integrity check 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)



Aboba & Calhoun               Informational                    [Page 16]


INTERNET-DRAFT                RADIUS & EAP                 21 March 2003


   When the message integrity check 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 message integrity check.  The
   Message-Authenticator 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.

3.3.  Table of Attributes

The following table provides a guide to which attributes may be found in
which kind of packets.  The EAP-Message and Message-Authenticator
attributes specified in this document MUST NOT be present in an
Accounting-Request.

The following table provides a guide to which attributes may be found in
packets sent as part of an EAP conversation, and in what quantity. If a
table entry is omitted, the values found in [RFC2548],
[RFC2865]-[RFC2869] and [RFC3162] should be assumed.

Request   Accept   Reject   Challenge   #    Attribute
0-1       0-1      0        0            1   User-Name
0         0        0        0            2   User-Password [Note 1]
0         0        0        0            3   CHAP-Password [Note 1]
0-1       0-1      0        0-1          6   Service-Type
0         0        0        0           18   Reply-Message
0-1       0-1      0        0-1         24   State
0         0+       0        0           25   Class
0         0-1      0        0-1         27   Session-Timeout
0+        0+       0+       0+          33   Proxy-State
0         0        0        0           60   CHAP-Challenge
0-1       0        0        0           70   ARAP-Password [Note 1]
0         0        0        0           75   Password-Retry
1+        1+       1+       1+          79   EAP-Message [Note 1]
1         1        1        1           80   Message-Authenticator [Note 1]
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-



Aboba & Calhoun               Informational                    [Page 17]


INTERNET-DRAFT                RADIUS & EAP                 21 March 2003


Authenticator.  If any packet type contains an EAP-Message attribute it
MUST also contain a Message-Authenticator.

The following table defines the meaning of 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.
1+    One or more of these attributes MUST be present.

4.  Security Considerations

4.1.  Security requirements

RADIUS/EAP is used in order to provide authentication and authorization
for network access. As a result, both the RADIUS and EAP portions of the
conversation are open to attack. Threats are discussed in [RFC2607],
[RFC2865], and [RFC3162]. Examples include:

[1]  An adversary may attempt to acquire confidential data and
     identities by snooping RADIUS packets.

[2]  An adversary may attempt to modify packets containing RADIUS
     messages.

[3]  An adversary may attempt to inject packets into a RADIUS
     conversation.

[4]  An adversary may launch a dictionary attack against
     the RADIUS shared secret.

[5]  An adversary may launch a known plaintext attack, hoping to
     recover the key stream corresponding to a Request Authenticator.

[6]  An adversary may attempt to replay a RADIUS exchange.

[7]  An adversary may attempt to disrupt the EAP negotiation,
     in order to weaken the authentication, or gain access to user
     passwords.

[8]  An authenticated NAS may attempt to forge attributes,
     including NAS-IP-Address, NAS-Identifier, Called-Station-Id,
     or Calling-Station-Id.

[9]  A rogue (unauthenticated) NAS may attempt to impersonate a
     legitimate NAS.




Aboba & Calhoun               Informational                    [Page 18]


INTERNET-DRAFT                RADIUS & EAP                 21 March 2003


[10] An attacker may attempt to act as a man-in-the-middle.

To address these threats, it is necessary to support confidentiality,
data origin authentication, integrity, and replay protection on a per-
packet basis.  Bi-directional authentication between the RADIUS client
and server also needs to be provided.  There is no requirement that the
identities of RADIUS clients and servers be kept confidential (e.g.,
from a passive eavesdropper).

4.2.  Security protocol

To address the security threats for RADIUS/EAP, in addition to
supporting RADIUS security as defined in [RFC2865] and [RFC2866],
RADIUS/EAP implementations SHOULD support IPsec [RFC2401] along with IKE
[RFC2409] for key management. IPsec ESP [RFC2406] with non-null
transform, and per-packet authentication, integrity and replay
protection SHOULD be used, along with IKE for key management.

Within RADIUS [RFC2865], a shared secret is used for hiding of
attributes such as User-Password, as well as in computation of the
Response Authenticator. In RADIUS accounting [RFC2866], the shared
secret is used in computation of both the Request Authenticator and the
Response Authenticator.

Since in RADIUS a shared secret is used to provide confidentiality as
well as integrity protection and authentication, only use of IPsec ESP
with a non-null transform can provide security services sufficient to
substitute for RADIUS application-layer security.  Therefore, where
IPSEC AH or ESP null is used, it will typically still be necessary to
configure a RADIUS shared secret.

Where RADIUS is run over IPsec ESP with a non-null transform, the secret
shared between the NAS and the RADIUS server may not be configured.  In
this case, a shared secret of zero length MUST be assumed.  However, a
RADIUS server that cannot know whether incoming traffic is IPsec-
protected MUST be configured with a non-null RADIUS shared secret.

When IPsec ESP is used with RADIUS, DES-CBC SHOULD NOT be used as the
encryption transform, and per-packet authentication, integrity and
replay protection MUST be used. A typical IPsec policy for an IPsec-
capable RADIUS client is "Initiate IPsec, from me to any destination
port UDP 1812".

This causes an IPsec SA to be set up by the RADIUS client prior to
sending RADIUS traffic. If some RADIUS servers contacted by the client
do not support IPsec, then a more granular policy will be required:
"Initiate IPsec, from me to IPsec-Capable-RADIUS-Server, destination
port UDP 1812".



Aboba & Calhoun               Informational                    [Page 19]


INTERNET-DRAFT                RADIUS & EAP                 21 March 2003


For an IPsec-capable RADIUS server, a typical IPsec policy is "Accept
IPsec, from any to me, destination port 1812".  This causes the RADIUS
server to accept (but not require) use of IPsec. It may not be
appropriate to require IPsec for all RADIUS clients connecting to an
IPsec-enabled RADIUS server, since some RADIUS clients may not support
IPsec.

Where IPsec is used for security, and no RADIUS shared secret is
configured, it is important that trust be demonstrated between the
RADIUS client and RADIUS server by some means. For example, before
enabling an IKE-authenticated host to act as a RADIUS client, the RADIUS
server should check whether the host is authorized to provide network
access. Similarly, before enabling an IKE-authenticated host to act as a
RADIUS server, the RADIUS client should check whether the host is
authorized for that role.

RADIUS servers can be configured with the IP addresses (for IKE
Aggressive Mode with pre-shared keys) or FQDNs (for certificate
authentication) of RADIUS clients.  Alternatively, if a separate CA
exists for RADIUS clients, then the RADIUS server can configure this CA
as a trusted root for use with IPsec.

Similarly, RADIUS clients can be configured with the IP addresses (for
IKE Aggressive Mode with pre-shared keys) or FQDNs (for certificate
authentication) of RADIUS servers.  Alternatively, if a separate CA
exists for RADIUS servers, then the RADIUS client can configure this CA
as a trusted root for use with IPsec.

Since unlike SSL/TLS, IKE does not permit certificate policies to be set
on a per-port basis, certificate policies need to apply to all uses of
IPsec on RADIUS clients and servers. In IPsec deployment supporting only
certificate authentication, a management station initiating an IPsec-
protected telnet session to the RADIUS server would need to obtain a
certificate chaining to the RADIUS client CA. Issuing such a certificate
might  not be appropriate if the management station was not authorized
as a RADIUS client.

Where RADIUS clients may obtain their IP address dynamically (such as an
Access Point supporting DHCP), Main Mode with pre-shared keys [RFC2409]
SHOULD NOT be used, since this requires use of a group pre-shared key;
instead, Aggressive Mode SHOULD be used. Where RADIUS client addresses
are statically assigned either Aggressive Mode or Main Mode MAY be used.
With certificate authentication, Main Mode SHOULD be used.

Care needs to be taken with IKE Phase 1 Identity Payload selection in
order to enable mapping of identities to pre-shared keys even with
Aggressive Mode. Where the ID_IPV4_ADDR or ID_IPV6_ADDR Identity
Payloads are used and addresses are dynamically assigned, mapping of



Aboba & Calhoun               Informational                    [Page 20]


INTERNET-DRAFT                RADIUS & EAP                 21 March 2003


identities to keys is not possible, so that group pre-shared keys are
still a practical necessity. As a result, the ID_FQDN identity payload
SHOULD be employed in situations where Aggressive mode is utilized along
with pre-shared keys and IP addresses are dynamically assigned. This
approach also has other advantages, since it allows the RADIUS server
and client to configure themselves based on the fully qualified domain
name of their peers.

Note that with IPsec, security services are negotiated at the
granularity of an IPsec SA, so that RADIUS exchanges requiring a set of
security services different from those negotiated with existing IPsec
SAs will need to negotiate a new IPsec SA. Separate IPsec SAs are also
advisable where quality of service considerations dictate different
handling RADIUS conversations. Attempting to apply different quality of
service to connections handled by the same IPsec SA can result in
reordering, and falling outside the replay window. For a discussion of
the issues, see [RFC2983].

4.3.  Security issues

This section provides more detail on the vulnerabilities identified in
Section 4.1, and how they may be mitigated. Vulnerabilities include:

Privacy issues
Message-Authenticator security
Connection hijacking
Dictionary attacks
Known plaintext attacks
Replay attacks
Negotiation attacks
Impersonation
Man in the middle attacks
Separation of EAP server and authenticator
Multiple databases

4.3.1.  Privacy issues

Since RADIUS messages may contain the User-Name attribute as well as
NAS-IP-Address or NAS-Identifier attributes, an attacker snooping on
RADIUS traffic may be able to determine the geographic location of users
in real time. In wireless networks, it is often assumed that RADIUS
traffic is physically secure, since it typically travels over the wired
network and that this limits the release of location information.

However, it is possible for an authenticated attacker to spoof ARP
packets from another Access Point so as to cause diversion of RADIUS
traffic onto the wireless network. In this way an attacker may obtain
RADIUS packets from which it can glean location information, or which it



Aboba & Calhoun               Informational                    [Page 21]


INTERNET-DRAFT                RADIUS & EAP                 21 March 2003


can subject to an offline dictionary attack.  To address this
vulnerabilities, IPsec ESP with non-null transform and per-packet
authentication, integrity and replay protection SHOULD be used to
protect both RADIUS authentication [RFC2865] and accounting [RFC2866]
traffic.

4.3.2.  Message-Authenticator security

Access-Request packets with a User-Password attribute 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
attributes 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 attribute, in order to establish the identity
of the NAS sending the request. The Message-Authenticator attribute MUST
be present in all RADIUS/EAP packets.

4.3.3.  Connection hijacking

An attacker may attempt to inject packets into the conversation between
the NAS and the RADIUS server, or between the RADIUS server and the
security server. RADIUS does not support encryption other than attribute
hiding, and as described in [RFC2865], only Access-Reply and Access-
Challenge packets are integrity protected. Moreover, the integrity
protection mechanism described in [RFC2865] 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 RADIUS/EAP packets MUST include the Message-Authenticator
attribute.

4.3.4.  Dictionary attacks

The RADIUS shared secret is vulnerable to offline dictionary attack,
based on capture of the Response authenticator or Message-Authenticator
attribute.  In order to decrease the level of vulnerability, [RFC2865]
recommends:

   The secret (password shared between the client and the RADIUS server)
   SHOULD be at least as large and unguessable as a well- chosen
   password.  It is preferred that the secret be at least 16 octets.

The risk of an offline dictionary attack can be further reduced by
employing IPsec ESP with non-null transform in order to encrypt the
RADIUS conversation, as described in Section 4.2.




Aboba & Calhoun               Informational                    [Page 22]


INTERNET-DRAFT                RADIUS & EAP                 21 March 2003


4.3.5.  Known plaintext attacks

Since EAP [RFC2284] does not support PAP, the RADIUS User-Password
attribute is not used to carry hidden user passwords within EAP
conversations. The User-Password hiding mechanism, defined in [RFC2865]
utilizes MD5, defined in [RFC1321], in order to generate a key stream
based on the RADIUS shared secret and the Request  authenticator.  Where
PAP is in use, it is possible to collect key streams corresponding to a
given Request Authenticator value, by capturing RADIUS conversations
corresponding to a PAP authentication attempt using a known password.
Since the User-Password is known, the key stream corresponding to a
given Request Authenticator can be determined and stored.

Since the key stream may have been determined previously from a known
plaintext attack, if the Request Authenticator repeats, attributes
encrypted using the RADIUS attribute hiding mechanism should be
considered compromised. In addition to the User-Password attribute,
which is not used with EAP, this includes attributes such as Tunnel-
Password [RFC2868, section 3.5] and MS-MPPE-Send-Key and MS-MPPE-Recv-
Key attributes [RFC2548, section 2.4], which include a Salt field as
part of the hiding algorithm.

To avoid this, [RFC2865], Section 3 advises:

   Since it is expected that the same secret MAY be used to authenticate
   with servers in disparate geographic regions, the Request
   Authenticator field SHOULD exhibit global and temporal uniqueness.

Where the Request Authenticator repeats, the Salt field defined in
[RFC2548], Section 2.4 does not provide protection against compromise.
This is because MD5 [RFC1321], rather than HMAC-MD5 [RFC2104], is used
to generate the key stream, which is calculated from the 128-bit RADIUS
shared secret (S), the  128-bit Request Authenticator (R), and the Salt
field (A), using the formula b(1) = MD5(S + R + A). Since the Salt field
is placed at the end, if the Request Authenticator were to repeat on a
network where PAP is in use, then the salted keystream could be
calculated from the User-Password keystream by continuing the MD5
calculation based on the Salt field (A), which is sent in the clear.

Even though EAP does not support PAP authentication, a security
vulnerability can still exist where the same RADIUS shared secret is
used for hiding User-Password as well as other attributes.  This can
occur, for example, if the same RADIUS proxy handles authentication
requests for both EAP and PAP.

The threat can be mitigated by protecting RADIUS with IPsec ESP with
non-null transform, as described in Section 4.2.  Where RADIUS shared
secrets are configured, the RADIUS shared secret used by a NAS



Aboba & Calhoun               Informational                    [Page 23]


INTERNET-DRAFT                RADIUS & EAP                 21 March 2003


supporting EAP MUST NOT be reused by a NAS supporting PAP
authentication, since improper shared secret hygiene could lead to
compromise of hidden attributes.

4.3.6.  Replay attacks

The RADIUS protocol provides only limited support for replay protection.
RADIUS Access-Requests include liveness via the 128-bit Request
authenticator.  However, the Request Authenticator is not a replay
counter. Since RADIUS servers may not maintain a cache of previous
Request Authenticators, the Request Authenticator does not provide
replay protection.

RADIUS accounting [RFC2866] does not support replay protection at the
protocol level. Due to the need to support failover between RADIUS
accounting servers, protocol-based replay protection is not sufficient
to prevent duplicate accounting records.  However, once accepted by the
accounting server, duplicate accounting records can be detected by use
of the the Acct-Session-Id [RFC2866, section 5.5] and Event-Timestamp
[RFC2869, section 5.3] attributes.

Unlike RADIUS authentication, RADIUS accounting does not use the Request
Authenticator as a nonce. Instead, the Request Authenticator contains an
MD5 hash calculated over the Code, Identifier, Length, and request
attributes of the Accounting Request packet, plus the shared secret. The
Response Authenticator also contains an MD5 hash calculated over the
Code, Identifier and Length, the Request Authenticator field from the
Accounting-Request packet being replied to, the response attributes and
the shared secret.

Since the Accounting Response Authenticator depends in part on the
Accounting Request Authenticator, it is not possible to replay an
Accounting-Response unless the Request Authenticator repeats.  While it
is possible to utilize EAP methods such as EAP TLS [RFC2716] which
include liveness checks on both sides, not all EAP messages will include
liveness so that this provides incomplete protection.

Strong replay protection for RADIUS authentication and accounting can be
provided by enabling IPsec replay protection with RADIUS, as described
in Section 4.2.

4.3.7.  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



Aboba & Calhoun               Informational                    [Page 24]


INTERNET-DRAFT                RADIUS & EAP                 21 March 2003


connection that would normally be authenticated via one EAP type occurs
via a less secure EAP type, such as MD5-Challenge. 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 [Masters].

Protection against negotiation attacks requires the elimination of
downward negotiations. This can be achieved by protecting the RADIUS
exchange using IPsec as described in Section 4.2. Alternatively, where
IPsec is not used, the vulnerability can be mitigated 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 a strong EAP method when connecting to one service, while
negotiating a weaker EAP method for another service.

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 a weaker method, such as CHAP or PAP.
In wireless networks, the service advertisement itself may be spoof-
able, so that an attacker could fool the peer into negotiating an
authentication method suitable for a less secure network.

For a NAS, it may not be possible to determine whether a peer is
required to authenticate with EAP until the peer's identity is known.
For example, for shared-uses NASes it is possible for one reseller to
implement EAP while another does not. Alternatively, some peer might be
authenticated locally by the NAS while other peers are authenticated via
RADIUS. In such cases, if any peers of the NAS MUST do EAP, then the NAS
MUST attempt to negotiate EAP for every session. This avoids forcing an
EAP-capable client to support more than one authentication type, which
could weaken 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



Aboba & Calhoun               Informational                    [Page 25]


INTERNET-DRAFT                RADIUS & EAP                 21 March 2003


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, a PPP 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 connecting from one location (with an EAP-capable
proxy) might be able to successfully authenticate via EAP, while the
same user connecting at another location (and encountering an EAP-
incapable proxy) might be consistently disconnected.

4.3.8.  Impersonation

When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or
NAS-IPv6-Address attributes may not correspond to the source address.
Since the NAS-Identifier attribute need not contain an FQDN, it also may
not correspond to the source address, even indirectly.  [RFC2865]
Section 3 states:

   A RADIUS server MUST use the source IP address of the RADIUS
   UDP packet to decide which shared secret to use, so that
   RADIUS requests can be proxied.

This implies that it is possible for a rogue NAS to forge NAS-IP-
Address, NAS-IPv6-Address or NAS-Identifier attributes within a RADIUS
Access-Request in order to impersonate another NAS. This could result in
Disconnect or CoF messages being sent to the wrong NAS. Since the rogue
NAS is authenticated by the RADIUS proxy or server purely based on the
source address, other mechanisms are required to detect the forgery.  In
addition, it is possible for attributes such as the Called-Station-Id
and Calling-Station-Id to be forged as well.

To address these vulnerabilities RADIUS proxies SHOULD check whether the
NAS-IP-Address or NAS-IPv6-Address attributes match the source address
of packets originating from the NAS. If the NAS-Identifier attribute is
used instead, such a check may not be possible since the NAS-Identifier
may not correspond to an FQDN, and therefore may not be resolvable to an
IP address to be matched against the source address. Also, where a NAT
exists between the RADIUS client and server, checking the NAS-IP-Address
or NAS-IPv6-Address attributes may not be feasible.

To allow verification of session parameters such as the Called-Station-
Id and Calling-Station-Id, they can be sent by the EAP peer to the EAP



Aboba & Calhoun               Informational                    [Page 26]


INTERNET-DRAFT                RADIUS & EAP                 21 March 2003


server, and covered by an EAP method-specific message integrity check.
The RADIUS server can then check the parameters sent by the EAP client
against those claimed by the NAS. If a discrepancy is found, an error
can be logged.

4.3.9.  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. This is
the case even where IPsec is used to protect RADIUS.

4.3.10.  Separation of EAP server and authenticator

It is possible for the EAP peer and authenticator to mutually
authenticate, and derive a Master Session Key (MSK) for a ciphersuite
used to protect subsequent data traffic.  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 derive and pass a
Transient Session Key (TSK) to the ciphersuite module.

The situation is more complex when EAP is used with RADIUS, since the
authenticator will typically not reside on the same machine as the EAP
server. For example, the EAP server may be a  security server, or a
module residing on the RADIUS server.

In the case where the EAP server and authenticator reside on different
machines, there are several implications for security.  First, 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, using EAP alone.

As described in Section 4, when EAP/RADIUS is used to encapsulate EAP
packets, IPsec SHOULD be used to provide per-packet authentication,
integrity, replay protection and confidentiality.  The Message-
Authenticator attribute is also 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 message integrity
check, 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, even
where IPsec is not used.  Similarly, Access-Challenge packets sent from
the RADIUS server to the NAS are also authenticated and integrity
protected using an HMAC-MD5 message integrity check, enabling the NAS or
tunnel server to determine the integrity of the packet and verify the
identity of the RADIUS server, even where IPsec is not used.  Moreover,
EAP packets sent using methods that contain their own integrity



Aboba & Calhoun               Informational                    [Page 27]


INTERNET-DRAFT                RADIUS & EAP                 21 March 2003


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
authenticator residing on different machines is that the EAP Master
Session Key (MSK) 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 MSK from the EAP server to the authenticator
or tunnel server that needs it. The specification of the key transport
and wrapping mechanism is outside the scope of this document.

4.3.11.  Multiple databases

In many cases a  security server will be deployed along with a RADIUS
server in order to provide EAP services. Unless the 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  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
security server store information in the same database; by having the
security server provide a full RADIUS implementation; or by
consolidating both the  security server and the RADIUS server onto the
same machine.

5.  IANA considerations

This specification does not create any new registries. However, it does
request allocation of a new value for the Service-Type attribute (6):
Packet-Reject.

6.  Normative references

[RFC1321]      Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
               April 1992.

[RFC2104]      Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
               Hashing for Message Authentication", RFC 2104, February
               1997.

[RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", RFC 2119, March 1997.]



Aboba & Calhoun               Informational                    [Page 28]


INTERNET-DRAFT                RADIUS & EAP                 21 March 2003


[RFC2279]      Yergeau, F., "UTF-8, a transformation format of ISO
               10646", RFC 2279, January 1998.

[RFC2284]      Blunk, L., and J. Vollbrecht, "Extensible Authentication
               Protocol (EAP)", RFC 2284, March 1998.

[RFC2401]      Atkinson, R., Kent, S., "Security Architecture for the
               Internet Protocol", RFC 2401, November 1998.

[RFC2406]      Kent, S., Atkinson, R., "IP Encapsulating Security
               Payload (ESP)", RFC 2406, November 1998

[RFC2409]      Harkins, D., Carrel, D., "The Internet Key Exchange
               (IKE)", RFC 2409, November 1998

[RFC2865]      Rigney, C., Willens, S., Rubens, A. and W. Simpson,
               "Remote Authentication Dial In User Service (RADIUS)",
               RFC 2865, June 2000.

7.  Informative references

[RFC1510]      Kohl, J., Neuman, C., "The Kerberos Network
               Authentication Service (V5)", RFC 1510, September 1993.

[RFC1661]      Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
               RFC 1661, July 1994.

[RFC2548]      Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",
               RFC 2548, March 1999.

[RFC2607]      Aboba, B., Vollbrecht, J., "Proxy Chaining and Policy
               Implementation in Roaming", RFC 2607, June 1999.

[RFC2716]      Aboba, B., Simon, D.,"PPP EAP TLS Authentication
               Protocol", RFC 2716, October 1999.

[RFC2866]      Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.

[RFC2867]      Zorn, G., Aboba, B., Mitton, D., "RADIUS Accounting
               Modifications for Tunnel Protocol Support", RFC 2867,
               June 2000.

[RFC2868]      Zorn, G. et. al, "RADIUS Attributes for Tunnel Protocol
               Support", RFC 2868, June 2000.

[RFC2869]      Rigney, C., Willats, W., Calhoun, P., "RADIUS
               Extensions", RFC 2869, June 2000.




Aboba & Calhoun               Informational                    [Page 29]


INTERNET-DRAFT                RADIUS & EAP                 21 March 2003


[RFC2983]      Black, D. "Differentiated Services and Tunnels", RFC
               2983, October 2000.

[RFC3162]      Aboba, B., Zorn, G., Mitton, D., "RADIUS and IP6", RFC
               3162, August 2001.

[IEEE802]      IEEE Standards for Local and Metropolitan Area Networks:
               Overview and Architecture, ANSI/IEEE Std 802, 1990.

[IEEE8021X]    IEEE Standards for Local and Metropolitan Area Networks:
               Port based Network Access Control, IEEE Std 802.1X-2001,
               June 2001.

[Masters]      Slatalla, M., and  Quittner, J., "Masters of Deception."
               HarperCollins, New York, 1995.




































Aboba & Calhoun               Informational                    [Page 30]


INTERNET-DRAFT                RADIUS & EAP                 21 March 2003


Appendix A - Examples

The examples below illustrate conversations between an authenticating
peer, NAS, and RADIUS server. The OTP and EAP-TLS protocols are used
only for illustrative purposes; other authentication protocols could
also have been used, although they might show somewhat different
behavior.

Where the NAS sends an EAP-Request/Identity as the initial packet, the
exchange appears as follows:

Authenticating peer     NAS                    RADIUS server
-------------------     ---                    -------------
                        <- EAP-Request/
                        Identity
EAP-Response/
Identity (MyID) ->
                        RADIUS Access-Request/
                        EAP-Message/EAP-Response/
                        (MyID) ->
                                                <- RADIUS
                                                Access-Challenge/
                                                EAP-Message/EAP-Request
                                                OTP/OTP Challenge
                        <- EAP-Request/
                        OTP/OTP Challenge
EAP-Response/
OTP, OTPpw ->
                        RADIUS Access-Request/
                        EAP-Message/EAP-Response/
                        OTP, OTPpw ->
                                                 <- RADIUS
                                                 Access-Accept/
                                                 EAP-Message/EAP-Success
                                                 (other attributes)
                        <- EAP-Success















Aboba & Calhoun               Informational                    [Page 31]


INTERNET-DRAFT                RADIUS & EAP                 21 March 2003


In the case where the NAS initiates with an EAP-Request for EAP TLS
[RFC2716], and the identity is determined based on the contents of the
client certificate, the exchange will appear as follows:

Authenticating peer     NAS                    RADIUS server
-------------------     ---                    -------------
                        <- EAP-Request/
                        EAP-Type=EAP-TLS
                        (TLS Start, S bit set)
EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
                        RADIUS Access-Request/
                        EAP-Message/EAP-Response/
                        EAP-Type=EAP-TLS->
                                               <-RADIUS Access-Challenge/
                                               EAP-Message/
                                               EAP-Request/
                                               EAP-Type=EAP-TLS
                         <- EAP-Request/
                         EAP-Type=EAP-TLS
                         (TLS server_hello,
                         TLS certificate,
                   [TLS server_key_exchange,]
                   [TLS certificate_request,]
                       TLS server_hello_done)
EAP-Response/
EAP-Type=EAP-TLS
(TLS certificate,
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished)->
                        RADIUS Access-Request/
                        EAP-Message/EAP-Response/
                        EAP-Type=EAP-TLS->
                                               <-RADIUS Access-Challenge/
                                               EAP-Message/
                                               EAP-Request/
                                               EAP-Type=EAP-TLS
                        <- EAP-Request/
                        EAP-Type=EAP-TLS
                        (TLS change_cipher_spec,
                        TLS finished)
EAP-Response/
EAP-Type=EAP-TLS ->
                        RADIUS Access-Request/
                        EAP-Message/EAP-Response/



Aboba & Calhoun               Informational                    [Page 32]


INTERNET-DRAFT                RADIUS & EAP                 21 March 2003


                        EAP-Type=EAP-TLS->
                                               <-RADIUS Access-Accept/
                                               EAP-Message/EAP-Success
                                               (other attributes)
                        <- EAP-Success

In the case where the NAS first sends an EAP-Start packet to the RADIUS
server,  the conversation would appear as follows:

Authenticating peer     NAS                    RADIUS server
-------------------     ---                    -------------
                        RADIUS Access-Request/
                        EAP-Message/Start ->
                                               <- RADIUS
                                               Access-Challenge/
                                               EAP-Message/EAP-Request/
                                               Identity
                        <- EAP-Request/
                        Identity
EAP-Response/
Identity (MyID) ->
                        RADIUS Access-Request/
                        EAP-Message/EAP-Response/
                        Identity (MyID) ->
                                                <- RADIUS
                                                Access-Challenge/
                                                EAP-Message/EAP-Request/
                                                OTP/OTP Challenge
                        <- EAP-Request/
                        OTP/OTP Challenge
EAP-Response/
OTP, OTPpw ->
                        RADIUS Access-Request/
                        EAP-Message/EAP-Response/
                        OTP, OTPpw ->
                                                 <- RADIUS
                                                 Access-Accept/
                                                 EAP-Message/EAP-Success
                                                 (other attributes)
                        <- EAP-Success











Aboba & Calhoun               Informational                    [Page 33]


INTERNET-DRAFT                RADIUS & EAP                 21 March 2003


In the case where the NAS initiates with an EAP-Request for EAP TLS
[RFC2716], but the peer responds with a Nak, indicating that it would
prefer another method not implemented locally on the NAS, the exchange
will appear as follows:

Authenticating peer     NAS                    RADIUS server
-------------------     ---                    -------------
                        <- EAP-Request/
                        EAP-Type=EAP-TLS
                        (TLS Start, S bit set)
EAP-Response/
EAP-Type=Nak
(Alternative(s))->
                        RADIUS Access-Request/
                        EAP-Message/Start ->
                                               <- RADIUS
                                               Access-Challenge/
                                               EAP-Message/EAP-Request/
                                               Identity
                        <- EAP-Request/
                        Identity
EAP-Response/
Identity (MyID) ->
                        RADIUS Access-Request/
                        EAP-Message/EAP-Response/
                        (MyID) ->
                                                <- RADIUS
                                                Access-Challenge/
                                                EAP-Message/EAP-Request
                                                OTP/OTP Challenge
                        <- EAP-Request/
                        OTP/OTP Challenge
EAP-Response/
OTP, OTPpw ->
                        RADIUS Access-Request/
                        EAP-Message/EAP-Response/
                        OTP, OTPpw ->
                                                 <- RADIUS
                                                 Access-Accept/
                                                 EAP-Message/EAP-Success
                                                 (other attributes)
                        <- EAP-Success









Aboba & Calhoun               Informational                    [Page 34]


INTERNET-DRAFT                RADIUS & EAP                 21 March 2003


In the case where the authenticating peer attempts to authenticate the
NAS, the conversation would appear as follows:

Authenticating Peer     NAS                    RADIUS Server
-------------------     ---                    -------------
EAP-Request/
Challenge, MD5 ->
                        RADIUS Access-Request/
                        EAP-Message/EAP-Request/
                        Challenge, MD5 ->
                                                 <- RADIUS
                                                 Access-Reject/
                                                 EAP-Message/
                                                 EAP-Response/
                                                 Nak (no alternative)

                        <- EAP-Response/Nak
                         (no alternative)
EAP-Failure ->

In the case where an invalid EAP Response is inserted by an attacker,
the conversation would appear as follows:

Authenticating peer     NAS                    RADIUS server
-------------------     ---                    -------------
                        <- EAP-Request/
                        EAP-Type=Foo
EAP-Response/
EAP-Type=Foo ->
                        RADIUS Access-Request/
                        EAP-Message/EAP-Response/
                        EAP-Type=Foo ->
                                               <- RADIUS
                                               Access-Challenge/
                                               EAP-Message/EAP-Request/
                                               EAP-Type=Foo
                        <- EAP-Request/
                        EAP-Type=Foo
Attacker spoof:
EAP-Response/
EAP-Type=Foo ->
                        RADIUS Access-Request/
                        EAP-Message/EAP-Response/
                        EAP-Type=Foo ->
                                               <- RADIUS
                                               Access-Challenge/
                                               Service-Type=Packet-Reject
EAP-Response/



Aboba & Calhoun               Informational                    [Page 35]


INTERNET-DRAFT                RADIUS & EAP                 21 March 2003


EAP-Type=Foo ->
                        RADIUS Access-Request/
                        EAP-Message/EAP-Response/
                        EAP-Type=Foo ->
                                               Access-Accept/
                                               EAP-Message/Success
                        <- EAP Success

In the case where the client fails EAP authentication, and an error
message is sent prior to disconnection, the conversation would appear as
follows:

Authenticating peer     NAS                    RADIUS server
-------------------     ---                    -------------
                        RADIUS Access-Request/
                        EAP-Message/Start ->
                                               <- RADIUS
                                               Access-Challenge/
                                               EAP-Message/EAP-Response/
                                               Identity
                        <- EAP-Request/
                        Identity
EAP-Response/
Identity (MyID) ->
                        RADIUS Access-Request/
                        EAP-Message/EAP-Response/
                        (MyID) ->
                                                <- RADIUS
                                                Access-Challenge/
                                                EAP-Message/EAP-Request
                                                OTP/OTP Challenge
                        <- EAP-Request/
                        OTP/OTP Challenge
EAP-Response/
OTP, OTPpw ->
                        RADIUS Access-Request/
                        EAP-Message/EAP-Response/
                        OTP, OTPpw ->
                                                 <- RADIUS
                                                 Access-Challenge/
                                                 EAP-Message/EAP-Request/
                                                 Notification
                        <- EAP-Request/
                           Notification
EAP-Response/
Notification ->
                        RADIUS Access-Request/
                        EAP-Message/EAP-Response/



Aboba & Calhoun               Informational                    [Page 36]


INTERNET-DRAFT                RADIUS & EAP                 21 March 2003


                        Notification ->
                                                 <- RADIUS
                                                 Access-Reject/
                                                 EAP-Message/EAP-Failure
                        <- EAP-Failure
                        (client disconnected)

In the case that the RADIUS server or proxy does not support EAP-
Message, but no error message is sent, the conversation would appear as
follows:

Authenticating peer     NAS                       RADIUS server
-------------------     ---                       -------------
                        RADIUS Access-Request/
                        EAP-Message/Start ->
                                                  <- RADIUS
                                                  Access-Reject
                        (User Disconnected)

In the case where the local RADIUS server does support EAP-Message, but
the remote RADIUS server does not, the conversation would appear as
follows:

Authenticating peer     NAS                       RADIUS server
-------------------     ---                       -------------
                        RADIUS Access-Request/
                        EAP-Message/Start ->
                                                  <- RADIUS
                                                  Access-Challenge/
                                                  EAP-Message/EAP-Response/
                                                  Identity
                        <- EAP-Request/
                        Identity

EAP-Response/
Identity
(MyID) ->
                        RADIUS Access-Request/
                        EAP-Message/EAP-Response/
                        (MyID) ->
                                                  <- RADIUS
                                                  Access-Reject
                                                  (proxied from remote
                                                   RADIUS server)
                        (User Disconnected)

In the case where PPP is the link and the authenticating peer does not
support EAP, but where EAP is required for that user, the conversation



Aboba & Calhoun               Informational                    [Page 37]


INTERNET-DRAFT                RADIUS & EAP                 21 March 2003


would appear as follows:

Authenticating peer     NAS                       RADIUS server
-------------------     ---                       -------------
                        <- PPP LCP Request-EAP
                        auth
PPP LCP NAK-EAP
auth ->
                        <- PPP LCP Request-CHAP
                        auth
PPP LCP ACK-CHAP
auth ->
                        <- PPP CHAP Challenge
PPP CHAP Response ->
                        RADIUS Access-Request/
                        User-Name,
                        CHAP-Password ->
                                                  <- RADIUS
                                                  Access-Reject
                        <-  PPP LCP Terminate
                        (User Disconnected)

In the case where PPP is the link, the NAS does not support EAP, but
where EAP is required for that user, the conversation would appear as
follows:

Authenticating peer     NAS                       RADIUS server
-------------------     ---                       -------------
                        <- PPP LCP Request-CHAP
                        auth

PP LCP ACK-CHAP
auth ->
                        <- PPP CHAP Challenge
PPP CHAP Response ->
                        RADIUS Access-Request/
                        User-Name,
                        CHAP-Password ->

                                                 <- RADIUS
                                                 Access-Reject
                        <-  PPP LCP Terminate
                        (User Disconnected)








Aboba & Calhoun               Informational                    [Page 38]


INTERNET-DRAFT                RADIUS & EAP                 21 March 2003


Appendix B - Change log

The following changes have been made from RFC 2869:

A NAS may simultaneously support both local authentication and pass-
through; once the NAS enters pass-through mode within a session, it
cannot revert back to local authentication. Also EAP is explicitly
described as a 'lock step' protocol. (Section 2).

The NAS may initiate with an EAP-Request for an authentication Type.  If
the Request is NAK'd, the NAS may send an initial Access-Request with an
EAP-Message attribute containing an EAP-Response/Nak. In such a packet,
an EAP-Start must not also be included (Section 2.1)

The RADIUS server may treat an invalid EAP Response as a non-fatal error
(Section 2.2)

The Password-Retry (Section 2.3) and Reply-Message (2.6.5) attributes
are deprecated.

Each EAP session has a unique Identifier space (Section 2.6.1).

Role reversal is not supported (Section 2.6.2).

Message combinations (e.g. Access-Accept/EAP-Failure) that conflict are
discouraged (Section 2.6.3).

EAP-Message attributes are processed last (Section 2.6.4).

Only a single EAP packet may be encapsulated within a RADIUS message
(Section 3.1).

IPsec ESP with non-null transform SHOULD be used and the usage model is
described in detail (Section 4.2).

Additional discussion of security vulnerabilities (Section 4.1) and
potential fixes (Section 4.3).

Separated normative (Section 5) and informative (Section 6) references.

Added additional examples (Appendix A): the NAS initiating with an EAP-
Request for an authentication Type; attempted role reversal.









Aboba & Calhoun               Informational                    [Page 39]


INTERNET-DRAFT                RADIUS & EAP                 21 March 2003


Acknowledgments

Thanks to Dave Dawson and Karl Fox of Ascend, Glen Zorn of Cisco
Systems, Jari Arkko of Ericsson and Ashwin Palekar, Tim Moore and
Narendra Gidwani of Microsoft for useful discussions of this problem
space. The authors would also like to acknowledge Tony Jeffree, Chair of
IEEE 802.1 for his assistance in resolving RADIUS/EAP issues in IEEE
802.1X.

Author's Addresses

Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

Phone:  +1 425 706 6605
Fax:    +1 425 936 7329
EMail:   bernarda@microsoft.com

Pat R. Calhoun
Airespace
250 Cambridge Avenue, Suite 200
Palo Alto, California, 94306
USA

Phone:  +1 650-617-2932
Fax:    +1 650-786-6445
E-mail:  pcalhoun@airespace.com

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to  pertain
to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any
effort to identify any such rights.  Information on the IETF's
procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP-11.  Copies of claims of
rights made available for publication and any assurances of licenses to
be made available, or the result of an attempt made to obtain a general
license or permission for the use of such proprietary rights by
implementors or users of this specification can be obtained from the
IETF Secretariat.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights



Aboba & Calhoun               Informational                    [Page 40]


INTERNET-DRAFT                RADIUS & EAP                 21 March 2003


which may cover technology that may be required to practice this
standard.  Please address the information to the IETF Executive
Director.

Full Copyright Statement

Copyright (C) The Internet Society (2003).  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."

Open issues

Open issues relating to this specification are tracked on the following
web site:

http://www.drizzle.com/~aboba/EAP/eapissues.html

Expiration Date

This memo is filed as <draft-aboba-radius-rfc2869bis-10.txt>, and
expires September 24, 2003.













Aboba & Calhoun               Informational                    [Page 41]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/