Subject: [eap] issue 242 -- State attribute and RFC 3579

From: Jari Arkko <[email-masked]>
Date: Thu, 27 May 2004 07:53:13 +0300

We have previously discussed what happens when EAPOL-Start
is received and whether ongoing authentication is restarted.
The primary problem appears to be the ability of the AAA
protocols to tell the AAA server what is happening.

On the AAA WG we have been looking at how to make it possible
in Diameter EAP. Here's the current text proposal:

    If a Diameter NAS is in the middle of a multi-round
    authentication exchange, and it detects that the EAP session
    between the client and the NAS has been terminated for some
    reason, it MUST select a new Diameter Session-Id for any
    subsequent EAP sessions.

    This is necessary in order to distinguish a restarted
    EAP authentication process from the continuation of an ongoing
    process (by the same user on the same NAS and port).

    In RADIUS [RFC 3579 Errata], the same functionality is
    achieved through the inclusion or omission of the State
    attribute. Translation rules in [NASREQ] ensure that
    an Access-Request without the State attribute maps to a
    a new Diameter Session-Id AVP value. Furthemore, a
    translation agent will always include a State attribute
    in Access-Challenge messages, making sure that the State
    attribute is available for a RADIUS NAS.

As you can see, we assume that the State attribute is
used in RADIUS to implement the same functionality.
However, RFC 3579 does not say anything about this
matter. Would it make sense to create an errata for
this RFC and say the following:

    The use of the State attribute is necessary in order to
    distinguish a restarted EAP authentication process from
    the continuation of an ongoing process (by the same user
    on the same NAS and port).

    The following rules specify how this attribute is used
    with RADIUS EAP:

      o  RADIUS servers SHOULD always include the State
         attribute in an Access-Challenge, Access-Accept,
         or Access-Reject message.

      o  Normally, a NAS copies the received State attribute
         to an Access-Request sent as a response to an
         Access-Challenge [RFC 2865 Section 5.24]. Note that
         an Access-Request sent as a result of a new or
         restarted authentication run MUST NOT include the
         State attribute, even if the State attribute has
         previously been received in an Access-Challenge
         for the same user and port.

--Jari

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap