[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03                                                   
INTERNET DRAFT                                             Pat R. Calhoun
Category: Standards Track                          Sun Microsystems, Inc.
Title: draft-calhoun-diameter-eap-01.txt                     Allan Rubens
Date: March 1998                                      Merit Networks Inc.
                                                            Bernard Aboba
                                                    Microsoft Corporation



                                       DIAMETER
                    Extensible Authentication Protocol Extensions
                         <draft-calhoun-diameter-eap-01.txt>


Status of this Memo

   This  document  is  an  Internet-Draft.  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.
   Internet-Drafts  may  be  updated,  replaced,  or  obsoleted  by other
   documents at any time.  It is not appropriate to  use  Internet-Drafts
   as  reference  material  or  to  cite  them  other than as a ``working
   draft'' or ``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,  nic.nordu.net,  ftp.nisc.sri.com,  or
   munnari.oz.au.

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


Table of Contents

      1.0    Introduction
      1.1    Definitions
      2.0    Protocol overview
      2.1    Example of an OTP Authentication
      2.2    NAS Initiated EAP Authentication
      2.3    Example of failed EAP Authentication
      2.4    Example of DIAMETER not supporting EAP
      2.5    Example of DIAMETER Proxy not supporting EAP


Calhoun, Rubens, Aboba          expires September 1998           [Page 1]


INTERNET DRAFT                                                 March 1998


      2.6    Example of PPP Client not supporting EAP
      3.0    Alternative uses
      4.0    Command Name and Command Code
      5.0    Command Meanings
      5.1    DIAMETER-EAP-Request
      5.2    DIAMETER-EAP-Response
      5.3    DIAMETER-EAP-Ack
      5.4    DIAMETER-EAP-Reject
      6.0    Attribute Name and Attribute Code
      7.0    Attribute Meanings
      7.1    EAP-Packet
      8.0    Acknowledgments
      9.0    References
      10.0   Authors' Addresses


1.0 Introduction

   The  Extensible  Authentication  Protocol  (EAP),  described  in  [1],
   provides 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 token cards, Kerberos,
   Public Key, One Time Passwords, and others. In order  to  provide  for
   support  of  EAP  within DIAMETER, two new attributes, EAP-Message and
   Signature,  were  introduced  as  DIAMETER  extensions  in  [5].  This
   document  describes how these new attributes may be used for providing
   EAP support within DIAMETER.

   The scheme described here is similar to that proposed in [2], in  that
   the  DIAMETER  server  is  used  to  shuttle DIAMETER-encapsulated EAP
   Packets between the NAS and  a  backend  security  server.  While  the
   conversation  between  the  DIAMETER  server  and the backend security
   server will typically occur using a proprietary protocol developed  by
   the  backend  security  server  vendor,  it  is  also  possible to use
   DIAMETER-encapsulated EAP via the EAP-Message attribute. This has  the
   advantage  of  allowing the DIAMETER server to support EAP without the
   need for authentication- specific code, which can instead reside on  a
   backend security server.


   This original document was named Enhanced RADIUS and  was  changed  at
   the  request  of  the  WG  since  this  protocol is different from the
   former.

   This document describes a management  protocol  used  between  Network
   Access Servers and DIAMETER Servers for authentication, authorization,
   and accounting of dial-up users. A considerable amount of  effort  was
   put  into the design of this protocol to ensure that an implementation
   could support both DIAMETER and RADIUS at the same time.



Calhoun, Rubens, Aboba          expires September 1998           [Page 2]


INTERNET DRAFT                                                 March 1998






















































Calhoun, Rubens, Aboba          expires September 1998           [Page 3]


INTERNET DRAFT                                                 March 1998


1.1  Definitions

   In this document, several words are used to signify  the  requirements
   of the specification.  These words are often capitalized.

   MUST      This word, or the adjective "required", means that the
             definition is an absolute requirement of the
             specification.

   MUST NOT  This phrase 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 this item, but the full implications must be
             understood and carefully weighed before choosing a
             different course.

   MAY       This word, or the adjective "optional", means that this
             item is one of an allowed set of alternatives.  An
             implementation which does not include this option MUST
             be prepared to interoperate with another implementation
             which does include the option.


2.0 Protocol overview

   The EAP conversation between  the  authenticating  peer  and  the  NAS
   begins  with  the  negotiation  of  EAP  within LCP. Once EAP has been
   negotiated, the NAS will typically  send  to  the  DIAMETER  server  a
   DIAMETER  Message  packet  containing the DIAMETER-EAP-Request Command
   signifying  an  EAP-Start.  EAP-Start  is  indicated  by  sending   an
   DIAMETER-EAP-Request  Command  with  an  EAP-Packet  attribute  with a
   length of 7 (no data). The Port number  and  NAS  Identifier  MUST  be
   included  in  the  attributes  issued  by the NAS in the DIAMETER-EAP-
   Request packet.

   If the DIAMETER server supports EAP, it MUST respond with an DIAMETER-
   EAP-Response packet containing an EAP-Packet attribute. The EAP-Packet
   attribute includes an encapsulated EAP packet which is then passed  on
   to  the  authenticating peer. The DIAMETER-EAP-Response typically will
   contain an EAP-Packet attribute encapsulating an  EAP-Request/Identity
   message,  requesting  the  authenticating peer to identify itself. The
   NAS will then respond with a DIAMETER-EAP-Request packet containing an
   EAP-Packet   attribute   encapsulating   an   EAP-Response,  etc.  The
   conversation continues until either a  DIAMETER-EAP-Reject  packet  is
   received  (with  an  EAP-Packet  attribute  encapsulating EAP-Failure)
   which results in the NAS disconnecting the user, or a DIAMETER-EAP-Ack
   packet  is  received  (with an EAP-Packet attribute encapsulating EAP-
   Success) successfully ending the authentication phase. Note that if  a


Calhoun, Rubens, Aboba          expires September 1998           [Page 4]


INTERNET DRAFT                                                 March 1998


   DIAMETER-EAP-Reject packet with an EAP-Packet attribute  encapsulating
   EAP-Failure is received from the DIAMETER Server, the NAS SHOULD issue
   an LCP Terminate Request to the authenticating peer.

   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 DIAMETER server in the EAP-
   Packet attribute of a DIAMETER-EAP-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 the calling or
   called phone number), 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
   identity. Therefore, the DIAMETER  Server  SHOULD  return  the  user's
   identity  by  inserting  it  in  the User-Name attribute of subsequent
   DIAMETER-EAP-Response and DIAMETER-EAP-Ack packets. Without the user's
   identity, accounting and billing becomes very difficult to manage.

   In cases where a  backup  DIAMETER  servers  is  available,  were  the
   primary  server  to  fail  at any time during the EAP conversation, it
   would be desirable for the NAS to be able to redirect the conversation
   to  an alternate DIAMETER server. However, for the backup server to be
   able to pick up the conversation, it must be provided with  the  state
   of the EAP conversation prior to the interruption.

   This can be accomplished by having  the  DIAMETER-EAP-Request  include
   the  series of EAP-Packet attributes representing the previous history
   of the EAP conversation. Similarly, the DIAMETER-EAP-Response returned
   by  the  DIAMETER  server  must  also  include all previous EAP-Packet
   attributes. The sequence number field in the EAP-Packet attribute MUST
   be used in order to determine which attribute is to be processed.  The
   attribute  with  the  highest  sequence  number  is  the  most  recent
   attribute.

   The DIAMETER-EAP-Ack/EAP-Packet/EAP-Success packet MUST contain all of
   the  expected   attributes  which are currently returned in a DIAMETER
   Authentication-Success packet.

   For proxied DIAMETER requests there are two methods of processing.  If
   the  domain  is  determined  based on the DNIS the DIAMETER Server may
   proxy the initial DIAMETER-EAP-Request/EAP-Start.  If  the  domain  is
   determined  based  on  the  user's identity, the local DIAMETER Server
   MUST respond with  a  DIAMETER-EAP-Response/EAP-Identity  packet.  The
   response  from  the  authenticating  peer MUST be proxied to the final


