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

From: <[email-masked]>
Date: Wed, 12 May 2004 19:40:25 +0300

I took a look at the state machines, and what seems to be missing 
is a way to pass the "eapRestart" signal to the AAA server...

John Vollbrecht suggested that this could be solved by adding an 
attribute signalling that this is the first EAP packet of an EAP
conversation. Maybe named something like EAP-Restart or EAP-Start?
If we assign the type code from 0..255 range, it would work for RADIUS 
as well...

(This way we could keep the Session-Id same; I think it's supposed
to stay the same over reauthentications..)

Best regards,
Pasi

> -----Original Message-----
> From: ext Jari Arkko [mailto:[email-masked]]
> Sent: Wednesday, May 12, 2004 6:34 PM
> To: Bernard Aboba
> Cc: Eronen Pasi (Nokia-NRC/Helsinki); [email-masked]
> Subject: Re: [AAA-WG]: Wrapping up Diameter EAP...
> 
> 
> Bernard Aboba wrote:
> >>Yes. How about making the same statement as in RFC 3579,
> >>but add Session-Id AVP in there as well?
> > 
> > 
> > In addition, I think you'd need to be clear that the 
> Session-Id AVP would
> > need to change if the session were restarted, and that the 
> Diameter server
> > should consider it a different session as a result.
> > 
> > I think the same thing would also apply to a reauthentication, no?
> 
> Also, we could invent a completely new AVP that fixes the issue
> for both Diameter *and* RADIUS.
> 
> --Jari
>

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 12 May 2004 09:53:21 -0700 (PDT)

Question: Does the RADIUS  State attribute serve some of the same
function?

For example, continuing EAP conversations may contain a State attribute.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 12 May 2004 20:25:13 +0300

Good question. I suppose it can be used to implement this.
Maybe the only missing thing is that RFC 3579 doesn't say
it should be used this way? Note that State would work for
Diameter EAP too, I think.

--Jari

---

From: David Mitton <[email-masked]>
Date: Wed, 12 May 2004 13:57:19 -0400

Note that a State attribute comes from the Server, and a client only 
reflects it.

Dave.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 12 May 2004 23:09:21 +0300

> Note that a State attribute comes from the Server, and a client only 

Yes. But if client does not include the State attribute in its
new Access Request, its an indication to the server that a new
EAP run has started.

However, in order for this to work, the server has to use the
State attribute, and it has to understand what the lack of
the State attribute means.

--Jari

---

From: "Joseph Salowey" <[email-masked]>
Date: Thu, 13 May 2004 21:50:58 -0700

[email-masked] wrote:
> Yes. But if client does not include the State attribute in
> its new Access Request, its an indication to the server that a new
> EAP run has started. 
> 
> State attribute, and it has to understand what the lack of the State
> attribute means. 
> 

[Joe] Currently the state attribute is not required so not all server
implementations may include it.  Perhaps when EAP is used they should.  

>>> Good question. I suppose it can be used to implement this. Maybe the
>>> only missing thing is that RFC 3579 doesn't say it should be used
>>> this way? Note that State would work for Diameter EAP too, I think.
>>> 
>>> --Jari
>>> 
>>> Bernard Aboba wrote:
>>> 
>>>> function? For example, continuing EAP conversations may contain a
>>>> State attribute. On Wed, 12 May 2004 [email-masked] wrote:
>>>> 
>>>>> If we assign the type code from 0..255 range, it would work for
>>>>> RADIUS as well... 
>>>>>