IETF Logo Mail Archive

RE: [SECMECH] Framework Bindings Vs. Mechanism Bridges

Bernard Aboba <aboba@internaut.com> Fri, 26 August 2005 15:15 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8fv2-0003SH-8F; Fri, 26 Aug 2005 11:15:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8fv0-0003S6-Mm for secmech@megatron.ietf.org; Fri, 26 Aug 2005 11:14:58 -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 LAA25981 for <secmech@ietf.org>; Fri, 26 Aug 2005 11:14:56 -0400 (EDT)
Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8fvk-0001bQ-AG for secmech@ietf.org; Fri, 26 Aug 2005 11:15:45 -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 1E8fux-0000CW-Jh; Fri, 26 Aug 2005 11:14:55 -0400
Received: by internaut.com (Postfix, from userid 1000) id D3A962469D; Fri, 26 Aug 2005 08:14:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id C3DBD2469A; Fri, 26 Aug 2005 08:14:54 -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: Fri, 26 Aug 2005 08:14:54 -0700
From: Bernard Aboba <aboba@internaut.com>
To: Charles Clancy <clancy@cs.umd.edu>
Subject: RE: [SECMECH] Framework Bindings Vs. Mechanism Bridges
In-Reply-To: <Pine.GSO.4.60.0508261036350.16020@ismene>
Message-ID: <Pine.LNX.4.61.0508260807091.18505@internaut.com>
References: <7210B31550AC934A8637D6619739CE6905C8BEEC@e2k-sea-xch2.sea-alpha. cisco.com> <Pine.LNX.4.61.0508252336520.5325@internaut.com> <191B6A09CAEEC043419A68E5@cumulus> <Pine.GSO.4.60.0508261036350.16020@ismene>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
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

> 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)
> 
> handoff:
> MSK_2 = PRF(MK, "new master session key", MSK_1 + nonces)
> 
> Then the NAS doesn't need to know anything about Kerberos.

This scheme allows for reuse of the initial Kerberos ticket, at the 
expense of a round-trip between the NAS and AAA server on each handoff. 

However, the Kerberos session key is no longer bound to a 
particular NAS -- this is the "Key binding" requirement in 
draft-housley-aaa-key-mgmt-00.txt.  

Also, the AAA server now needs to keep a cache of Kerberos session keys.  

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

v2.23.0 | Report a Bug | By Email