RADIUS Working Group                                       Pat Calhoun
INTERNET-DRAFT                                US Robotics Access Corp.
Updates: RFC 2058                                      Allan C. Rubens
Category: Standards Track                          Merit Network, Inc.
<draft-ietf-radius-eap-02.txt>                           Bernard Aboba
May 22, 1997                                                 Microsoft


         Extensible Authentication Protocol Support in RADIUS


1.  Status of this Memo

This document is an Internet-Draft.  Internet-Drafts are working docu-
ments  of  the  Internet Engineering Task Force (IETF), its areas, and
its working groups.  Note that other groups may also distribute  work-
ing 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.''

To learn the current status of any Internet-Draft,  please  check  the
``1id-abstracts.txt''  listing contained in the Internet-Drafts Shadow
Directories  on  ds.internic.net  (US   East   Coast),   nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).

The distribution of this memo is unlimited.  It is  filed  as  <draft-
ietf-radius-eap-02.txt>,  and   expires  January  1, 1998. Please send
comments to the authors.


2.  Abstract

The Extensible Authentication Protocol (EAP) is a PPP  extension  that
provides  support  for  additional  authentication methods within PPP.
This document describes how the EAP-Message and  Signature  attributes
may be used for providing EAP support within RADIUS.


3.  Introduction

The Extensible Authentication Protocol (EAP), described in  [1],  pro-
vides  a  standard  mechanism for support of additional authentication
methods within PPP. Through the use of EAP, support for  a  number  of
authentication  schemes may be added, including smart cards, Kerberos,
Public Key, One Time Passwords, and others. In order  to  provide  for
support of EAP within RADIUS, two new attributes, EAP-Message and Sig-
nature, were introduced as RADIUS extensions  in  [4].  This  document
describes  how these new attributes may be used for providing EAP sup-
port within RADIUS.

In the proposed scheme, the RADIUS server is used to  shuttle  RADIUS-



Calhoun, Rubens & Aboba                                       [Page 1]





INTERNET-DRAFT                                            May 22, 1997


encapsulated  EAP  Packets  between  the  NAS  and  a backend security
server. While the conversation between  the  RADIUS  server   and  the
backend  security server will typically occur using a proprietary pro-
tocol developed by the backend security server vendor, it is also pos-
sible  to  use  RADIUS-encapsulated EAP via the EAP-Message attribute.
This has the advantage of allowing the RADIUS server  to  support  EAP
without  the  need for authentication-specific code, which can instead
reside on a backend security server.


3.1.  Requirements language

This specification uses the same words as [6] for defining the  signi-
ficance of each particular requirement.  These words are:


MUST      This word, or the adjectives "REQUIRED"  or  "SHALL",  means
          that  the  definition  is  an  absolute  requirement  of the
          specification.

MUST NOT  This phrase, or the  phrase  "SHALL  NOT",  means  that  the
          definition is an absolute prohibition of the specification.

SHOULD    This word, or the adjective "RECOMMENDED", means that  there
          may  exist  valid  reasons  in  particular  circumstances to
          ignore a particular item, but the full implications must  be
          understood and carefully weighed before choosing a different
          course.

SHOULD NOTThis phrase means that there may exist valid reasons in par-
          ticular   circumstances  when  the  particular  behavior  is
          acceptable or even useful, but the full implications  should
          be  understood  and the case carefully weighed before imple-
          menting any behavior described with this label.

MAY       This word, or the adjective "AL",  means  that  an  item  is
          truly  optional.   One vendor may choose to include the item
          because a particular marketplace requires it or because  the
          vendor feels that it enhances the product while another ven-
          dor may omit the same item.  An  implementation  which  does
          not  include a particular option MUST be prepared to intero-
          perate with another implementation which  does  include  the
          option,  though  perhaps  with reduced functionality. In the
          same vein an implementation which does include a  particular
          option  MUST be prepared to interoperate with another imple-
          mentation which does  not  include  the  option.(except,  of
          course, for the feature the option provides)

An implementation is not compliant if it fails to satisfy one or  more
of  the must or must not requirements for the protocols it implements.
An implementation that satisfies all the must, must  not,  should  and
should  not requirements for its protocols is said to be "uncondition-
ally compliant"; one that satisfies all the must and must not require-
ments  but  not  all  the  should  or  should not requirements for its



Calhoun, Rubens & Aboba                                       [Page 2]





