Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges

Charles Clancy <clancy@cs.umd.edu> Mon, 22 August 2005 12:42 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Bcy-0001bG-PP; Mon, 22 Aug 2005 08:42:12 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Bcx-0001bB-2d for secmech@megatron.ietf.org; Mon, 22 Aug 2005 08:42:11 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12903 for <secmech@ietf.org>; Mon, 22 Aug 2005 08:42:09 -0400 (EDT)
Received: from carrierpigeon.cs.umd.edu ([128.8.129.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7CDW-0007r3-BG for secmech@ietf.org; Mon, 22 Aug 2005 09:19:58 -0400
Received: from ismene (ismene.cs.umd.edu [128.8.126.62]) by carrierpigeon.cs.umd.edu (8.12.10/8.12.5) with ESMTP id j7MCfxfD016386; Mon, 22 Aug 2005 08:41:59 -0400 (EDT)
Date: Mon, 22 Aug 2005 08:36:44 -0400 (EDT)
From: Charles Clancy <clancy@cs.umd.edu>
X-X-Sender: clancy@ismene
To: Shumon Huque <shuque@isc.upenn.edu>
Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges
In-Reply-To: <20050822044255.GC27685@isc.upenn.edu>
Message-ID: <Pine.GSO.4.60.0508220801430.1114@ismene>
References: <7210B31550AC934A8637D6619739CE6905C06510@e2k-sea-xch2.sea-alpha.cisco.com> <Pine.GSO.4.60.0508191330380.16954@ismene> <20050819210308.GI6659@binky.Central.Sun.COM> <20050820031035.GA5352@isc.upenn.edu> <43074F76.8000604@cs.umd.edu> <20050822044255.GC27685@isc.upenn.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Cc: secmech@ietf.org, Nicolas Williams <Nicolas.Williams@sun.com>
X-BeenThere: secmech@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security mechanisms BOF <secmech.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/secmech>, <mailto:secmech-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/secmech>
List-Post: <mailto:secmech@lists.ietf.org>
List-Help: <mailto:secmech-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/secmech>, <mailto:secmech-request@lists.ietf.org?subject=subscribe>
Sender: secmech-bounces@lists.ietf.org
Errors-To: secmech-bounces@lists.ietf.org

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 ]--[ 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