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

[Stefan Winter <[e-mail]>]

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.

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