INTERNET-DRAFT                                            May 22, 1997


protocols is said to be "conditionally compliant."


4.  Protocol overview

The EAP conversation between the authenticating  peer  (dial-in  user)
and  the  NAS  begins with the negotiation of EAP within LCP. Once EAP
has been negotiated, the NAS will typically send to the RADIUS  server
a  RADIUS  Access-Request  packet  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). NAS-Port SHOULD be included in
the attributes issued by the NAS in the Access-Request packet;  either
NAS-Identifier or NAS-IP-Address MUST be included.

If the RADIUS server supports EAP, it MUST  respond  with  an  Access-
Challenge  packet  containing  an EAP-Message attribute. If the RADIUS
server does not support EAP, it MUST respond with an Access-Reject.

The EAP-Message attribute includes an encapsulated EAP packet which is
then  passed on to the authenticating peer. The Access-Challenge typi-
cally will contain an  EAP-Message  attribute  encapsulating  an  EAP-
Request/Identity  message,  requesting  the  dial-in  user to identify
themself. The NAS will  then  respond  with  a  RADIUS  Access-Request
packet  containing  an  EAP-Message  attribute  encapsulating  an EAP-
Response. The conversation continues until  either  a  RADIUS  Access-
Reject or Access-Accept packet is received.

Reception of a RADIUS Access-Reject packet, with or  without  an  EAP-
Message  attribute  encapsulating  EAP-Failure, MUST result in the NAS
issuing an LCP Terminate Request to the authenticating peer.  A RADIUS
Access-Accept  packet with an EAP-Message attribute encapsulating EAP-
Success  successfully  ends  the  authentication  phase.  The   RADIUS
Access-Accept/EAP-Message/EAP-Success  packet  MUST contain all of the
expected attributes which are currently returned in  an  Access-Accept
packet.

The above scenario creates a situation in which the NAS never needs to
manipulate  an  EAP  packet.  An alternative may be used in situations
where an EAP-Request/Identity message will always be sent by  the  NAS
to  the authenticating peer. This involves having the NAS send an EAP-
Request/Identity message to the authenticating  peer,  and  forwarding
the  EAP-Response/Identity  packet  to  the  RADIUS server in the EAP-
Message attribute  of  a  RADIUS  Access-Request  packet.  While  this
approach  will  save  a round-trip, it cannot be universally employed.
There are circumstances in which the user's identity may not be needed
(such  as  when  authentication  and  accounting  is  handled based on
Called-Station-Id  or  Calling-Station-Id),  and  therefore  an   EAP-
Request/Identity  packet  may  not necessarily be issued by the NAS to
the authenticating peer.

Unless the NAS interprets the EAP-Response/Identity packet returned by
the  authenticating  peer, it will not have access to the user's iden-
tity. Therefore, the RADIUS Server SHOULD return the  user's  identity
by  inserting  it  in  the  User-Name  attribute of subsequent Access-



Calhoun, Rubens & Aboba                                       [Page 3]





INTERNET-DRAFT                                            May 22, 1997


Challenge and Access-Accept  packets.  Without  the  user's  identity,
accounting and billing becomes very difficult to manage.

For proxied RADIUS requests there are two methods of  processing.   If
the  domain  is  determined based on the 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 peer MUST be proxied to
the final authentication server.

For proxied RADIUS requests, the  NAS  may  receive  an  Access-Reject
packet  in  response  to  its Access-Request/EAP-Identity packet. This
would occur if the message was proxied to a RADIUS Server  which  does
not  support the EAP-Message extension. On receiving an Access-Reject,
the NAS MUST send an LCP Terminate Request to the authenticating peer,
and disconnect.

The NAS is not responsible for the retransmission of any AP  messages.
The  authenticating peer and the RADIUS Server are responsible for any
retransmissions.

The example below shows the conversation  between  the  authenticating
peer,  NAS,  and  RADIUS  server,  for the case of a One Time Password
(OTP) authentication. OTP is  used  only  for  illustrative  purposes;
other  authentication  protocols  could  also have been used, although
they might show somewhat different behavior.


Authenticating Peer     NAS                      RADIUS Server
-------------------     ---                      -------------

                        <- PPP LCP Request-EAP
                        auth
PPP LCP ACK-EAP
auth ->
                        RADIUS
                        Access-Request/
                        EAP-Message/Start ->
                                                 <- RADIUS
                                                 Access-Challenge/
                                                 EAP-Message/Identity
                        <- PPP EAP-Request/
                        Identity
