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
- [radext] FW: New Version Notification for draft-x… Xueli
- Re: [radext] FW: New Version Notification for dra… Stefan Winter
- Re: [radext] FW: New Version Notification for dra… Bernard Aboba
- Re: [radext] FW: New Version Notification for dra… Behcet Sarikaya
- Re: [radext] FW: New Version Notification for dra… Xueli
- Re: [radext] FW: New Version Notification for dra… Sam Hartman
- Re: [radext] FW: New Version Notification for dra… Xueli
- Re: [radext] FW: New Version Notification for dra… Sam Hartman