Calhoun, Rubens, Aboba          expires September 1998           [Page 5]


INTERNET DRAFT                                                 March 1998


   authentication server.

   For  proxied  DIAMETER  requests,  the  NAS  may  receive  an  Command
   Unrecongnized  packet  in  response  to  its DIAMETER-EAP-Request/EAP-
   Identity packet.  This would occur if the message  was  proxied  to  a
   DIAMETER Server which does not support the DIAMETER EAP extensions. At
   this point, the NAS MUST re-open LCP with the authenticating peer  and
   request either CHAP or PAP as the authentication protocol.

   If the NAS is unable to negotiate EAP with  the  authenticating  peer,
   what happens next is a matter of policy. In circumstances where EAP is
   required of all users accessing the NAS, the NAS MUST  disconnect  the
   user. However, in circumstances where EAP is mandatory for some users,
   and optional or not required for others, the decision cannot  be  made
   until  the  user's identity is ascertained. In this case, the NAS will
   negotiate another authentication method, such as CHAP, and  will  pass
   the  User-Name  and CHAP-Password attributes to the DIAMETER Server in
   an Authentication-Request message. If the user is not required to  use
   EAP,  then  the  DIAMETER  Server will respond with an Authentication-
   Success or  Authentication-Failure  packet  as  appropriate.  However,
   should  the  user  require  EAP, then the DIAMETER Server will respond
   with  an  DIAMETER-EAP-Response  packet   containing   an   EAP-Packet
   attribute.  The  EAP-Packet  attribute will either encapsulate an EAP-
   Request/Identity packet, or if the DIAMETER Server makes  use  of  the
   User-Name  attribute in the Authentication-Request, it may encapsulate
   an EAP challenge. On receiving the EAP-Packet attribute, the NAS  will
   either  attempt  to negotiate EAP if it had not done so previously, or
   if negotiation had previously  been  attempted  and  failed,  it  MUST
   disconnect the user.

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