PPP EAP-Response/
Identity (MyID) ->
                        RADIUS
                        Access-Request/
                        EAP-Message/
                        EAP-Response/
                        (MyID) ->
                                                  <- RADIUS
                                                  Access-Challenge/
                                                  EAP-Message/EAP-Request



Calhoun, Rubens & Aboba                                       [Page 4]





INTERNET-DRAFT                                            May 22, 1997


                                                  OTP/OTP Challenge
                        <- PPP EAP-Request/
                        OTP/OTP Challenge
PPP EAP-Response/
OTP, OTPpw ->
                        RADIUS
                        Access-Request/
                        EAP-Message/
                        EAP-Response/
                        OTP, OTPpw ->
                                                   <- RADIUS
                                                   Access-Accept/
                                                   EAP-Message/EAP-Success
                                                   (other attributes)
                        <- PPP EAP-Success
PPP Authentication
Phase complete,
NCP Phase starts

In the case where the  NAS  sends  the  authenticating  peer  an  EAP-
Request/Identity  packet  without first sending an EAP-Start packet to
the RADIUS server,  the conversation would appear as follows:

Authenticating Peer     NAS                      RADIUS Server
-------------------     ---                      -------------

                        <- PPP LCP Request-EAP
                        auth
PPP LCP ACK-EAP
auth ->
                        <- PPP EAP-Request/
                        Identity
PPP EAP-Response/
Identity (MyID) ->
                        RADIUS
                        Access-Request/
                        EAP-Message/
                        EAP-Response/
                        (MyID) ->
                                                  <- RADIUS
                                                  Access-Challenge/
                                                  EAP-Message/EAP-Request
                                                  OTP/OTP Challenge
                        <- PPP EAP-Request/
                        OTP/OTP Challenge
PPP EAP-Response/
OTP, OTPpw ->
                        RADIUS
                        Access-Request/
                        EAP-Message/
                        EAP-Response/
                        OTP, OTPpw ->
                                                   <- RADIUS
                                                   Access-Accept/



Calhoun, Rubens & Aboba                                       [Page 5]





INTERNET-DRAFT                                            May 22, 1997


                                                   EAP-Message/EAP-Success
                                                   (other attributes)
                        <- PPP EAP-Success
PPP Authentication
Phase complete,
NCP Phase starts

In the case where the client fails EAP authentication,  the  conversa-
tion would appear as follows:


Autheticating Peer     NAS                      RADIUS Server
-------------------     ---                      -------------

                        <- PPP LCP Request-EAP
                        auth
PPP LCP ACK-EAP
auth ->
                        Access-Request/
                        EAP-Message/Start ->
                                                 <- RADIUS
                                                 Access-Challenge/
                                                 EAP-Message/Identity
                        <- PPP EAP-Request/
                        Identity
PPP EAP-Response/
Identity (MyID) ->
                        RADIUS
                        Access-Request/
                        EAP-Message/
                        EAP-Response/
                        (MyID) ->
                                                  <- RADIUS
                                                  Access-Challenge/
                                                  EAP-Message/EAP-Request
                                                  OTP/OTP Challenge
                        <- PPP EAP-Request/
                        OTP/OTP Challenge
PPP EAP-Response/
OTP, OTPpw ->
                        RADIUS
                        Access-Request/
                        EAP-Message/
                        EAP-Response/
                        OTP, OTPpw ->
                                                   <- RADIUS
                                                   Access-Reject/
                                                   EAP-Message/EAP-Failure
                        <- PPP EAP-Failure
                        (client disconnected)

In the case that the RADIUS server or  proxy  does  not  support  EAP-
Message, the conversation would appear as follows:




Calhoun, Rubens & Aboba                                       [Page 6]





INTERNET-DRAFT                                            May 22, 1997


Authenticating Peer     NAS                         RADIUS Server
-------------------     ---                         -------------

                        <- PPP LCP Request-EAP
                        auth
