Subject: Re: [Emu] Issue #14 Emergency auth

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 8 Sep 2009 17:17:45 -0700

Hi Yaron,

Does this issue still require the document to be modified?  If so what
text would you like to see.

Thanks,

Joe

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Joseph Salowey (jsalowey)
> Sent: Thursday, August 06, 2009 4:36 PM
> To: Yaron Sheffer; [email-masked]
> Subject: Re: [Emu] Issue #14 Emergency auth
> 
> Often, there is a richer interface between EAP and the authenticator.
> For example in an Access-Accept message from RADIUS a number 
> of things can be communicated about the authentication 
> including the identity of the authenticated peer.  I also 
> don't think that EAP-Success necessarily implies mutual 
> authentication, it just says that the EAP server is satisfied 
> with the result of the process. 
> 
> Joe
> 
> > -----Original Message-----
> > From: Yaron Sheffer [mailto:[email-masked]]
> > Sent: Thursday, August 06, 2009 3:05 PM
> > To: Joseph Salowey (jsalowey); [email-masked]
> > Subject: RE: Issue #14 Emergency auth
> > 
> > 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-masked] [mailto:[email-masked]] On
> > Behalf Of
> > > Joseph Salowey (jsalowey)
> > > Sent: Thursday, August 06, 2009 22:14
> > > To: [email-masked]
> > > 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-masked]
> > > https://www.ietf.org/mailman/listinfo/emu
> > > 
> > > Scanned by Check Point Total Security Gateway.
> > 
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu
>