2.1 Example of an OTP Authentication

   The example below shows the conversation  between  the  authenticating
   peer,  NAS,  and  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
   would show somewhat different behavior. For brevity,  the  history  of
   previous EAP messages (which will be transmitted in each DIAMETER-EAP-
   Request and DIAMETER-EAP-Response packet) has been left out.

    Authenticating Peer   NAS                      DIAMETER Server
    -------------------   ---                      ---------------

                          <- PPP LCP Request-EAP
                          auth


Calhoun, Rubens, Aboba          expires September 1998           [Page 6]


INTERNET DRAFT                                                 March 1998


    PPP LCP ACK-EAP
    auth ->
                          DIAMETER-
                          EAP-Request/
                          EAP-Packet/Start ->
                                                   <- DIAMETER-
                                                   EAP-Response/
                                                   EAP-Packet/Identity
                          <- PPP EAP-Request/
                          Identity
    PPP EAP-Response/
    Identity (MyID) ->
                          DIAMETER-
                          EAP-Request/
                          EAP-Packet/
                          EAP-Response/
                          (MyID) ->
                                                   <- DIAMETER-
                                                   EAP-Response/
                                                   EAP-Packet/EAP-Request
                                                   OTP/OTP Challenge
                          <- PPP EAP-Request/
                          OTP/OTP Challenge
    PPP EAP-Response/
    OTP, OTPpw ->
                          DIAMETER-
                          EAP-Request/
                          EAP-Packet/
                          EAP-Response/
                          OTP, OTPpw ->
                                                   <- DIAMETER-EAP-Ack/
                                                   EAP-Packet/EAP-Success
                                                   (other attributes)
                          <- PPP EAP-Success
    PPP Authentication
    Phase complete,
    NCP Phase starts