PPP LCP ACK-EAP
auth ->
                        RADIUS
                        Access-Request/
                        EAP-Message/Start ->
                                                    <- RADIUS
                                                    Access-Reject
                        <- PPP LCP Terminate
                        (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
-------------------     ---                         -------------

                        <- PPP LCP Request-EAP
                        auth
PPP LCP ACK-EAP
auth ->
                        RADIUS
                        Access-Request/
                        EAP-Message/Start ->
                                                    <- RADIUS
                                                    Access-Challenge/
                                                    EAP-Message/Identity
                        <- PPP EAP-Request/
                        Identity
PPP EAP-Response/
Identity
(MyID) ->
                        RADIUS
                        Access-Request/
                        EAP-Message/EAP-Response/
                        (MyID) ->
                                                    <- RADIUS
                                                    Access-Reject
                                                    (proxied from remote
                                                    RADIUS Server)
                        <- PPP LCP Terminate
                        (User Disconnected)

In the case where 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
-------------------     ---                         -------------



Calhoun, Rubens & Aboba                                       [Page 7]





INTERNET-DRAFT                                            May 22, 1997


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


5.  Alternative uses

Currently the conversation between the backend security server and the
RADIUS  server  is 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.




Calhoun, Rubens & Aboba                                       [Page 8]





INTERNET-DRAFT                                            May 22, 1997


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/EAP-Success  message
without  inclusion of the expected attributes currently returned in an
Access-Accept. This means that the RADIUS server MUST add these attri-
butes  prior  to  sending  an Access-Accept/EAP-Success message to the
NAS.


6.  Attributes


6.1.  EAP-Message

Description

   This attribute encapsulates Extensible Authentication Protocol  [1]
   packets  so  as  to allow the NAS to authenticate dial-in users via
   EAP without having to understand the protocol.

   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. The  RADIUS  Server
   may  return one or more EAP-Message attributes in Access-Challenge,
   Access-Accept and Access-Reject packets.

   Access-Request packets including one or more EAP-Message attributes
   MUST also contain a Signature attribute, described in [4], in order
   to provide for authentication of the shuttled EAP packets.  Access-
   Request packets including an EAP-Message attribute without a Signa-
   ture attribute SHOULD be silently discarded by the RADIUS server. A
   RADIUS  Server  supporting  EAP-Message  MUST calculate the correct
   value of the Signature and silently discard the packet if  it  does
   not  match  the  value  sent.   A RADIUS Server not supporting EAP-
   Message MUST return an Access-Reject  if  it  receives  an  Access-
   Reqeust  containing  an  EAP-Message  attribute.  A  RADIUS  Server
   receiving an EAP-Message attribute that it does not understand MUST
   return an Access-Reject.

A summary of the EAP-Message 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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |    Length     |            String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

   67 for EAP-Message

Length




Calhoun, Rubens & Aboba                                       [Page 9]





INTERNET-DRAFT                                            May 22, 1997


   >=3 (EAP packet enclosed)
   =2  (EAP-Start message)

String

   The String field includes EAP packets, as defined in [1]. If multi-
   ple  EAP-Message  attributes  are  present in a packet their values
   should be concatenated; this allows EAP  packets  longer  than  253
   octets to be passed by RADIUS.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Code     | Identifier    |          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   /                                                               /
   /                        Data                                   /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


7.  Security considerations

Since the purpose of EAP is  to  provide  enhanced  security  for  PPP
authentication,  it is critical that RADIUS support for EAP be secure.
In particular, protection  must  be  provided  against  the  following
attacks:

   Connection hijacking
   Man in the middle attacks
   Multiple databases
   Negotiation attacks


7.1.  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 [2], only Access-Reply and Access-
Challenge packets are authenticated.

In order to provide for authentication  of  all  packets  in  the  EAP
exchange, all Access-Request/EAP-Message packets MUST be authenticated
using the Signature attribute, as described in [4].  The RADIUS server
MUST  silently  discard all Access-Request packets failing authentica-
tion.


7.2.  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 con-
trol  of  a RADIUS proxy will be able to modify EAP packets in transit



Calhoun, Rubens & Aboba                                      [Page 10]





INTERNET-DRAFT                                            May 22, 1997


without fear of detection.

This represents a weakness of RADIUS which can be remedied  by  imple-
menting RADIUS on top of IP Security.


7.3.  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  data-
base;  by  having  the  backend  security server provide a full RADIUS
implementation; or by consolidating both the backend  security  server
and the RADIUS server onto the same machine.


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

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

For the authenticating peer, authentication policy should be set on  a
per-connection  basis.  Per-connection policy allows an authenticating
peer to negotiate EAP when calling one service, while negotiating CHAP
for another service, even if both services are accessible via the same
phone number.

With per-connection policy, an authenticating peer will  only  attempt
to  negotiate EAP for a session in which EAP support is expected. As a



Calhoun, Rubens & Aboba                                      [Page 11]





INTERNET-DRAFT                                            May 22, 1997


result, there is a presumption that an authenticating  peer  selecting
EAP  requires  that level of security. If it cannot be provided, it is
likely that there is some kind of misconfiguration, or even  that  the
authenticating peer is contacting the wrong server. Should the NAS not
be able to negotiate EAP, or should the EAP-Request sent by the NAS be
of a different EAP type than what is expected, the authenticating peer
MUST disconnect. An authenticating peer expecting EAP to be negotiated
for a session MUST NOT negotiate CHAP or PAP.

For a NAS, it may not be possible  to  determine  whether  a  user  is
required  to authenticate with EAP until the user's identity is known.
For example, for shared-uses NASes it is possible for one reseller  to
implement  EAP  while another does not. In such cases, if any users of
the NAS MUST do EAP, then the NAS MUST attempt to  negotiate  EAP  for
every  call. This avoids forcing an EAP-capable client to do more than
one authentication, which weakens security.

If CHAP is negotiated, the NAS  will  pass  the  User-Name  and  CHAP-
Password  attributes to the RADIUS Server in an Access-Request packet.
If the user is not required to use EAP, then the  RADIUS  Server  will
respond  with an Access-Accept or Access-Reject packet as appropriate.
However, if CHAP has been negotiated but EAP is required,  the  RADIUS
server  MUST  respond  with  an  Access-Reject, rather than an Access-
Challenge/EAP-Message/EAP-Request packet. The authenticating peer MUST
refuse  to  renegotiate  authentication,  even if the renegotiation is
from CHAP to EAP.

If EAP is negotiated but is not  supported  by  the  RADIUS  proxy  or
server,  then  the server or proxy MUST respond with an Access-Reject.
In these cases, the NAS MUST send an LCP-Terminate and disconnect  the
user.  This  is  the correct behavior since the authenticating peer is
expecting EAP to be negotiated, and that expectation  cannot  be  ful-
filled.  An EAP-capable authenticating peer MUST refuse to renegotiate
the authentication protocol if  EAP  had  initially  been  negotiated.
Note  that  problems  with  a non-EAP capable RADIUS proxy could prove
difficult to diagnose, since a user dialing in from one location (with
an  EAP-capable  proxy) might be able to successfully authenticate via
EAP, while the same user dialing into another location (and encounter-
ing an EAP-incapable proxy) might be consistently disconnected.


8.  Acknowledgments

Thanks to Dave Dawson and Karl Fox of Ascend, and Glen Zorn and Naren-
dra Gidwani of Microsoft for useful discussions of this problem space.


9.  References

[1] L. J. Blunk, J. R.  Vollbrecht.   "PPP  Extensible  Authentication
Protocol  (EAP)." Work in progress, draft-ietf-pppext-eap-auth-02.txt,
Merit Network, Inc., June, 1996.

[2]   C.  Rigney,  A.  Rubens,  W.  Simpson,  S.   Willens.    "Remote



Calhoun, Rubens & Aboba                                      [Page 12]





INTERNET-DRAFT                                            May 22, 1997


Authentication  Dial  In User Service (RADIUS)." RFC 2058, Livingston,
Merit, Daydreamer, January, 1997.

[3]  C. Rigney.  "RADIUS Accounting." RFC 2059,  Livingston,  January,
1997.

[4] C. Rigney, W. Willats.  "RADIUS  Extensions."  Work  in  progress,
draft-ietf-radius-ext-00.txt, Livingston, January, 1997.

[5] R. Rivest, S. Dusse.   "The  MD5  Message-Digest  Algorithm."  RFC
1321,  MIT  Laboratory  for  Computer Science, RSA Data Security Inc.,
April 1992.

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

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


10.  Authors' Addresses

Pat R. Calhoun
US Robotics Access Corp.
8100 N. McCormick Blvd.
Skokie, IL 60076-2999

Phone: 847-342-6898
EMail: pcalhoun@usr.com

Allan C. Rubens
Merit Network, Inc.
4251 Plymouth Rd.
Ann Arbor, MI 48105-2785

Phone: 313-647-0417
EMail: acr@merit.edu

Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

Phone: 206-936-6605
EMail: bernarda@microsoft.com












Calhoun, Rubens & Aboba                                      [Page 13]