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

From: Xueli <[email-masked]>
Date: Fri, 12 Jul 2013 03:22:32 +0000

Hi,

There is a new version for RADIUS Extensions for Key Management in WLAN network.

It is a general case that authenticator is deployed on gateway instead of AC. So In this scenario, 
the encryption/decryption node  can't obtain Pairwise Master Key (PMK) information during Extensible
Authentication Protocol (EAP) procedure, it is not sufficient to
achieve traffic encryption/decryption requirement in Wireless Local Area Network (WLAN) network.

This document analyzes the requirement and issue for key management
that has arisen so far during authentication process in WLAN network.
Meanwhile, the control messages for key management are defined.

This drat is updated with China-telecom as co-author.
Your comments are appreciated. 

BR
Li

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Friday, July 12, 2013 11:16 AM
>To: Xueli; Bo Gao
>Subject: New Version Notification for draft-xue-radext-key-management-01.txt
>
>
>A new version of I-D, draft-xue-radext-key-management-01.txt
>has been successfully submitted by Li Xue and posted to the
>IETF repository.
>
>Filename:	 draft-xue-radext-key-management
>Revision:	 01
>Title:		 RADIUS Extensions for Key Management in WLAN network
>Creation date:	 2013-07-12
>Group:		 Individual Submission
>Number of pages: 12
>URL:
>http://www.ietf.org/internet-drafts/draft-xue-radext-key-management-01.txt
>Status:
>http://datatracker.ietf.org/doc/draft-xue-radext-key-management
>Htmlized:
>http://tools.ietf.org/html/draft-xue-radext-key-management-01
>Diff:
>http://www.ietf.org/rfcdiff?url2=draft-xue-radext-key-management-01
>
>Abstract:
>   It is a general case in operators networks that Authenticator is
>   deployed on Service Gateway (SGW) to avoid overload on the Access
>   Controller (AC).  In this scenario, the encryption/decryption node
>   can't obtain Pairwise Master Key (PMK) information during Extensible
>   Authentication Protocol (EAP) procedure, it is not sufficent to
>   achieve traffic encryption/decryption requirement in Wireless Local
>   Area Network (WLAN) network.
>
>   This document analyzes the requirement and issue for key management
>   that has arisen so far during authentication process in WLAN network.
>   Meanwhile, the control messages for key management are defined.
>
>
>
>
>The IETF Secretariat

---

From: Stefan Winter <[email-masked]>
Date: Fri, 12 Jul 2013 08:39:15 +0200

Hello,

> Your comments are appreciated. 

When you submitted -00, you got substantial criticism as per the use
cases for this document; the approach taken to offload the authenticator
function to the SGW was seen as a rather odd move.

Now, in -01, you don't really react to this; the only statement in that
direction I see is that you repeatedly make the assertion that "It is a
general case in operators networks".

I simply doubt that this is generally true; merely making an unbacked
assertion that it is so doesn't make it true.

I also can't help but notice that many of your normative references are
old and obsolete.
* For key exchange, you reference an unapproved draft of IEEE-802.11i!
All of the features from that draft are meanwhile part of IEEE
802.11-2012 (and I hope you don't implement an old draft version in your
products!).
* The next reference is the IEEE 802.1X version from 2001 - it has two
successors meanwhile.
* RFC3576 is obsoleted by RFC5176. You mention both in the normative
references; the main text uses the Authenticator field from 3576, but
the type definition from 5176. That's probably an oversight; the
calculation of Authenticator hasn't changed between the two revs.

Your security considerations are very inadequate. You simply state that
the link between SGW and AC must be secure. From my (skimming)
understanding of the draft, these two entities are not typically located
inside the same premises, right? If they aren't, simply assuming
securtiy on the link blindly is an extremely bad idea. IMHO, not
protecting the keys and sending them in the clear is a no-go.

In the same section, you state roughly "Oh, if you need security, use
IPSec!" - which is too superficial a statement to be useful; you should
at least discuss how the IPSec endpoints are supposed to negotiate IPSec
keying material to be able to communicate confidentially.

BTW, if I recall correctly your draft was motivated by the "fact" (or so
you presented it) that changing the AC to take over the authenticator
role is too costly in terms of implementation or computing power. Now in
security considerations, you generously recommend to implement the
entire IPSec stack on the AC. I would argue that it's easier to
implement the authenticator function of IEEE 802.1X than it is to
implement IPSec.

The same section also suggests MD5 encryption/decryption. Here I am
completely lost. The KoA and KoA ACK/NAK messages are RADIUS packets,
right? As such they are always making use of the MD5 shared secret for
integrity checks; if you want to protect the 802.11 keying material then
you could use encrypted attributes with the same shared secret (that's
the way how User-Password gets encrypted). With little to no additional
implementation cost. If that's what you want - don't put a half-sentence
into security considerations. *Write in the spec itself that the
attribute is to be encrypted*.

