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

From: <[email-masked]>
Date: Fri, 14 May 2004 10:40:53 +0300

Hmm, a question: FC 3579 distinguishes between sessions using the
following attributes: NAS-Identifier, NAS-IPv6-Address,
NAS-IPv4-Address, User-Name, NAS-Port, NAS-Port-Type, NAS-Port-Id,
Called-Station-Id, Calling-Station-Id and Originating-Line-Info.

Is it enough to use the Session-Id AVP to get the same effect 
in Diameter?

In addition to Session-Id, we may still need the State attribute
to distinguish multiple EAP sessions within a single Diameter session,
if we assume that e.g. reauthentication can keep the same Diameter
Session-Id.

Cheers,
Pasi

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> ext Joseph Salowey
> Sent: Friday, May 14, 2004 7:51 AM
> To: 'Jari Arkko'; 'David Mitton'
> Cc: [email-masked]
> Subject: RE: [AAA-WG]: Wrapping up Diameter EAP...
> 
> 
> 
> 
> [email-masked] wrote:
> > David Mitton wrote:
> >> Note that a State attribute comes from the Server, and a 
> client only
> >> reflects it.
> > 
> > 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. 
> > 
> 
> [Joe] Currently the state attribute is not required so not all server
> implementations may include it.  Perhaps when EAP is used 
> they should.  
> 
> > --Jari
> > 
> >> Dave.
> >> 
> >> On 5/12/2004 08:25 PM +0300, Jari Arkko wrote:
> >> 
> >>> 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:
> >>> 
> >>>> Question: Does the RADIUS  State attribute serve some of the same
> >>>> function? For example, continuing EAP conversations may contain a
> >>>> State attribute. On Wed, 12 May 2004 [email-masked] wrote:
> >>>> 
> >>>>> 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
> 
>

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 14 May 2004 01:10:40 -0700 (PDT)

> if we assume that e.g. reauthentication can keep the same Diameter

Yes.  I think in practice that the State attribute is needed to avoid
strange behavior such as for the case we have been discussing on the EAP
WG mailing list (EAPOL restart).

---

From: "Joseph Salowey" <[email-masked]>
Date: Fri, 14 May 2004 08:26:23 -0700

So is it possible that session-Id could refer to something other than the
current authentication transaction, or will it be unambiguous?

I worry a little about overloading session-id since there can be many pieces
of state each of which can be identified as a separate session.   

[email-masked] wrote:
>> In addition to Session-Id, we may still need the State attribute to
>> distinguish multiple EAP sessions within a single Diameter session,
> Yes.  I think in practice that the State attribute is needed
> to avoid strange behavior such as for the case we have been
> discussing on the EAP WG mailing list (EAPOL restart).

---

From: Jari Arkko <[email-masked]>
Date: Fri, 14 May 2004 18:42:59 +0300

I'm starting think that the use of State attribute
is the right approach, as it handles the issue for
both AAA protocols, and does not overload the
Session-Id for yet another purpose. Otherwise I
believe the same attributes as listed in RFC 3579
can be used.

---

From: Barney Wolff <[email-masked]>
Date: Fri, 14 May 2004 15:01:15 -0400

> current authentication transaction, or will it be unambiguous?

As a server owner, how much do you trust the client's implementation to
always get it right?  Call me paranoid, but I would certainly add on
whatever I could to the id to ensure uniqueness.

-- 
Barney Wolff         http://www.databus.com/bwresume.pdf
I'm available by contract or FT, in the NYC metro area or via the 'Net.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 17 May 2004 07:54:31 -0700

> WG mailing list (EAPOL restart).

I have a couple of issues when the State attribute/AVP is used for
handling the reset operation:

- What the Diameter EAP client (i.e., the NAS) should do when EAP is
reset while it has an outstanding DER?  (a) Can the Diameter EAP
client immediately send a new DER used for restarting EAP conversation
without waiting for a DEA for the outstanding DER, or (b) Should the
Diameter EAP client wait for a DEA for the outstanding DER before
sending a new DER used for restarting EAP conversation?

- In the case of a), it might be possible that the Diameter EAP client
receives a DEA for the previously outstanding DER after it has sent a
new DER used for restarting EAP conversation.  How can the Diameter
EAP client distinguish between the DEA for the previously outstanding
DER and the DEA for the new DER?

Regards,

Yoshihiro Ohba