2.2 NAS Initiated EAP Authentication

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

    Authenticating Peer   NAS                      DIAMETER Server
    -------------------   ---                      ---------------


                          <- PPP LCP Request-EAP


Calhoun, Rubens, Aboba          expires September 1998           [Page 7]


INTERNET DRAFT                                                 March 1998


                          auth
    PPP LCP ACK-EAP
    auth ->
                          <- PPP EAP-Request/
                          Identity
    PPP EAP-Response/
    Identity (MyID) ->
                          DIAMETER-
                          EAP-Request/
                          EAP-Packet/
                          EAP-Response/
                          (MyID) ->
                                                   <- DIAMETER-
                                                   EAP-Response/
                                                   EAP-Packet/EAP-Request
                                                   OTP/OTP Challenge
                          <- PPP EAP-Request/
                          OTP/OTP Challenge
    PPP EAP-Response/
    OTP, OTPpw ->
                          DIAMETER-
                          EAP-Request/
                          EAP-Packet/
                          EAP-Response/
                          OTP, OTPpw ->
                                                   <- DIAMETER-EAP-Ack/
                                                   EAP-Packet/EAP-Success
                                                   (other attributes)
                          <- PPP EAP-Success
    PPP Authentication
    Phase complete,
    NCP Phase starts


2.3 Example of failed EAP Authentication

   In  the  case  where  the  client  fails   EAP   authentication,   the
   conversation would appear as follows:

    Authenticating Peer   NAS                      DIAMETER Server
    -------------------   ---                      ---------------

                          <- PPP LCP Request-EAP
                          auth
    PPP LCP ACK-EAP
    auth ->
                          DIAMETER-
                          EAP-Request/
                          EAP-Packet/Start ->
                                                   <- DIAMETER-


Calhoun, Rubens, Aboba          expires September 1998           [Page 8]


INTERNET DRAFT                                                 March 1998


                                                   EAP-Response/
                                                   EAP-Packet/Identity
                          <- PPP EAP-Request/
                          Identity
    PPP EAP-Response/
    Identity (MyID) ->
                          DIAMETER-
                          EAP-Request/
                          EAP-Packet/
                          EAP-Response/
                          (MyID) ->
                                                   <- DIAMETER-
                                                   EAP-Response/
                                                   EAP-Packet/EAP-Request
                                                   OTP/OTP Challenge
                          <- PPP EAP-Request/
                          OTP/OTP Challenge
    PPP EAP-Response/
    OTP, OTPpw ->
                          DIAMETER-
                          EAP-Request/
                          EAP-Packet/
                          EAP-Response/
                          OTP, OTPpw ->
                                                   <- DIAMETER-
                                                   EAP-Reject/
                                                   EAP-Packet/EAP-Failure
                          <- PPP EAP-Failure

                          <- LCP Terminate


2.4 Example of DIAMETER not supporting EAP

   In the case that the DIAMETER server or proxy  does  not  support  EAP
   extensions the conversation would appear as follows:

    Authenticating Peer   NAS                      DIAMETER Server
    -------------------   ---                      ---------------

                          <- PPP LCP Request-EAP
                          auth
    PPP LCP ACK-EAP
    auth ->
                          DIAMETER
                          EAP-Request/
                          EAP-Packet/Start ->
                                                   <- DIAMETER
                                                   Command-Unrecognized
                          <- PPP LCP Request-CHAP


Calhoun, Rubens, Aboba          expires September 1998           [Page 9]


INTERNET DRAFT                                                 March 1998


                          auth

    PPP LCP ACK-CHAP
    auth ->
                          <- PPP CHAP Challenge
    PPP CHAP Response ->
                          DIAMETER
                          Authentication-Request->
                                                   <- DIAMETER
                                                   Authentication-Success
                          <- PPP LCP
                          CHAP-Success
    PPP Authentication
    Phase complete,
    NCP Phase starts


