The contract between the authenticator and the EAP layer is, when I see an EAP Success message, it means that both sides are authenticated. We are now breaking this contract, so it makes sense to have EAP inform the upper layer of this fact.
But I suppose EAP is not extensible enough to add such semantics. Sigh.
Thanks,
Yaron
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Joseph Salowey (jsalowey)
> Sent: Thursday, August 06, 2009 22:14
> To: [email protected]
> Subject: [Emu] Issue #14 Emergency auth
>
>
> > Referring to Sec. 3.5 of
> http://tools.ietf.org/html/draft-ietf-emu-eaptunnel-req-03, there should
> be an indication to the application that is using EAP > that such
> "strange" authentication took place. For example, the VoIP server may
> than make sure that only calls to 911 or 112 are allowed. Otherwise
> > there is no way to authorize the user without some backchannel into
> the AAA.
> >
> > So I propose to add:
>
> > "The tunnel method, if it supports emergency services, MUST provide an
> indication at the EAP or EAP-method level that such authentication took
> place; >
> > the indication MUST be unencrypted but integrity protected".
>
> I don't understand what this text is for? Who is this indication for?
> An application should not be sniffing EAP packets to see what happens.
> It seems that this is the responsibility of a local API between the EAP
> server and the application.
>
>
> Joe
> _______________________________________________
> Emu mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/emu
>
> Scanned by Check Point Total Security Gateway.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
