[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-06.txt>              Black Storm Networks
11 January 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               11 January 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       Role reversal ...................................    8
   2.3       Retransmission ..................................    8
   2.4       Fragmentation ...................................    9
   2.5       Alternative uses ................................    9
   2.6       Usage guidelines ................................    9
3.     Attributes ............................................   12
   3.1       Password-Retry ..................................   12
   3.2       EAP-Message .....................................   13
   3.3       Message-authenticator ...........................   14
   3.4       Table of attributes .............................   16
4.     Security considerations ...............................   16
   4.1       Message-authenticator Security ..................   16
   4.2       EAP Security ....................................   17
5.     Normative references ..................................   22
6.     Informative references ................................   22
Appendix A - Examples ........................................   24
ACKNOWLEDGMENTS ..............................................   31
AUTHORS' ADDRESSES ...........................................   31
Full Copyright Statement .....................................   31

























Aboba & Calhoun               Informational                     [Page 2]


INTERNET-DRAFT                RADIUS & EAP               11 January 2003


1.  Introduction

[RFC2865] describes the RADIUS Protocol as it is implemented and
deployed today, and [RFC2866] describes how Accounting can be performed
with RADIUS.

The Extensible Authentication Protocol (EAP) 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 media is described in [IEEE8021X].

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

The Extensible Authentication Protocol (EAP) [RFC2284] provides support
for additional authentication methods.  This memo describes how the EAP-
Message and Message- authenticator attributes may be used for providing
EAP support within RADIUS.

A Network Access Server (NAS) that does not implement a given service
MUST NOT implement the RADIUS attributes for that service.  For example,
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               11 January 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 being
          authenticated by the authenticator. In IEEE 802.1X, this end
          is known as the Supplicant.

backend backend 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 user 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 user
          may have multiple sessions in parallel or series if the NAS
          supports that, with each session generating a separate start



Aboba & Calhoun               Informational                     [Page 4]


INTERNET-DRAFT                RADIUS & EAP               11 January 2003


          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.  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 backend authentication server which
may implement some or all authentication methods, with the NAS acting as
a pass- through for some or all methods and users.

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 user; both local and RADIUS
authentication may be in use simultaneously.

In order to provide for support of 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 backend 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 alternate EAP method is possible. For example, a NAS might be
configured to initiate with a default EAP 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.

The peer responds with an EAP-Response, which the NAS encapsulates
within EAP-Message attribute(s) within a RADIUS Access-Request packet,
sent to the RADIUS server. For example, if an EAP-Request/Identity



Aboba & Calhoun               Informational                     [Page 5]


INTERNET-DRAFT                RADIUS & EAP               11 January 2003


message is sent by the NAS as the first packet, the peer responds with
an EAP-Response/Identity, and the NAS encapsulates the EAP-
Response/Identity message within EAP-Message attribute(s), enclosed
within an Access-Request sent to the RADIUS server.

If the RADIUS server supports EAP, it MUST respond with an Access-
Challenge packet containing EAP-Message attribute(s). If the RADIUS
server does not support 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 an 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 may act as a pass-through for an EAP conversation
between the peer and backend authentication Server, without needing to
implement the EAP method used between them.  Even where the NAS
initiates the conversation by sending an EAP-Request, it is not required
that the NAS fully implement the EAP method sent in the first packet.
Depending on the 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.

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.

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-Challenge, Access-Accept or Access-
Reject 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.






Aboba & Calhoun               Informational                     [Page 6]


INTERNET-DRAFT                RADIUS & EAP               11 January 2003


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 RADIUS Access-Request as the
     result of a "carrier sense" or "media up" indication may inundate
     the RADIUS server with Requests that can never complete
     successfully.

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-
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.  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 a large number of uncompleted RADIUS conversations, in situations
where EAP unaware peers are common, it SHOULD NOT be employed by
default.

Where the NAS does not initially send an EAP-Request message to the
peer, 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. The NAS will
decapsulate this packet, send it to the peer, and receive an EAP-
Response packet from the peer. 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-
Challenge/EAP-Identity packet.  The response from the authenticating



Aboba & Calhoun               Informational                     [Page 7]


INTERNET-DRAFT                RADIUS & EAP               11 January 2003


peer MUST be proxied to the final backend 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.  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.

Support for role reversal is optional on the RADIUS server, and requires
the RADIUS server to be able to respond to an Access-Request containing
an EAP-Request encapsulated within EAP-Message attribute(s).  A RADIUS
server supporting role reversal will respond with an Access-Challenge
containing an EAP-Response encapsulated within EAP-Message attribute(s).
The conversation will end with the NAS sending an Access-Request
containing an EAP-Failure or EAP-Success message encapsulated within
EAP-Message attribute(s). The RADIUS server then replies with an Access-
Accept (in response to an EAP-Success) or an Access-Reject (in response
to an EAP-Failure), containing no EAP-Message attribute.

A RADIUS server that does not support role reversal 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 should
include an EAP-Response/NAK packet offering no alternative methods,
encapsulated within EAP-Message attribute(s).

Since with role reversal the RADIUS server acts as an EAP peer, a RADIUS
server not supporting role reversal and responding with an Access-Reject
MUST NOT include EAP-Message attribute(s) encapsulating an EAP Failure
packet. EAP Failure packets are sent only by the authenticator, not the
peer.

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



Aboba & Calhoun               Informational                     [Page 8]


INTERNET-DRAFT                RADIUS & EAP               11 January 2003


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
and Password-Retry attributes 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 provides the
NAS with the maximum number of seconds the NAS should wait for an EAP-
Response before retransmitting the EAP-Request.

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 backend 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 backend 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 backend
security server instead.

In the case where RADIUS-encapsulated EAP is used in a conversation
between a RADIUS server and a backend 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.  Conflicting messages

Within an EAP conversation, a RADIUS Access-Accept will typically
contain an EAP-Message attribute encapsulating an EAP Success packet.
Similarly, a RADIUS Access-Reject will typically contain an EAP-Message



Aboba & Calhoun               Informational                     [Page 9]


INTERNET-DRAFT                RADIUS & EAP               11 January 2003


attribute encapsulating an EAP Failure packet. However, in some cases,
the authentication result implied by the encapsulated EAP packet may not
match the result communicated in the RADIUS message. For example, an EAP
Failure packet may be encapsulated within an Access-Accept message and
an EAP Success packet may be encapsulated within an Access-Reject.
Alternatively, no EAP-Message attribute may be included within a RADIUS
Access-Accept or Access-Reject.

Such combinations are likely to cause confusion, because the NAS and
peer will arrive at different conclusions as to the outcome of the
authentication. For example, if the NAS receives an Access-Reject with
an encapsulated EAP Success, it will not grant access to the peer.
However, on receiving the Success, the peer will be lead to believe that
it authenticated successfully.

Similarly, 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 no further Access-Requests will
be sent 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 RADIUS server SHOULD check for agreement
between the encapsulated EAP-Message attribute and the RADIUS message.
The following combinations SHOULD NOT be sent by a RADIUS server as part
of an EAP conversation:

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

Since the responsibility for avoiding these 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], has since been deprecated.




