Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges

[Charles Clancy <[e-mail]>]

On Mon, 22 Aug 2005, Shumon Huque wrote:

> I've read RFC 4017. My discomfort comes from the observation that it is 
> at best incomplete to point this out only for wireless LANs, since many 
> of these vulnerabilities are applicable to other link layers too. If I 
> use an EAP method that supports Kerberos on a wired ethernet for 
> example, the dictionary attack threat still exists. I do not find the 
> differential magnitude of the threat a very convincing argument. It 
> makes more sense to design security mechanisms with the uniform 
> assumption that the network is always hostile.

As a responsible cryptographer, I would never advocate using an 
authentication protocol vulnerable to dictionary attacks over any PHY. 
However, I recognize more than just crypto goes into deciding what 
protocol to deploy.  Were this true, everything would be one big PKI, and 
working groups like BTNS wouldn't exist.  If people want to shoot 
themselves in the foot, it would be nice to minimize the damage.

> This puts us in a position of having to say (whether we're using
> EAP or not): "use Kerberos normally, except when running over
> link layers X, Y and Z, in which case you should run it only in
> a protected, cryptographically bound tunnel". If we need to address
> the dictionary attack problem, I think we should discuss how to
> do so in the Kerberos protocol directly. Perhaps that discussion
> belongs in another group though ..

I think something like "You SHOULD Kerberos in a cryptographically bound 
tunnel.  If you don't, you're vulnerable to offline dictionary attacks. 
These types of attacks are significantly easier to execute in some link 
layers, e.g. X, Y, and Z."

> I'm also not a fan of automatically assuming that a tunnel is the
> right solution for many problems. If we are tunnelling in TLS for
> example, I now have additional issues to deal with. Such as how to
> query up-to-date certificate revocation status, and whether my
> users are properly validating the certificates etc.

I don't think SECMECH should try to change Kerberos, so all we can do is 
wrap something around it.  The two basic ways to fix dictionary attacks is 
public-key crypto with a server-side cert, or the IPR-riddled 
EKE/SPEKE/SRP protocols.  The latter would require Kerberos protocol 
changes.  Personally, I think a native EAP-Kerberos method that utilizes 
DTLS is the way to go.  In 802.11, it would look something like:

STA          AP           AAA          KDC
|------------|-------------|-------------|

       EAP(DTLS(krb5))           krb5
<-------------------------><------------->

     802.1X         AAA          krb5
<------------><-----------><------------->

As for CRLs, it's likely that one's AAA server and KDC will be of similar 
configuration, on the same subnet, or even the same machine.  If someone 
compromises your EAP server's private key, your KDC master secret won't be 
far behind.  So, if you're ever at a point where you need to worry about 
CRLs, you have bigger problems.  (Though, this argument doesn't 
necessarily apply to cross-real authentication, roaming, etc.)

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

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