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

[Xueli <[e-mail]>]

Hi, Stefan

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

BR
Li 

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On 
>Behalf Of Stefan Winter
>Sent: Friday, July 12, 2013 2:39 PM
>To: [e-mail]
>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  
>> 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.
>
>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.

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


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

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

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

[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?

>
>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*.
>
[xueli] Yes, that is what I want to do.. I will clarify it.

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

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

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