Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges

Josh Howlett <josh.howlett@bristol.ac.uk> Thu, 25 August 2005 15:35 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8JlV-0006j1-EL; Thu, 25 Aug 2005 11:35:41 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8JlT-0006gW-BJ for secmech@megatron.ietf.org; Thu, 25 Aug 2005 11:35:39 -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 LAA23917 for <secmech@ietf.org>; Thu, 25 Aug 2005 11:35:37 -0400 (EDT)
Received: from dirg.bris.ac.uk ([137.222.10.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8Jm0-0006uB-Bt for secmech@ietf.org; Thu, 25 Aug 2005 11:36:13 -0400
Received: from isis.bris.ac.uk ([137.222.10.63]) by dirg.bris.ac.uk with esmtp (Exim 4.51) id 1E8JkT-0005Ms-EZ; Thu, 25 Aug 2005 16:34:39 +0100
Received: from cumulus.cse.bris.ac.uk ([137.222.12.162]) by isis.bris.ac.uk with esmtp (Exim 4.51) id 1E8Jj5-0001XG-E2; Thu, 25 Aug 2005 16:33:14 +0100
Date: Thu, 25 Aug 2005 16:33:11 +0100
From: Josh Howlett <josh.howlett@bristol.ac.uk>
To: Shumon Huque <shuque@isc.upenn.edu>, Jari Arkko <jari.arkko@piuha.net>
Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges
Message-ID: <F7412BACB0F60392201F91A2@cumulus>
In-Reply-To: <20050825151922.GA29211@isc.upenn.edu>
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> <430DCD61.1090109@piuha.net> <20050825151922.GA29211@isc.upenn.edu>
Originator-Info: login-token=Mulberry:015adzIEcc3YYoELl/H0YXoJMiHqd5JUrV1ZIZG6d3FRMc3g==; token_authority=postmaster@bristol.ac.uk
X-Mailer: Mulberry/3.1.5 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: -2.8
X-Spam-Level: --
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Content-Transfer-Encoding: 7bit
Cc: secmech@ietf.org, Nicolas Williams <Nicolas.Williams@sun.com>
X-BeenThere: secmech@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Josh Howlett <josh.howlett@bristol.ac.uk>
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 Thursday, August 25, 2005 11:19:23 -0400 Shumon Huque 
<shuque@isc.upenn.edu> wrote:

> On Thu, Aug 25, 2005 at 04:53:37PM +0300, Jari Arkko wrote:
>> Shumon Huque wrote:
>>
>> > 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.
>> >
>> >
>> Given choice, I'd rather have a well-design fully
>> capable mechanisms than a tunnel + a mechanism
>> that needs to run inside the tunnel.
>>
>> --Jari
>
> I completely agree. However, current options don't look good
> for Kerberos 5, unless a strong password based pre-authentication
> mechanism is developed. So, I'm willing to endorse the scheme
> of running Kerberos inside TLS, at least as an interim measure
> (ala Tom Clancy's recent diagram).

IIRC, it was inside TTLS. However, it might it still be worth considering 
an EAP-Kerberos so as not to preclude the option of running it inside PEAP 
as well (even if native EAP-Kerberos is a Bad Idea over 802.11). It might 
also provide the basis for a subsequent improved Kerberos EAP method that 
could be used natively.

josh.

-- 
-----------------------------------------------------------
Josh Howlett, Networking & Digital Communications,
Information Systems & Computing, University of Bristol, U.K.
'phone: 0117 928 7850 email: josh.howlett@bris.ac.uk
------------------------------------------------------------

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