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

[Stefan Winter <[e-mail]>]

Hi,

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

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

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,
>    it is cost in large-scale upgraded deployment."

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.

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

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.

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

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.

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

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

> 
>> 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]
> 
> _______________________________________________
> 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]