Aboba & Calhoun               Informational                    [Page 10]


INTERNET-DRAFT                RADIUS & EAP               11 January 2003


2.6.2.  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, the NAS SHOULD process EAP-Message attributes last.

2.6.3.  Displayable messages

The Reply-Message attribute, defined in section 5.18 of [RFC2865],
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 SHOULD encapsulate displayable messages within EAP-Message/EAP-
Request/Notification attribute(s), and SHOULD NOT use Reply-Message
attribute(s) for this purpose.

A NAS receiving Reply-Message attribute(s) MAY copy the Text field(s)
into the Type-Data field of an EAP-Request/Notification packet, fill in
the Identifier field, and send 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-
     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. This would violate the requirement that  the
     Identifier be unique within an  EAP conversation.



Aboba & Calhoun               Informational                    [Page 11]


INTERNET-DRAFT                RADIUS & EAP               11 January 2003


2.6.4.  Multiple EAP-Message attributes

An Access-Challenge, Access-Accept, Access-Reject or Access-Request
message MAY contain zero or more EAP-Message attributes. However, 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. Since EAP
is a "lockstep" protocol, a new EAP-Request cannot be sent until an EAP-
Response is received to an outstanding request and only a single Request
can be outstanding at a given time.  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.

When used within an EAP conversation, a Reply-Message attribute received
by the NAS MAY be translated to an EAP-Request/Notification sent to the
peer. As a result, a Reply-Message attribute MUST NOT be included in a
RADIUS message containing an EAP-Message attribute. An EAP-Message/EAP-
Request/Notification or Reply-Message attribute SHOULD NOT be included
within an Access-Accept or Access-Reject packet representing the
conclusion of an EAP conversation.

