Re: [radext] FW: New Version Notification for draft-xue-radext-key-management-00.txt

Stefan Winter <stefan.winter@restena.lu> Fri, 29 March 2013 13:27 UTC

Return-Path: <stefan.winter@restena.lu>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6019D21F9410 for <radext@ietfa.amsl.com>; Fri, 29 Mar 2013 06:27:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_45=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5gViT3A2s5F for <radext@ietfa.amsl.com>; Fri, 29 Mar 2013 06:27:58 -0700 (PDT)
Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE8321F9405 for <radext@ietf.org>; Fri, 29 Mar 2013 06:27:58 -0700 (PDT)
Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 5A6D810589; Fri, 29 Mar 2013 14:27:57 +0100 (CET)
Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 4359A10581; Fri, 29 Mar 2013 14:27:57 +0100 (CET)
Message-ID: <515596D8.1000209@restena.lu>
Date: Fri, 29 Mar 2013 14:27:52 +0100
From: Stefan Winter <stefan.winter@restena.lu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: radext@ietf.org, xueli@huawei.com
References: <01FE63842C181246BBE4CF183BD159B4482A1371@NKGEML512-MBS.china.huawei.com>
In-Reply-To: <01FE63842C181246BBE4CF183BD159B4482A1371@NKGEML512-MBS.china.huawei.com>
X-Enigmail-Version: 1.5.1
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="----enig2GVSTHOAOIHPIXOLHEJDN"
X-Virus-Scanned: ClamAV
Subject: Re: [radext] FW: New Version Notification for draft-xue-radext-key-management-00.txt
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Mar 2013 13:27:59 -0000

Hello,


On 28.03.2013 03:12, Xueli wrote:
> Hi all
> 
> There is a draft to resolve the some issue raised in WLAN network.
> 
> In the authentication architecture, only STA and AS can manufacture PMK, 
> moreover, AS can only distribute PMK to Authenticator.However, if the authenticator function is not collocated
> with the encryption/decryption function, it is difficult to achieve traffic encryption/decryption in WLAN network.
> 
> The purpose of this document is to analyze the requirement and issue for key management that have arisen so far 
> during STA authentication process in WLAN network. Meanwhile, the control messages for key management are defined.
> 
> Your comments are appreciated.

You attempt to split the role of the Access Point into several
sub-entities. This is admirable, but by no means a novelty. There are
many proprietary approaches to this, but there's also already a set of
RFCs describing a standard way:

If you are interested in offloading functions of an AP into separate
sub-entities, you should also first take a look at the results of the
CAPWAP working group, whose target is to do just that. The advantage of
CAPWAP is that it has a much broader scope than "just" the keys for a
session.

RFC5415 is a good read. Section 10.1 has a "Station Configuration
Request" which transmits user session specific data from the controller
to the lightweight AP (which you call "FIT" AP in your document - did
you mean "thin" as the opposite to "fat"?).

The media-specific binding in RFC5416 goes into detail and describes how
exactly session keys are transmitted in WLAN (Sections 5.10, 6.15).

Greetings,

Stefan Winter


> 
> BR
> Li
>> -----Original Message-----
>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>> Sent: Monday, February 18, 2013 7:31 PM
>> To: Xueli
>> Subject: New Version Notification for draft-xue-radext-key-management-00.txt
>>
>>
>> A new version of I-D, draft-xue-radext-key-management-00.txt
>> has been successfully submitted by Li Xue and posted to the
>> IETF repository.
>>
>> Filename:	 draft-xue-radext-key-management
>> Revision:	 00
>> Title:		 RADIUS Extensions for Key Management in WLAN network
>> Creation date:	 2013-02-18
>> Group:		 Individual Submission
>> Number of pages: 17
>> URL:
>> http://www.ietf.org/internet-drafts/draft-xue-radext-key-management-00.txt
>> Status:
>> http://datatracker.ietf.org/doc/draft-xue-radext-key-management
>> Htmlized:
>> http://tools.ietf.org/html/draft-xue-radext-key-management-00
>>
>>
>> Abstract:
>>   In order to guarantee the security and integration of the subscriber
>>   in WLAN network, Pairwise Master Key (PMK) will be generated as an
>>   access authorization token during the mutual authentication procedure
>>   between station (STA) and authenticator server (AS).  Then, the PMK
>>   and 4-way handshake are used between STA and Authenticator to derive,
>>   bind and verify the Pairwise Transient Key (PTK), which is a
>>   collection of operational keys for security.  Also,Group Transient
>>   Key (GTK) can be derived, and is used to secure multicast/broadcast
>>   traffic.  In the authentication architecture, only STA and AS can
>>   manufacture PMK, moreover, AS can only distribute PMK to
>>   Authenticator.However, if the authenticator function is not
>>   collocated with the encryption/decryption function, it is difficult
>>   to achieve traffic encryption/decryption in WLAN network.The purpose
>>   of this document is to analyze the requirement and issue for key
>>   management that have arisen so far during STA authentication process
>>   in WLAN network.  Meanwhile, the control messages for key
>> management
>>   are defined.
>>
>>
>>
>>
>> The IETF Secretariat
> 
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext
> 


-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473