Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges

Bernard Aboba <aboba@internaut.com> Thu, 25 August 2005 03:52 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E88mr-0001Nz-Or; Wed, 24 Aug 2005 23:52:21 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E85dJ-00030w-0n for secmech@megatron.ietf.org; Wed, 24 Aug 2005 20:30:17 -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 UAA05913 for <secmech@ietf.org>; Wed, 24 Aug 2005 20:30:15 -0400 (EDT)
Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E85di-0007HS-35 for secmech@ietf.org; Wed, 24 Aug 2005 20:30:43 -0400
Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1E85dC-000M6z-9t; Wed, 24 Aug 2005 20:30:10 -0400
Received: by internaut.com (Postfix, from userid 1000) id 7A05860DDC; Wed, 24 Aug 2005 17:30:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id 692A660DD8; Wed, 24 Aug 2005 17:30:09 -0700 (PDT)
X-Mail-Handler: MailHop Outbound by DynDNS.org
X-Originating-IP: 67.182.139.247
X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information)
X-MHO-User: aboba
Date: Wed, 24 Aug 2005 17:30:09 -0700 (PDT)
From: Bernard Aboba <aboba@internaut.com>
To: Charles Clancy <clancy@cs.umd.edu>
Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges
In-Reply-To: <430D0D2B.8050405@cs.umd.edu>
Message-ID: <Pine.LNX.4.61.0508241724080.26080@internaut.com>
References: <43074F76.8000604@cs.umd.edu> <20050822044255.GC27685@isc.upenn.edu> <Pine.GSO.4.60.0508220801430.1114@ismene> <35850EE42DFD2824F0DDBBC8@cumulus> <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>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
X-Mailman-Approved-At: Wed, 24 Aug 2005 23:52:19 -0400
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

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

"AAA Key Management" (draft-housley-aaa-key-mgmt-00.txt) talks about 
preventing cascading vulnerabilities.  One of the requirements is that 
compromise of one NAS not compromise long-term credentials. 

Providing a cleartext password to a NAS seems like it would violate that 
requirement. 

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