Subject: RE: [SECMECH] Framework Bindings Vs. Mechanism Bridges

From: "Salowey, Joe" <[email-masked]>
Date: Fri, 26 Aug 2005 08:06:48 -0700

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Thursday, August 25, 2005 11:40 PM
> To: Salowey, Joe
> Cc: Ali Fessi; [email-masked]
> Subject: RE: [SECMECH] Framework Bindings Vs. Mechanism Bridges
> 
> > > EAP-Kerb/IAKERB/GSS is inherently different other EAP methods 
> > > because it requires support for the method on the NAS.  
> That is, the 
> > > NAS needs to support Kerberos for a peer to be able to 
> submit a TGS 
> > > to the NAS in order to obtain network access.
> > > 
> > [Joe] I'm not quite sure what you mean. If a AAA server is not 
> > involved then this is not really any different than 
> terminating EAP-TLS on a NAS.
> 
> It's different because the NAS needs to support Kerberos even 
> if it is operating in "Pass-through" mode.  

[Joe] Then its not operating in "Pass-through" mode, it is terminating
EAP (acting as an EAP server).

> In contrast, a 
> NAS operating in pass-through mode for EAP-TLS doesn't need 
> to validate the client certificate. 
> 
> > It could also be possible to still involve a AAA and have 
> it terminate 
> > the method and talk to the KDC. If you are trying to implement a 
> > method that is evaluated by both the NAS and the AAA in the same 
> > transaction you are really doing something other than EAP.
> 
> In all the EAP Kerberos proposals I've seen the method is 
> terminated on either the NAS or AAA server, but not both.  
> But in any scenario, the NAS still needs to support Kerberos, 
> in order to validate the "network access" service ticket. 

[Joe] If this is done in the same method execution instance it seems
problematic to me, because you have in effect two EAP-servers (one in
the AAA and one in the NAS) processing the EAP messages.  This is not
EAP. 

_______________________________________________
SECMECH mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/secmech

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 26 Aug 2005 10:32:49 -0500

> EAP (acting as an EAP server).

I agree.

As for fast reconnect/handoff, which I'd mentioned earlier, the re-use
of TGTs and service tickets (within their lifetimes), can save round
trips in the IAKERB method, but doesn't really amount to fast
reconnect/handoff in pass-through mode in that the method must be used
everytime and so the EAP server is involved always.

What is the exact definition of "fast reconnect/handoff" anyways?
RFC3748's description of "fast reconnect" does not say very much.

> the AAA and one in the NAS) processing the EAP messages.  This is not

I agree.  If the NAS speaks Kerberos V and, more importantly, if there's
a cross-realm path from the peer's principal's realm to the NAS's realm,
then NAS is (should be) the EAP server also; if the NAS does not speak
Kerberos or there is not such x-realm path then, as far as the NAS is
concerned, the EAP Kerberos V method is like any other AAA method.

Nico
--