2.5 Example of DIAMETER Proxy not supporting EAP

   In the case where the local  DIAMETER  Server  does  support  the  EAP
   extensions  but  the remote DIAMETER Server does not, the conversation
   would appear as follows:

    Authenticating Peer   NAS                      DIAMETER Server
    -------------------   ---                      ---------------

                          <- PPP LCP Request-EAP
                          auth
    PPP LCP ACK-EAP
    auth ->
                          DIAMETER-
                          EAP-Request/
                          EAP-Packet/Start ->
                                                   <- DIAMETER-
                                                   EAP-Response/
                                                   EAP-Packet/Identity
                          <- PPP EAP-Request/
                          Identity
    PPP EAP-Response/
    Identity
    (MyID) ->
                          DIAMETER-
                          EAP-Request/
                          EAP-Packet/EAP-Response/
                          (MyID) ->
                                                   <- DIAMETER-
                                                   EAP-Reject
                                                   (proxied from remote
                                                   DIAMETER Server)
                          <- PPP LCP Request-CHAP


Calhoun, Rubens, Aboba          expires September 1998          [Page 10]


INTERNET DRAFT                                                 March 1998


                          auth
    PPP LCP ACK-CHAP
    auth ->
                          <- PPP CHAP Challenge
    PPP CHAP Response ->
                          DIAMETER
                          Authentication-Request->
                                                   <- DIAMETER
                                                   Authentication-Success
                                                   (proxied from remote
                                                   DIAMETER Server)
                          <- PPP LCP
                          CHAP-Success
    PPP Authentication
    Phase complete,
    NCP Phase starts


2.6 Example of PPP Client not supporting EAP

   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                      DIAMETER Server
    -------------------   ---                      ---------------

                          <- PPP LCP Request-EAP
                          auth
    PPP LCP NAK-EAP
    auth ->
                          <- 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 ->

                          DIAMETER-
                          Authentication-Request/
                          User-Name,
                          CHAP-Password ->
                                                   <- DIAMETER-
                                                   EAP-Response/
                                                   EAP-Packet
                          <- LCP Terminate Req



Calhoun, Rubens, Aboba          expires September 1998          [Page 11]


INTERNET DRAFT                                                 March 1998


3.0 Alternative uses

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

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

   In the case where DIAMETER-encapsulated EAP is used in a  conversation
   between  a DIAMETER server and a backend security server, the Security
   Server  will  typically  return  an   DIAMETER-EAP-Ack/EAP-Packet/EAP-
   Success message without inclusion of the expected attributes currently
   returned in an Authentication-Success. This means  that  the  DIAMETER
   server  MUST  add  these  attributes prior to sending an DIAMETER-EAP-
   Ack/EAP-Packet/EAP-Success message to the NAS.


4.0 Command Name and Command Code

       Command Name: DIAMETER-EAP-Request
       Command Code: 18

       Command Name: DIAMETER-EAP-Response
       Command Code: 19

       Command Name: DIAMETER-EAP-Ack
       Command Code: 20

       Command Name: DIAMETER-EAP-Reject
       Command Code: 21


5.0 Command Meanings

5.1 DIAMETER-EAP-Request

   Description

      DIAMETER-EAP-Request command is sent by the DIAMETER Client to  the
      DIAMETER  Server,  and convey EAP-Responses from the client through
      the NAS and on to the DIAMETER server.  DIAMETER-EAP-Requests  will
      normally  include  at least one EAP-Packet attribute which contains
      the EAP packets. A DIAMETER-EAP-Request sent from the  NAS  to  the
      DIAMETER  Server  that  does  not  contain  an EAP-Packet attribute
      signals  to  the  DIAMETER  Server  that  it  is  to  initiate  EAP


Calhoun, Rubens, Aboba          expires September 1998          [Page 12]


