Subject: RE: [AAA-WG]: Wrapping up Diameter EAP...

From: <[email-masked]>
Date: Mon, 24 May 2004 16:56:17 +0300

Hi,

NASREQ already specifies the State AVP and, more
importantly, uses the State attribute to keep track of 
Diameter Session-Id on the RADIUS side.

This latter feature seems to actually help us: when a
translation agent receives a RADIUS Access-Request without 
a State attribute, it already picks a new Session-Id.

(BTW, the former feature seems to require that the translation
agent stores the State AVP sent by the Diameter server (if any)
locally, since the RADIUS Access-Response can contain only zero
or one State attributes. But this is not specific to EAP.)

Given this, I think the translation functionality already
present in NASREQ is sufficient for the job, and we only have 
to clarify how Diameter NASes should behave. Perhaps something 
like this?

  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.

Best regards,
Pasi 

> -----Original Message-----
> From:t Yoshihiro Ohba
> Sent: Tuesday, May 18, 2004 6:07 PM
> To: Jari Arkko
> Cc: Yoshihiro Ohba; Eronen Pasi (Nokia-NRC/Helsinki); [email-masked]
> Subject: Re: [AAA-WG]: Wrapping up Diameter EAP...
> 
> 
> On Tue, May 18, 2004 at 05:00:22PM +0300, Jari Arkko wrote:
> > Yoshihiro Ohba wrote:
> > 
> > > I don't think we need to define the same method for RADIUS and
> > > Diameter to support EAP restart.  Diameter can be smarter 
> as it has
> > > Session-Id and is able to terminate a session.
> > 
> > Ok. That's reasonable. But are you saying
> > 
> >   1) We don't need Diameter and RADIUS to interoperate upon 
> >     EAP restart.
> > 
> > or
> > 
> >   2) If we use Session-Id to support EAP restart in Diameter,
> >   we can make that work also through a D-R gateway so that it
> >   works even in RADIUS, which has to use State attribute?
> > 
> > I'd be happy with alt 2, but has someone looked at the details,
> > and can we make it work?
> 
> I also support alt 2.  I think translation between RADIUS and
> Diameter can be done in the following way (assuming that a
> State AVP is always carried in RADIUS Access-Answer and
> Access-Accept messages when an EAP-Message attribute is
> carried):
> 
> - Translation from DER to RADIUS Access-Request:
> 
> If the translation agent receives a DER with a new Session-Id,
> then it generates a RADIUS Access-Request without a State
> attribute.  The RADIUS server will treat the request as a
> signal to restart the EAP session if the NAS and session
> identification attributes corresponds to an existing EAP
> session.
> 
> If the translation agent receives a DER with an existing
> Session-Id, then it generates a RADIUS Access-Request with a
> State attribute that was contained in the message that was
> previously sent by the RADIUS server.
> 
> - Translation from RADIUS Access-Request to DER:
> 
> If the translation agent receives a RADIUS Access-Request
> without a State attribute, then it creates a new Diameter
> session and generates a DER with a new Session-Id.
> 
> If the translation agent receives a RADIUS Access-Request with
> a State attribute as well as the NAS and session
> identification attributes corresponding to an existing EAP
> session, then it generates a DER with the corresponding
> Session-Id.
> 
> But I am pretty sure Pasi will come up with better text. :)
> 
> Yoshihiro Ohba

---

From: Jari Arkko <[email-masked]>
Date: Mon, 24 May 2004 21:19:52 +0300

>   reason, it MUST select a new Diameter Session-Id for any

Ok. But I wonder if it would be useful to write down also
the thinking behind this, i.e., the use of the State attribute
in RADIUS to do the restart. "This is necessary because ...".

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 24 May 2004 11:32:52 -0700 (PDT)

> in RADIUS to do the restart. "This is necessary because ...".

Yes.  An errata to RFC 3579 might also make sense.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 24 May 2004 22:31:22 +0300

> Yes.  An errata to RFC 3579 might also make sense.

Ok. Here's some proposed text. For D-EAP:

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

For R-EAP RFC 3579 Errata:

   "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

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 26 May 2004 15:32:54 -0700 (PDT)

I like this. We should probably bring the RFC 3579 Errata issue to EAP WG.
I've filed it as Issue 242 on the EAP issues list.