Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges

Jari Arkko <jari.arkko@piuha.net> Thu, 25 August 2005 13:53 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8IAG-00082y-FZ; Thu, 25 Aug 2005 09:53:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8IAF-00082t-TT for secmech@megatron.ietf.org; Thu, 25 Aug 2005 09:53:08 -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 JAA18323 for <secmech@ietf.org>; Thu, 25 Aug 2005 09:53:05 -0400 (EDT)
Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8IAl-0003uY-Np for secmech@ietf.org; Thu, 25 Aug 2005 09:53:41 -0400
Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 05EAF89852; Thu, 25 Aug 2005 16:52:56 +0300 (EEST)
Message-ID: <430DCD44.3060703@piuha.net>
Date: Thu, 25 Aug 2005 16:53:08 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Nicolas Williams <Nicolas.Williams@sun.com>
Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges
References: <Pine.GSO.4.60.0508221008260.1174@ismene> <1DCACCAC04655B3AFE9733A8@cumulus> <Pine.GSO.4.60.0508221047001.1307@ismene> <20050822154044.GE7789@binky.Central.Sun.COM> <430CA545.3020109@uni-tuebingen.de> <Pine.LNX.4.61.0508241113420.16086@internaut.com> <20050824213010.GO10174@binky.Central.Sun.COM> <Pine.LNX.4.61.0508241436250.21720@internaut.com> <430D0D2B.8050405@cs.umd.edu> <Pine.LNX.4.61.0508241724080.26080@internaut.com> <20050825041350.GV10174@binky.Central.Sun.COM>
In-Reply-To: <20050825041350.GV10174@binky.Central.Sun.COM>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Content-Transfer-Encoding: 7bit
Cc: secmech@ietf.org, Bernard Aboba <aboba@internaut.com>
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

Nicolas Williams wrote:

>So, there could (should?) be a standard framework for transporting key
>material from the EAP server to the NAS, yes?  Is this covered in the
>EAP key management I-D?  Or does every EAP method have to provide its
>own EAP-server-->NAS key transport protocol?
>  
>
EAP keying framework explains how the system works
regarding methods, eap, clients, nases, an authentication
servers. It also analyses the security properties. But the
actual key transport is defined in the AAA space. There's
only one proposed standard for this (Diameter EAP), and
one old vendor-specific attribute for RADIUS.

So, from the point of view of the methods, they just export
a key, and AAA will transport it to the NAS.

--Jari


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