Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges

Bernard Aboba <> Thu, 25 August 2005 03:52 UTC

Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1E88mr-0001Nz-Or; Wed, 24 Aug 2005 23:52:21 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1E85dJ-00030w-0n for; Wed, 24 Aug 2005 20:30:17 -0400
Received: from (ietf-mx []) by (8.9.1a/8.9.1a) with ESMTP id UAA05913 for <>; Wed, 24 Aug 2005 20:30:15 -0400 (EDT)
Received: from ([] ident=mailnull) by with esmtp (Exim 4.43) id 1E85di-0007HS-35 for; Wed, 24 Aug 2005 20:30:43 -0400
Received: from ([] by with esmtpa (Exim 4.51) id 1E85dC-000M6z-9t; Wed, 24 Aug 2005 20:30:10 -0400
Received: by (Postfix, from userid 1000) id 7A05860DDC; Wed, 24 Aug 2005 17:30:09 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 692A660DD8; Wed, 24 Aug 2005 17:30:09 -0700 (PDT)
X-Mail-Handler: MailHop Outbound by
X-Report-Abuse-To: (see for abuse reporting information)
X-MHO-User: aboba
Date: Wed, 24 Aug 2005 17:30:09 -0700 (PDT)
From: Bernard Aboba <>
To: Charles Clancy <>
Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges
In-Reply-To: <>
Message-ID: <>
References: <> <> <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> <> <> <20050824213010.GO10174@binky.Central.Sun.COM> <> <>
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
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security mechanisms BOF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

> 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 

"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 

SECMECH mailing list