3.  Attributes

3.1.  Password-Retry

Description

   This attribute MAY be included in an Access-Reject to indicate how
   many authentication attempts a user may be allowed to attempt before
   being disconnected.

   A summary of the Password-Retry attribute format is shown below.  The
   fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |             Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

   75 for Password-Retry.

Length




Aboba & Calhoun               Informational                    [Page 12]


INTERNET-DRAFT                RADIUS & EAP               11 January 2003


   6

Value

   The Value field is four octets, containing an integer specifying the
   number of password retry attempts to permit the user.

3.2.  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 any EAP messages received from the user into one or
   more EAP-Message attributes and forwards them to the RADIUS server as
   part of the Access-Request, which can return EAP messages in Access-
   Challenge, Access-Accept and Access-Reject packets.

   A RADIUS server receiving EAP messages that it does not understand
   SHOULD return an Access-Reject.

   The NAS places EAP messages received from the authenticating peer
   into one or more EAP-Message attributes and forwards them to the
   RADIUS server within an Access-Request message.  If multiple EAP-
   Messages are contained within an Access-Request or Access- Challenge
   packet, they MUST be in order and they MUST be consecutive attributes
   in the Access-Request or Access-Challenge packet.

   It is expected that EAP will be used to implement a variety of
   authentication methods, including methods involving strong
   cryptography. In order to prevent attackers from subverting EAP by
   attacking RADIUS/EAP, (for example, by modifying the EAP-Success or
   EAP-Failure packets) it is necessary that RADIUS/EAP provide
   integrity protection.

   Therefore the Message-authenticator attribute MUST be used to protect
   all Access-Request, Access-Challenge, Access-Accept, and Access-
   Reject packets containing an EAP-Message attribute.

   Access-Request packets including 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-



Aboba & Calhoun               Informational                    [Page 13]


INTERNET-DRAFT                RADIUS & EAP               11 January 2003


   Message attribute. A RADIUS server receiving an EAP-Message attribute
   that it does not understand MUST return an Access-Reject.

   Access-Challenge, Access-Accept, or Access-Reject packets including
   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 EAP packets, 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.3.  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-
   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.



Aboba & Calhoun               Informational                    [Page 14]


INTERNET-DRAFT                RADIUS & EAP               11 January 2003


   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)

   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 is
   calculated and inserted in the packet before the Response
   authenticator is calculated.




Aboba & Calhoun               Informational                    [Page 15]


INTERNET-DRAFT                RADIUS & EAP               11 January 2003


   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.

   RADIUS over IPsec, defined in [RFC3162] will eventually make this
   attribute obsolete, so it should be considered an interim measure.

3.4.  Table of Attributes

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

Request  Accept  Reject  Challenge   #    Attribute
0        0       0-1     0           75   Password-Retry
0+       0+      0+      0+          79   EAP-Message [Note 1]
0-1      0-1     0-1     0-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-
authenticator.  If any packet type contains an EAP-Message attribute it
MUST also contain a Message-authenticator.

The following table defines the above table entries.

0     This attribute MUST NOT be present
0+    Zero or more instances of this attribute MAY be present.
0-1   Zero or one instance of this attribute MAY be present.
1     Exactly one instance of this attribute MUST be present.

4.  Security Considerations

The attributes other than Message-authenticator and EAP-Message in this
document have no additional security considerations beyond those already
identified in [RFC2865].

4.1.  Message-authenticator Security

Access-Request packets with a User-Password establish the identity of
both the user and the NAS sending the Access-Request, because of the way



Aboba & Calhoun               Informational                    [Page 16]


INTERNET-DRAFT                RADIUS & EAP               11 January 2003


the shared secret between NAS and RADIUS server is used.  Access-Request
packets with CHAP-Password or EAP-Message do not have a User-Password
attribute, so the Message-authenticator attribute should be used in
access-request packets that do not have a User- Password, in order to
establish the identity of the NAS sending the request.

Note that the Message-authenticator attribute may be subjected to an
offline dictionary attack in order to recover the RADIUS shared secret.
As noted in [RFC2685]:

   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.

