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

From: <[email-masked]>
Date: Thu, 27 May 2004 14:06:56 +0300

Ok, I have now put together version -06.b which adds the 
following section: 

2.8.5  Identifier space

   In EAP, each session has its own unique Identifier space.  Diameter
   server implementations MUST be able to distinguish between EAP
   packets with the same Identifier existing within distinct EAP
   sessions, originating on the same NAS.  This is done by using the
   Session-Id AVP.

   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, the same functionality can be 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.

Is this sufficient?

BR,
Pasi

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> ext Jari Arkko
> Sent: Monday, May 24, 2004 10:31 PM
> To: Bernard Aboba
> Cc: Eronen Pasi (Nokia-NRC/Helsinki); [email-masked]
> Subject: Re: [AAA-WG]: Wrapping up Diameter EAP...
> 
> 
> Bernard Aboba wrote:
> >>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 ...".
> > 
> > 
> > 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: Jari Arkko <[email-masked]>
Date: Thu, 27 May 2004 14:15:41 +0300

Ok. Nit: s/furthemore/furthermore/ (this was
originally a mistake in my text).