RE: [SECMECH] Framework Bindings Vs. Mechanism Bridges

Charles Clancy <> Fri, 26 August 2005 14:49 UTC

Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1E8fWI-0005EB-BR; Fri, 26 Aug 2005 10:49:26 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1E8fWG-0005BX-3B for; Fri, 26 Aug 2005 10:49:24 -0400
Received: from (ietf-mx []) by (8.9.1a/8.9.1a) with ESMTP id KAA24655 for <>; Fri, 26 Aug 2005 10:49:22 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.43) id 1E8fWz-0000ky-H6 for; Fri, 26 Aug 2005 10:50:10 -0400
Received: from ismene ( []) by (8.12.10/8.12.5) with ESMTP id j7QEmkfD026002; Fri, 26 Aug 2005 10:48:56 -0400 (EDT)
Date: Fri, 26 Aug 2005 10:43:27 -0400 (EDT)
From: Charles Clancy <>
X-X-Sender: clancy@ismene
To: Josh Howlett <>
Subject: RE: [SECMECH] Framework Bindings Vs. Mechanism Bridges
In-Reply-To: <191B6A09CAEEC043419A68E5@cumulus>
Message-ID: <Pine.GSO.4.60.0508261036350.16020@ismene>
References: <7210B31550AC934A8637D6619739CE6905C8BEEC@e2k-sea-xch2.sea-alpha.> <> <191B6A09CAEEC043419A68E5@cumulus>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Cc:, Bernard Aboba <>
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security mechanisms BOF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

On Fri, 26 Aug 2005, Josh Howlett wrote:

> --On Thursday, August 25, 2005 23:40:04 -0700 Bernard Aboba 
> <> wrote:
>> In all the EAP Kerberos proposals I've seen the method is terminated on
>> either the NAS or AAA server, but not both.  But in any scenario, the
>> NAS still needs to support Kerberos, in order to validate the "network
>> access" service ticket.
> Just to clarify - it would be possible for the AAA server to authenticate 
> against the KDC and return an EAP-Success to the NAS as per other EAP types, 
> without the NAS needing to understand Kerberos. However, the NAS would need 
> to understand Kerberos in order to allow a service ticket to be used for, ie, 
> fast reconnect (...which is undesirable for secret hygene).

Using NAS-terminated Kerberos for fast handoff/reconnect is probably not a 
good idea due to the round trips, unless the NAS service ticket could be 
preemptively acquired.

I think EAP-Kerberos should be terminated at the AAA server.  Your service 
ticket is for "network access", not a particular NAS.  The key contained 
within the service ticket could be used to bootstrap the traditional EAP 
keying.  If you wanted fast reconnect or fast handoff, you could build it 
into the method by computing something like:

   initial key generation:
     MK = PRF(service key, "master key", nonces)
     MSK_1 = PRF(MK, "master session key", nonces)

     MSK_2 = PRF(MK, "new master session key", MSK_1 + nonces)

Then the NAS doesn't need to know anything about Kerberos.

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

SECMECH mailing list