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

From: Xueli <[email-masked]>
Date: Thu, 28 Mar 2013 02:12:41 +0000

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.

BR
Li
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>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

---

From: Stefan Winter <[email-masked]>
Date: Fri, 29 Mar 2013 14:27:52 +0100

Hello,

> 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

> _______________________________________________
> radext mailing list
> [email-masked]
> 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

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 29 Mar 2013 14:35:33 -0700

[BA] Also, RFC 5247 desribes the security issues that can arise when splitting the AP function. 
 Stefan Winter said: 
 
"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:"

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 29 Mar 2013 18:13:40 -0500

Hi Stefan, Bernard,

This draft is not about split MAC, local MAC of CAPWAP protocol (in the
draft those are called Fit AP, Fat AP, quite strangely).

This draft is about the case where IEEE 802.11i authenticator is moved from
the AC of CAPWAP to the access router which is not at the same time the AC.

In that case the keys, e.g. PMK has to be transferred to the AC. The
solution is described in Section 5 which uses CoA type of signaling (as in
RFC3576).  This requires some RADIUS extensions

Hope this helps.

Regards,

Behcet

---

From: Xueli <[email-masked]>
Date: Sat, 30 Mar 2013 06:32:52 +0000

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

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

>From: [email-masked] [mailto:[email-masked]] On Behalf Of

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

>To: [email-masked]; Xueli

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

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

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

>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"?).

>>> Subject: New Version Notification for

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

>>> has been successfully submitted by Li Xue and posted to the IETF

>>> repository.

>>> http://www.ietf.org/internet-drafts/draft-xue-radext-key-management-0

>>> 0.txt

>>>   and 4-way handshake are used between STA and Authenticator to

>derive,

>Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de

>la Recherche 6, rue Richard Coudenhove-Kalergi