RE: [SECMECH] Framework Bindings Vs. Mechanism Bridges

["Salowey, Joe" <[e-mail]>]

 

> -----Original Message-----
> From: Bernard Aboba [mailto:[e-mail]] 
> Sent: Friday, August 26, 2005 8:01 AM
> To: Shumon Huque
> Cc: Salowey, Joe; [e-mail]
> Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges
> 
> > The AAA server could perform the service ticket validation 
> on behalf 
> > of the NAS. This requires another round trip with the AAA 
> server, but 
> > I don't think this is too much of a problem.
> 
> How does the EAP peer figure out the scope of usage of the 
> "network access service" ticket?  If each NAS is a separate 
> Kerberos principal, then the peer needs a distinct ticket for 
> each NAS;  if the AAA server is the principal, then it can 
> submit the same ticket to any NAS. 
> 

[Joe] I don't think there is necessarily a problem service ticket for
the AAA.  This is how EAP typically works today. 

> > If we need the NAS to support Kerberos, then I think the barrier to 
> > practical deployment is too high. Or am I missing something?
> 
> I think that the NAS needs to be modified even in the case 
> where the AAA server is the Kerberos principal, in order to 
> be able to securely inform the EAP peer of the ticket scope.  
> Otherwise, the EAP peer can't know when it needs to acquire 
> another ticket. 

[Joe] How would the NAS know anything about the ticket scope?  If you
are concerned about scope why would you trust the NAS to tell you?  It
would seem that this information needs to encoded in the ticket. Perhaps
scope can be derived from the service principal name. 


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