BTW, even if you do write that in the spec, you'd still get a beating
for suggesting MD5 RADIUS crypto in 2013. This encryption method is not
contemporary.

Greetings,

Stefan Winter

-- 
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: Xueli <[email-masked]>
Date: Fri, 12 Jul 2013 10:17:21 +0000

Hi, Stefan

Thanks for your comments..
And please see my reply in line.

BR
Li 

>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of Stefan Winter
>Sent: Friday, July 12, 2013 2:39 PM
>To: [email-masked]
>Subject: Re: [radext] FW: New Version Notification for 
>draft-xue-radext-key-management-01.txt
>
>Hello,
>
>> There is a new version for RADIUS Extensions for Key Management in 
>> WLAN
>network.
>>
>>
>> It is a general case that authenticator is deployed on gateway 
>> instead of AC. So In this scenario, the encryption/decryption node  
>> achieve traffic
>encryption/decryption requirement in Wireless Local Area Network (WLAN) 
>network.
>>
>cases for this document; the approach taken to offload the 
>authenticator function to the SGW was seen as a rather odd move.

>assertion that it is so doesn't make it true.

[xueli] I appreciated the comments to scenario to offload the authenticator function to SGW.
There are two reasons, which I clarified the scenario in the document version 01 as :
   "In EAP framework, SGW could act as the Authenticator instead of AC
   because of several reasons.  First of all, a powerful AC that
   aggregates the Authenticator function is not a appreciated choice for
   some operators. There are large numbers of AC devices in the operators
   existing network.  The Authentication Server (AS) will overload the communication with large
   numbers of AC devices if ACs acts as the Authenticator.  On the other
   hand, SGW MUST support the RADIUS proxy function when AC acts as the
   Authenticator in EAP framework.  In this scenario, both SGW and AC
   should be responsible for authentication procedure.  For operators,
   it is cost in large-scale upgraded deployment."

Meanwhile, this requirement is also mentioned in the draft " http://tools.ietf.org/html/draft-cao-capwap-eap-00"

It is described as
"AR acts as authenticator in the EAP framework.  After authentication, the AR
   receives the EAP keying message for the session.  But AC is supposed
   to delieve these keying messages to the AP, and AR has no standard
   interface to ship them to the AP or the AC.  This is unacceptable in
   the scenario of EAP-based auto-authentication.
" AR is the access router. 

>802.11-2012 (and I hope you don't implement an old draft version in 
>your products!).

[xueli] thanks a lot. 
802.11i is already approved in 2004. I am not sure why you say it is an unapproved draft.
For other references, I will update. 

>understanding of the draft, these two entities are not typically 
>located inside the same premises, right? If they aren't, simply 
>assuming securtiy on the link blindly is an extremely bad idea. IMHO, 
>not protecting the keys and sending them in the clear is a no-go.
[xueli] I don't think I mentioned that the link between AC and SGW is secure. 
I have already recognized the key transported in the link must be encrypted. 
>at least discuss how the IPSec endpoints are supposed to negotiate 
>IPSec keying material to be able to communicate confidentially.

[xueli] I totally agree with you and this part of work will be presented in the next version. 
>
>BTW, if I recall correctly your draft was motivated by the "fact" (or 
>so you presented it) that changing the AC to take over the 
>authenticator role is too costly in terms of implementation or 
>computing power. Now in security considerations, you generously 
>recommend to implement the entire IPSec stack on the AC. I would argue 
>that it's easier to implement the authenticator function of IEEE 802.1X than it is to implement IPSec.

[xueli] I see. I just give a possible solution to address the security problem. I agree that there could be more optimal solutions. 
I would like to mention during the meeting and collect comments from the security guys. Is that fair enough?

