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

[Xueli <[e-mail]>]

Hi Stefan



Thanks a lot for your comments.



Actually, the issue is when the authenticator is in access router instead of AC, the PMK should be announced to AC.

Please see the procedure shown as follow

[cid:image003.jpg@01CE2D53.74DAE0C0]



Unfortunately, in exiting authentication procedure, authenticator is the only node which can obtain the derived PMK,

except of STA and AS. In addition, authenticator is not always deployed collocated on ecryption/decryption node, as AC.

That is to say, WTP/AC cannot implement STA's traffic encryption/decryption because of lacking the PMK information.

In this case, mechanism is needed to inform the PMK to ecryption/decryption node, WTP or AC in WLAN.



The Radius extension is defined in this draft for key announcement from authenticator(GW) to AC.



I hope this clarification is helpful.



BR

Li



>-----Original Message-----

>From: [e-mail] [mailto:[e-mail]] On Behalf Of

>Stefan Winter

>Sent: Friday, March 29, 2013 9:28 PM

>To: [e-mail]; Xueli

>Subject: Re: [radext] FW: New Version Notification for

>draft-xue-radext-key-management-00.txt

>

>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: [e-mail] [mailto:[e-mail]]

>>> 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-0

>>> 0.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

>> [e-mail]

>> 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: [phone]

>Fax: [phone]