INTERNET DRAFT                                                 March 1998


      authentication with the client.

      Upon receipt of a  DIAMETER-EAP-Request,  A  DIAMETER  Server  MUST
      issue  a reply. The reply may be either: 1) a DIAMETER-EAP-Response
      containing an EAP-Request in at lease one EAP-Packet attribute,  2)
      a  DIAMETER-EAP-Ack  containing an EAP-Packet of type "success", or
      3)  a  DIAMETER-EAP-Reject  containing  an   EAP-Packet   of   type
      "failure".  A Command-Unrecognized packet is returned if the server
      does not support the EAP extensions.

      The DIAMETER-EAP-Request message MUST include either the  Signature
      or the Digital-Signature attribute depending upon the local policy.
      A DIAMETER Server MUST calculate the correct calue of the Signature
      and  silently  discard  the  packet  if it does not match the value
      sent.

      A summary of the DIAMETER-EAP-Request packet 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Attribute Type         |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Flags     |         Command Type          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Attribute Type

      256     DIAMETER Command


    Length

      The length of this attribute MUST be 9.


    Flags

      The flag field MUST have bit 1 (Mandatory Support) set.


    Command Type

      The Command Type field MUST be set to 18 (DIAMETER-EAP-Request).


5.2 DIAMETER-EAP-Response

   Description


Calhoun, Rubens, Aboba          expires September 1998          [Page 13]


INTERNET DRAFT                                                 March 1998


      DIAMETER-EAP-Response packets are sent by the  DIAMETER  Server  to
      the  NAS.  They contain the next EAP-Request packet to be passed to
      the client.

      The DIAMETER-EAP-Response MUST  contain  at  least  one  EAP-Packet
      attribute  and  MUST  include  either the Signature or the Digital-
      Signature attribute depending upon the  local  policy.  A  DIAMETER
      Server  MUST  calculate  the  correct  calue  of  the Signature and
      silently discard the packet if it does not match the value sent.

      After issuing the included  EAP-Request  to  the  client,  the  NAS
      remains  in  a state where it awaits further EAP-Responses from the
      client.

      A summary of  the  DIAMETER-EAP-Response  packet  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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Attribute Type         |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Flags     |         Command Type          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Attribute Type

      256     DIAMETER Command


    Length

      The length of this attribute MUST be 9.


    Flags

      The flag field MUST have bit 1 (Mandatory Support) set.


    Command Type

      The Command Type field MUST be set to 19 (DIAMETER-EAP-Response).


5.3 DIAMETER-EAP-Ack

   Description

      DIAMETER-EAP-Ack packets are sent by the  DIAMETER  Server  to  the


Calhoun, Rubens, Aboba          expires September 1998          [Page 14]


INTERNET DRAFT                                                 March 1998


      NAS. They contain the next EAP-Request or EAP-Success packet to  be
      passed to the client.

      The DIAMETER-EAP-Ack packet MUST contain at  least  one  EAP-Packet
      attribute  and  MUST  include  either the Signature or the Digital-
      Signature attribute depending upon the  local  policy.  A  DIAMETER
      Server  MUST  calculate  the  correct  calue  of  the Signature and
      silently discard the packet if it does not match the value sent.

      After issuing the included EAP-Success packet to  the  client,  the
      NAS should end the authentication phase with a positive response.

      A summary of the DIAMETER-EAP-Ack packet 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Attribute Type         |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Flags     |         Command Type          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Attribute Type

      256     DIAMETER Command


    Length

      The length of this attribute MUST be 9.


    Flags

      The flag field MUST have bit 1 (Mandatory Support) set.


    Command Type

      The Command Type field MUST be set to 20 (DIAMETER-EAP-Ack).


5.4 DIAMETER-EAP-Reject

   Description

      DIAMETER-EAP-Reject packets are sent by the DIAMETER Server to  the
      NAS.  They  are  sent  in  response  to a DIAMETER-EAP-Request that
      results in an authentication failure.  DIAMETER-EAP-Reject  packets


Calhoun, Rubens, Aboba          expires September 1998          [Page 15]


