Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges

Bernard Aboba wrote:
>>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. 

Why would the cleartext password ever end up on a NAS?

Maybe a picture would help:

EAP Client          EAP Server           KDC
--------------------------------------------

     TTLS Negotiation
<----------------------->

krb5 authentication (EAP server is passthrough)
<------------------------------------------>

                          TGT, service ticket
<-------------------------------------------

       service auth
<----------------------->

{MK,MSK} = PRF(service key)

[ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ]
[ computer science ]-----[ university of maryland | college park ]

_______________________________________________
SECMECH mailing list
SECMECH@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/secmech