>integrity checks; if you want to protect the 802.11 keying material 
>then you could use encrypted attributes with the same shared secret 
>(that's the way how User-Password gets encrypted). With little to no 
>additional implementation cost. If that's what you want - don't put a 
>half-sentence into security considerations. *Write in the spec itself 
>that the attribute is to be encrypted*.
>
[xueli] Yes, that is what I want to do.. I will clarify it.

>for suggesting MD5 RADIUS crypto in 2013. This encryption method is not 

[xueli] Thank you for your advice. 
Security is important part of this work. 
It is my plan to go into technique details and give a more concrete security solution by the next IETF meeting. 

>de la Recherche 6, rue Richard Coudenhove-Kalergi
>L-1359 Luxembourg
>
>Tel: +352 424409 1
>Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Fri, 12 Jul 2013 13:31:20 +0200

Hi,

>    numbers of AC devices if ACs acts as the Authenticator.

This is the point where you lost me. Why is it "not appreciated" by
operators?

Sometimes you need to add new functionality to a device; the vendor
writes code and provides firmware updates for these devices. Deployers
apply the firmware update. That is a normal part of day-to-day
operations in a network.

I don't understand why you go out of your way to define an entire new
*protocol* just for the convenience of saving a firmware update in a
fleet of equipment. (And not even that is true, see below)

At other places you write that it's difficult to implement in the
authenticators and more convenient to do it in a central place. My only
reply to this: yes, it's work and it needs to be done. Get over it. I
don't see how the hassle of defining a new protocol - which also needs
to get implemented, and firmware updated to support it - is in any way
easier or more useful.

I also don't buy that the AC authentication traffic will "overload the
communication". AAA traffic is only an insignificant portion of traffic
of an edge network - the payload generated by the user after
authenticating is many orders of magnitude higher. If you are concerned
about AAA packets getting lost if the link gets full, use traffic
priorisation, i.e. put the AAA traffic in a separate queue which has
priority over normal IP payloads. That's how "everyone else" does it as
well.

>  On the other
>    should be responsible for authentication procedure.

I also don't see why the SGW needs to be a RADIUS proxy. If the
authenticators are implemented correctly, they implement the RADIUS
client side and can be configured to contact any RADIUS server they
want. If traffic is administratively *wanted* to flow by the SGW, then
yes, the SGW must also implement the RADIUS protocol. If not, the
authenticators can talk to the real target, the authentication server,
on their own. So this is not a protocol problem, it is just a deployment
choice.

>  For operators,

Your KoA is also new code that both the ACs and the SGW need to
understand. An upgrade is necessary either way; so your argument is null.

> 802.11i is already approved in 2004. I am not sure why you say it is an unapproved draft.

You should read your own draft again. I *quoted* you with the word
Unapproved. If I may *quote* your Normative References section:

[IEEE-802.11i]
              , "Institute of Electrical and Electronics Engineers,
              "Unapproved Draft Supplement to Standard for
              Telecommunications and Information Exchange Between
              Systems-LAN/MAN Specific Requirements -Part 11: Wireless
              LAN Medium Access Control (MAC) and Physical Layer (PHY)
              Specifications: Specification for Enhanced Security" "",
              September 2004.

If you don't want to talk about an unapproved draft from 2004, then ...
don't. Just update your text.

> I have already recognized the key transported in the link must be encrypted. 

You write that security must be guaranteed. Then you state that "if
there is a security requirement". Why the "if"? - security *is* a
requirement, you are transporting secrets. The first sentence of the
section says that itself.

You don't say anything about a MUST encryption. You hide it behind an
"if" conditional. I understood this such as that there are cases where
the if isn't true; which means there is no encryption on the wire. If
you still guarantee security in that case, that can only be because the
link in itself is for some unexplained reason secure.

I suggest you fix your wording and be *much* more verbose.

> It is my plan to go into technique details and give a more concrete security solution by the next IETF meeting. 

It is up to the chairs to distribute speaking time. I for one would
welcome if we could first clear up the very first topic area: what is
the *use* of your designed protocol. As I wrote earlier in my mail I see
many reasons why your thinking that the authenticator function should be
split and put into the SGW is flawed in the first place. If it is, there
is no need to further discuss technical details of the draft.

Greetings,

Stefan Winter

> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext
> 

Tel: +352 424409 1
Fax: +352 422473

---

From: "gaobo" <[email-masked]>
Date: Fri, 12 Jul 2013 22:17:35 +0800

I supplement my view as follows:
For the traditional operators, WLAN network is stacked in the existing broadband network. SGW is responsible for the broadband user authentication, address assignment, user management and other functions. In the WLAN DHCP+Portal user authentication, SGW is responsible for the allocation of WLAN address, user authentication and user management, and AC is only responsible for radio resource management and AP management. For EAP authentication, AC as the authentication point, SGW acts as Radius Proxy. At the same time, SGW is responsible for the user EAP address allocation and user management. This configuration enables the network complex, and maintenance of network management becomes complex. If the SGW acts as EAP authentication, the network becomes simple, but we need to solve the PMK exchange between SGW and AC.
By the way, SGW acts as the EAP authentication, for the operators more than one option.
Thanks!
   
   Bo Gao
   China Telecom
   No. 1835, South Pudong Road
   Shanghai  200122
   China

发件人： Xueli 
发送时间： 2013-07-12  18:17:32 
收件人： Stefan Winter; [email-masked] 
抄送： gaobo 
主题： RE: [radext] FW: New Version Notification fordraft-xue-radext-key-management-01.txt 
 
Hi, Stefan
[xueli] thanks a lot.