Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges

Charles Clancy <> Thu, 25 August 2005 01:29 UTC

Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1E86Yy-0005Lw-Cd; Wed, 24 Aug 2005 21:29:52 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1E86Yw-0005Lr-Ka for; Wed, 24 Aug 2005 21:29:50 -0400
Received: from (ietf-mx []) by (8.9.1a/8.9.1a) with ESMTP id VAA08220 for <>; Wed, 24 Aug 2005 21:29:49 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.43) id 1E86ZM-0000KX-9O for; Wed, 24 Aug 2005 21:30:17 -0400
Received: from [] ([]) by (sccrmhc12) with ESMTP id <20050825012841012000d7t3e>; Thu, 25 Aug 2005 01:28:42 +0000
Message-ID: <>
Date: Wed, 24 Aug 2005 21:28:21 -0400
From: Charles Clancy <>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Bernard Aboba <>
Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges
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> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security mechanisms BOF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

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

Why would the cleartext password ever end up on a NAS?

Maybe a picture would help:

EAP Client          EAP Server           KDC

     TTLS Negotiation

krb5 authentication (EAP server is passthrough)

                          TGT, service ticket

       service auth

{MK,MSK} = PRF(service key)

[ t. charles clancy ]--[ ]--[ ]
[ computer science ]-----[ university of maryland | college park ]

SECMECH mailing list