RE: [SECMECH] Framework Bindings Vs. Mechanism Bridges

Charles Clancy <clancy@cs.umd.edu> Fri, 26 August 2005 19:24 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8jox-00076u-Rt; Fri, 26 Aug 2005 15:24:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8jow-00076l-At for secmech@megatron.ietf.org; Fri, 26 Aug 2005 15:24: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 PAA09252 for <secmech@ietf.org>; Fri, 26 Aug 2005 15:24:56 -0400 (EDT)
Received: from carrierpigeon.cs.umd.edu ([128.8.129.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8jpi-00019W-V9 for secmech@ietf.org; Fri, 26 Aug 2005 15:25:47 -0400
Received: from ismene (ismene.cs.umd.edu [128.8.126.62]) by carrierpigeon.cs.umd.edu (8.12.10/8.12.5) with ESMTP id j7QJOZfD027699; Fri, 26 Aug 2005 15:24:35 -0400 (EDT)
Date: Fri, 26 Aug 2005 15:19:15 -0400 (EDT)
From: Charles Clancy <clancy@cs.umd.edu>
X-X-Sender: clancy@ismene
To: Bernard Aboba <aboba@internaut.com>
Subject: RE: [SECMECH] Framework Bindings Vs. Mechanism Bridges
In-Reply-To: <Pine.LNX.4.61.0508261146590.23743@internaut.com>
Message-ID: <Pine.GSO.4.60.0508261458430.16020@ismene>
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> <Pine.LNX.4.61.0508260807091.18505@internaut.com> <Pine.GSO.4.60.0508261405280.16020@ismene> <Pine.LNX.4.61.0508261146590.23743@internaut.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
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

> As noted in the EAP Key Framework document, the EAP layer does not cache 
> exported EAP keying material, either on the client or the server. 
> Caching is only permitted in the lower layer (AAA is a lower layer from 
> the EAP perspective).

Ah, there was the point I missed.

> However, AAA servers today do not cache EAP keying parameters -- they 
> discard all EAP keying material (not just the transported keying 
> material) once they send the MSK to the NAS.  So asking the AAA server 
> to implement a key cache is a significant change from the existing 
> architecture.

I've implemented fast handoff using PMK caching for EAP-TLS on FreeRADIUS 
with minimal difficulty.  Your points extend beyond the functionality 
offered by my previous efforts in that it allows for an architecture where 
a NAS could contact multiple AAA servers.

> a. How does the peer know what AAA server it is dealing with?  The EAP 
> Key Framework has added the Server-ID parameter to enable the peer to 
> know this, but not all EAP methods define this parameter.  Do we want 
> fast handoff to only be supported for methods with a defined Server-ID?

Well so far we've been talking about fast handoff in EAP-Kerberos.  So, 
I'd imagine EAP-Kerberos would need to implement the Server-ID field.

Although note that my protocol sketch below doesn't require using the 
Server-ID field.

> b. How does the peer request that the NAS contact a particular AAA 
> server (either for requesting a key or validating a ticket)?  Does it 
> include the Server-ID in the message?

The EAP-Response/Identity could be formatted in some way to include the 
desired AAA server.  Personally, I say we shouldn't worry about this case. 
If someone roams to a NAS that has a different default AAA server, then 
they should reauthenticate.  This functionality could also be added later, 
if deemed necessary, since it seems outside the scope of the method, and 
would involve changes in EAP itself.

> c. How does the AAA server validate that the ticket is being used by the
> EAP peer that it granted access to?  Do we require that the peer NAI be
> the same as the Kerberos Principal name of the peer?  Do we require that
> the Server-ID be the same as the Kerberos Principal name of the AAA
> server?

Assuming the AAA server has cached the MK, I'd imagine something similar 
to:

   (Client <- Server) ID Request
   (Client -> Server) ID Response
   (Client <- Server) EAP-Krb5(fast reconn available, keyid=hash(MK),
                               A=nonce)

Then if client has keyid cached:

   (Client) {MSK,K} = PRF(A,B,MK)
   (Client -> Server) EAP-Krb5(fast reconn ACK, B=nonce, hash(A,B,K))
   (Server) {MSK,K} = PRF(A,B,MK)
   (Client <- Server) EAP-Krb5(ACK, hash(B,K))
   (Client -> Server) EAP-Krb5(ACK)
   (Client <- Server) EAP-Success
   (NAS <- Server) AAA(MSK)

Or if keyid is not found:

   (Client -> Server) EAP-Krb5(fast reconn NACK)
   (Client <-> Server) EAP-Krb5(full kerberos authentication)

> d. How does the peer know whether a particular NAS is configured to 
> connect to a AAA server from whom it has received a ticket?

I say it shouldn't know.  If the NAS connects to the right AAA server, 
then the above will happen.  Otherwise it won't.

[ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ]
[ computer science ]-----[ university of maryland | college park ]

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