eap Mailing List: RE: Issue 204: Peer-to-peer operation

[Joseph Salowey (jsalowey]

> -----Original Message-----
> From: eap-admin [at] frascone.com [mailto:eap-admin [at] frascone.com] 
> On Behalf Of Bernard Aboba
> Sent: Wednesday, November 26, 2003 8:07 AM
> To: Jari Arkko
> Cc: Nick Petroni; eap [at] frascone.com
> Subject: Re: [eap] Issue 204: Peer-to-peer operation
> 
> 
> > Interesting discussion! When we come to a conclusion, we should 
> > document the result in the state machine spec just to avoid people 
> > asking about it later.
> >
> > A couple of points:
> >
> >    o  Assuming 802.11i, wouldn't mutual authentication be
> >       required in any case, so in theory 802.11i equipment
> >       could assume Access-Accept = mutual authentication?
> 
> I think the issue may in part be that mutual auth != 
> confirmed result indications.

[Joe] Yes this seems to be the issue, but I'm still not sure what the
value is in confirmed result indicators or why it has to be done in EAP
and not the layer calling EAP.  

> 
> >    o  But in general, I agree that if methods could provide
> >       information to other layers about the type of
> >       authentication they performed, this would be useful.
> >
> >    o  If we do provide such information over an API, we
> >       also need new AAA attributes as Bernard pointed out.
> 
> Yes, I think that may be required. 

[Joe] If these attributes are not present do you deny access or is this
a local policy decision on the NAS?   Shouldn't this be centralized with
the rest of the access policy in AAA?

> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
>