4.2.  EAP Security

Since the purpose of EAP is to provide enhanced security for
authentication, it is critical that RADIUS support for EAP be secure.
Vulnerabilities include:

   Separation of EAP server and authenticator
   Dictionary attacks
   Known plaintext attacks
   Replay protection
   Connection hijacking
   Man in the middle attacks
   Multiple databases
   Negotiation attacks

4.2.1.  Separation of EAP server and authenticator

It is possible for the EAP endpoints to mutually authenticate, negotiate
a ciphersuite, and derive a session key for use in a ciphersuite.  This
does not present an issue on the peer, since the peer and EAP client
reside on the same machine; all that is required is for the EAP client
module to pass the session key to the 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 backend 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.  Firstly, mutual
authentication will occur between the peer and the EAP server, not
between the peer and the authenticator. This means that it is not
possible for the peer to validate the identity of the NAS or tunnel
server that it is speaking to, using EAP alone.



Aboba & Calhoun               Informational                    [Page 17]


INTERNET-DRAFT                RADIUS & EAP               11 January 2003


As described earlier, when EAP/RADIUS is used to encapsulate EAP
packets, the Message-authenticator attribute is required in EAP/RADIUS
Access-Requests sent from the NAS or tunnel server to the RADIUS server.
Since the Message-authenticator attribute involves a HMAC-MD5 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.  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.  Moreover, EAP packets sent via methods that contain
their own integrity protection cannot be successfully modified by a
rogue NAS or tunnel server.

The second issue that arises in the case of an EAP server and
authenticator residing on different machines is that a three way key
handshake needs to carried out between the peer, the NAS and the RADIUS
server. The specification of this handshake is outside the scope of this
document.

4.2.2.  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 mitigated by
employing IPsec ESP with non-null transform in order to encrypt the
RADIUS conversation, as described in [RFC3162].

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




Aboba & Calhoun               Informational                    [Page 18]


INTERNET-DRAFT                RADIUS & EAP               11 January 2003


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 may be included within
RADIUS/EAP conversations.

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 [RFC3162].  In addition, the same
RADIUS shared secret MUST NOT used for both EAP and PAP authentication.

4.2.4.  Replay protection

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.

Replay protection for RADIUS authentication and accounting can be
provided by enabling IPsec replay protection with RADIUS, as described
in [RFC3162].

4.2.5.  Connection hijacking

In this form of attack, the attacker attempts to inject packets into the
conversation between the NAS and the RADIUS server, or between the
RADIUS server and the backend security server. RADIUS does not support
encryption, and as described in [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 EAP/RADIUS packets MUST be authenticated using the
Message-authenticator attribute, as described previously. If stronger
authentication and integrity protection is required, or replay
protection or confidentiality is desired, then RADIUS over IPsec



Aboba & Calhoun               Informational                    [Page 19]


INTERNET-DRAFT                RADIUS & EAP               11 January 2003


[RFC3162] should be used.

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

4.2.7.  Multiple databases

In many cases a backend security server will be deployed along with a
RADIUS server in order to provide EAP services. Unless the backend
security server also functions as a RADIUS server, two separate user
databases will exist, each containing information about the security
requirements for the user. This represents a weakness, since security
may be compromised by a successful attack on either of the servers, or
their backend databases. With multiple user databases, adding a new user
may require multiple operations, increasing the chances for error.  The
problems are further magnified in the case where user information is
also being kept in an LDAP server. In this case, three stores of user
information may exist.

In order to address these threats, consolidation of databases is
recommended.  This can be achieved by having both the RADIUS server and
backend security server store information in the same backend database;
by having the backend security server provide a full RADIUS
implementation; or by consolidating both the backend security server and
the RADIUS server onto the same machine.

4.2.8.  Negotiation attacks

In a negotiation attack, a rogue NAS, tunnel server, RADIUS proxy or
RADIUS server causes the authenticating peer to choose a less secure
authentication method so as to make it easier to obtain the user's
password. For example, a session that would normally be authenticated
with EAP would instead authenticated via CHAP or PAP; alternatively, a
connection that would normally be authenticated via one EAP type occurs
via a less secure EAP type, such as MD5. The threat posed by rogue
devices, once thought to be remote, has gained currency given
compromises of telephone company switching systems, such as those
described in [Masters].

Protection against negotiation attacks requires the elimination of
downward negotiations. This can be achieved via implementation of per-
connection policy on the part of the authenticating peer, and per-user
policy on the part of the RADIUS server.  For the authenticating peer,
authentication policy should be set on a per-connection basis. Per-



Aboba & Calhoun               Informational                    [Page 20]


INTERNET-DRAFT                RADIUS & EAP               11 January 2003


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 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 user is
required to authenticate with EAP until the user's identity is known.
For example, for shared-uses NASes it is possible for one reseller to
implement EAP while another does not. Alternatively, some users might be
authenticated locally by the NAS while other users are authenticated via
RADIUS. In such cases, if any users 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
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



Aboba & Calhoun               Informational                    [Page 21]


INTERNET-DRAFT                RADIUS & EAP               11 January 2003


same user connecting at another location (and encountering an EAP-
incapable proxy) might be consistently disconnected.

5.  Normative references

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

[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.]

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

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

[RFC2866]      Rigney, C., "RADIUS Accounting", RFC 2866, June 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.

6.  Informative references

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

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

[RFC2486]      Beadles, M., Aboba, B., "The Network Access Identifier",
               RFC 2486, January 1999.




Aboba & Calhoun               Informational                    [Page 22]


INTERNET-DRAFT                RADIUS & EAP               11 January 2003


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

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

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

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








































Aboba & Calhoun               Informational                    [Page 23]


INTERNET-DRAFT                RADIUS & EAP               11 January 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 24]


