Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges

Nicolas Williams <> Mon, 22 August 2005 15:38 UTC

Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1E7ENU-0000xS-1w; Mon, 22 Aug 2005 11:38:24 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1E7ENS-0000ws-Gx for; Mon, 22 Aug 2005 11:38:22 -0400
Received: from (ietf-mx []) by (8.9.1a/8.9.1a) with ESMTP id LAA23278 for <>; Mon, 22 Aug 2005 11:38:19 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.43) id 1E7Ey0-0004m0-4Y for; Mon, 22 Aug 2005 12:16:11 -0400
Received: from centralmail2brm.Central.Sun.COM ([]) by (8.12.10/8.12.9) with ESMTP id j7MFcH2B000617 for <>; Mon, 22 Aug 2005 08:38:17 -0700 (PDT)
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM []) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j7MFcGLG011617 for <>; Mon, 22 Aug 2005 09:38:17 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost []) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j7MFcGLI008745; Mon, 22 Aug 2005 10:38:16 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j7MFcG83008744; Mon, 22 Aug 2005 10:38:16 -0500 (CDT)
Date: Mon, 22 Aug 2005 10:38:16 -0500
From: Nicolas Williams <>
To: Shumon Huque <>
Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges
Message-ID: <20050822153816.GD7789@binky.Central.Sun.COM>
References: <> <Pine.GSO.4.60.0508191330380.16954@ismene> <20050819210308.GI6659@binky.Central.Sun.COM> <> <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.7i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security mechanisms BOF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

On Mon, Aug 22, 2005 at 12:42:55AM -0400, 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.
> 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 ..

BTW, and for the benefit of lurkers and future readers of this list, the
password cracking issues, for Kerberos V apply only to the AS KDC
exchanges, and only when using PA-ENC-TIMESTAMP pre-auth.  And that's
relevant to EAP only because we all agree that we'd want to tunnel KDC
exchanges through EAP as that would be the only way to reach the KDC for
EAP client in many, many cases.

> 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.

Agreed.  But you can do other things too.  Like: ignore this issue at
first and do cryptographic binding between the inner and tunnel layers
and, if the result succeeds in real-time (assuming that offline password
dictionary attacks can't be done in real-time), "learn" the server cert;
the problem is what to do if the password-based mechanism fails...
(e.g., tell the user to call his/her helpdesk, which need not be as
easy for the user to do, or as likely that the user would actually do
it, as one might hope).


SECMECH mailing list