Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges

Nicolas Williams <Nicolas.Williams@sun.com> Thu, 25 August 2005 04:14 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E897v-0008CG-GQ; Thu, 25 Aug 2005 00:14:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E897t-0008C2-OP for secmech@megatron.ietf.org; Thu, 25 Aug 2005 00:14:06 -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 AAA13723 for <secmech@ietf.org>; Thu, 25 Aug 2005 00:14:01 -0400 (EDT)
Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E898B-0004YO-A3 for secmech@ietf.org; Thu, 25 Aug 2005 00:14:32 -0400
Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j7P4Dr2B020622 for <secmech@ietf.org>; Wed, 24 Aug 2005 21:13:53 -0700 (PDT)
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j7P4DqLG005378 for <secmech@ietf.org>; Wed, 24 Aug 2005 22:13:52 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j7P4DpmU013903; Wed, 24 Aug 2005 23:13:51 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j7P4DoiX013902; Wed, 24 Aug 2005 23:13:50 -0500 (CDT)
Date: Wed, 24 Aug 2005 23:13:50 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Bernard Aboba <aboba@internaut.com>
Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges
Message-ID: <20050825041350.GV10174@binky.Central.Sun.COM>
References: <Pine.GSO.4.60.0508221008260.1174@ismene> <1DCACCAC04655B3AFE9733A8@cumulus> <Pine.GSO.4.60.0508221047001.1307@ismene> <20050822154044.GE7789@binky.Central.Sun.COM> <430CA545.3020109@uni-tuebingen.de> <Pine.LNX.4.61.0508241113420.16086@internaut.com> <20050824213010.GO10174@binky.Central.Sun.COM> <Pine.LNX.4.61.0508241436250.21720@internaut.com> <430D0D2B.8050405@cs.umd.edu> <Pine.LNX.4.61.0508241724080.26080@internaut.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.61.0508241724080.26080@internaut.com>
User-Agent: Mutt/1.5.7i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Cc: secmech@ietf.org
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 Wed, Aug 24, 2005 at 05:30:09PM -0700, 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. 

So, there could (should?) be a standard framework for transporting key
material from the EAP server to the NAS, yes?  Is this covered in the
EAP key management I-D?  Or does every EAP method have to provide its
own EAP-server-->NAS key transport protocol?

Nico
-- 

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