INTERNET-DRAFT                RADIUS & EAP               11 January 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 ->



Aboba & Calhoun               Informational                    [Page 25]


INTERNET-DRAFT                RADIUS & EAP               11 January 2003


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

In the case where the authenticating peer attempts to authenticate the
NAS, and this is supported by the NAS and RADIUS server, 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-Challenge/
                                                 EAP-Message/
                                                 EAP-Response/
                                                 Response, MD5
                        <- EAP-Response/
                         Response, MD5
EAP-Success ->
                        RADIUS Access-Request/
                        EAP-Message/
                        EAP-Success ->
                                                 <- RADIUS
                                                 Access-Accept

In the case where the authenticating peer attempts to authenticate the
NAS, and this is supported by the NAS but not the RADIUS server, the
conversation would appear as follows:

Authenticating Peer     NAS                    RADIUS Server
-------------------     ---                    -------------
EAP-Request/
Challenge, MD5 ->
                        RADIUS Access-Request/
                        EAP-Message/
                        EAP-Request/



Aboba & Calhoun               Informational                    [Page 26]


INTERNET-DRAFT                RADIUS & EAP               11 January 2003


                        Challenge, MD5 ->
                                                 <- RADIUS
                                                 Access-Reject/
                                                 EAP-Message/
                                                 EAP-Response/
                                                 NAK (no alternative)

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

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/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

In the case where the client fails EAP authentication, and an error



Aboba & Calhoun               Informational                    [Page 27]


INTERNET-DRAFT                RADIUS & EAP               11 January 2003


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/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/
                        Notification ->
                                                 <- RADIUS
                                                 Access-Reject/
                                                 EAP-Message/EAP-Failure
                        <- EAP-Failure
                        (client disconnected)




Aboba & Calhoun               Informational                    [Page 28]


INTERNET-DRAFT                RADIUS & EAP               11 January 2003


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/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)














Aboba & Calhoun               Informational                    [Page 29]


INTERNET-DRAFT                RADIUS & EAP               11 January 2003


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
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 30]


INTERNET-DRAFT                RADIUS & EAP               11 January 2003


Acknowledgments

Thanks also to Dave Dawson and Karl Fox of Ascend, Glen Zorn of Cisco
Systems and Ashwin Palekar, Tim Moore and Narendra Gidwani of Microsoft
for useful discussions of this problem space.

Author's Addresses

Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

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

Pat R. Calhoun
Black Storm Networks
250 Cambridge Avenue, Suite 200
Palo Alto, California, 94306
USA

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

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



Aboba & Calhoun               Informational                    [Page 31]


INTERNET-DRAFT                RADIUS & EAP               11 January 2003


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-06.txt>, and
expires August 24, 2003.








































Aboba & Calhoun               Informational                    [Page 32]


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