Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges

[Bernard Aboba <[e-mail]>]

> If the EAP server is the service, then it can do a passthrough Kerberos
> authentication for the EAP client.  The client can obtain a TGT and a service
> ticket for the EAP server, and then authenticate to the EAP server using the
> service ticket.  The key contained within that service ticket is known only by
> the client and the EAP server, so it could theoretically then be used to
> bootstrap an EAP key derivation, including the info needed by TTLS to do the
> crypto binding.  TTLS would then augment the security of these keys using its
> own entropy, and poof.
> 
> ... or am I missing something?

EAP methods need to be "mode independent" which implies that they need to 
work the same way regardless of whether an authentication server is 
present or not.  If an AS is not present, then the EAP server resides on 
the NAS, and the EAP peer would be providing a clear text password to the 
NAS. 

"AAA Key Management" (draft-housley-aaa-key-mgmt-00.txt) talks about 
preventing cascading vulnerabilities.  One of the requirements is that 
compromise of one NAS not compromise long-term credentials. 

Providing a cleartext password to a NAS seems like it would violate that 
requirement. 

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