INTERNET DRAFT                                                 March 1998


      contain at least one EAP-Packet attribute containing an EAP failure
      packet.

      After issuing the included EAP failure packet to  the  client,  the
      NAS should end the authentication phase with a negative result.

      The DIAMETER-EAP-Reject message MUST include either  the  Signature
      or the Digital-Signature attribute depending upon the local policy.
      A DIAMETER Server MUST calculate the correct calue of the Signature
      and  silently  discard  the  packet  if it does not match the value
      sent.

      A summary of the DIAMETER-EAP-Reject packet 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Attribute Type         |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Flags     |         Command Type          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Attribute Type

      256     DIAMETER Command


    Length

      The length of this attribute MUST be 9.


    Flags

      The flag field MUST have bit 1 (Mandatory Support) set.


    Command Type

      The Command Type field MUST be set to 21 (DIAMETER-EAP-Reject).


6.0 Attribute Name and Attribute Code

       Attribute Name: EAP-Packet
       Attribute Code: 277


7.0 Attribute Meanings


Calhoun, Rubens, Aboba          expires September 1998          [Page 16]


INTERNET DRAFT                                                 March 1998


7.1 EAP-Packet

   Description

      This attribute is used to contain the  actual  EAP-Requests  to  be
      sent  from  the DIAMETER server to the client (DIAMETER-EAP-Ack and
      DIAMETER-EAP-Reject) and the EAP-Responses  to  be  sent  from  the
      client  to the DIAMETER server (DIAMETER-EAP-Requests).  These EAP-
      Requests and Responses are exactly as defined in [1].

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Attribute Type         |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Flags     |        Sequence Number        |   String ...   |
      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      277 for EAP-Packet


   Length

      >= 7


   Flags

      The flag field MUST have bit 1 (Mandatory Support) set.


   Sequence Number

      The Sequence Number field is used in order to build a "history"  of
      the transaction. The EAP-Packet attribute with the highest Sequence
      Number represents the current packet to  process.  The  history  is
      passed along in each request/responses in order in order to support
      the concept of DIAMETER backup servers, as described earlier.


   String

      The String field is the exact EAP packet  data  to  be  transported
      from  client  to  server  or  server  to  client.   It  is not Null
      terminated and may contain arbitrary binary values.




Calhoun, Rubens, Aboba          expires September 1998          [Page 17]


INTERNET DRAFT                                                 March 1998


8.0 Acknowledgments

Thanks to Dave Dawson and Karl Fox of  Ascend,  Glen  Zorn  and  Narendra
Gidwani of Microsoft and Jeff Haag of 3Com for useful discussions of this
problem space.


9.0 References

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

    [2] P. R. Calhoun, "DIAMETER Authentication Extension",
        draft-calhoun-diameter-auth-00.txt, February 1998.

    [3] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote
        Authentication Dial In User Service (RADIUS)." RFC 2058,
        January, 1997.

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

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

    [6] S. Bradner, "Key words for use in RFCs to Indicate Requirement
        Levels." draft-bradner-key-words-02.txt,  August 1996.

    [7] P. R. Calhoun, A. Rubens, "DIAMETER Base Protocol",
        draft-calhoun-diameter-00.txt, February 1998.


10.0 Authors' Addresses

   Questions about this memo can be directed to:

      Pat R. Calhoun
      Technology Development
      Sun Microsystems, Inc.
      15 Network Circle
      Menlo Park, California, 94025
      USA

       Phone:  1-847-548-9587
         Fax:  1-650-786-6445
      E-mail:  pcalhoun@toast.net


      Allan C. Rubens
      Merit Network, Inc.
      4251 Plymouth Rd.


Calhoun, Rubens, Aboba          expires September 1998          [Page 18]


INTERNET DRAFT                                                 March 1998


      Ann Arbor, MI 48105-2785

       Phone: 1-313-647-0417
      E-Mail: acr@merit.edu


      Bernard Aboba
      Microsoft Corporation
      One Microsoft Way
      Redmond, WA 98052

       Phone: 1-425-936-6605
      E-Mail: bernarda@microsoft.com







































Calhoun, Rubens, Aboba          expires September 1998          [Page 19]