Subject: Re: PANA security requirements

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 4 Mar 2002 13:03:26 -0500

On Thu, Feb 28, 2002 at 07:38:21PM -0500, George Tsirtsis wrote:
> All,
> 
> I have been trying to understand the security requirements for PANA and have
> been talking to a couple of security people in my company. Here is where I
> am at the moment.
> 
> The requirements draft says that we should be able to guard against "blind
> masquerading" attacks and the protection should be similar to that of TCP
> SYN attacks.
> >From the draft:
> "  PANA MUST be robust against a class of DoS attacks such as blind
> masquerade     
>    attacks through IP spoofing that swamp the PAA in 
>    spending much resources and prevent legitimate clients' attempts of 
>    network access. The required robustness is no worse than that for 
>    TCP SYN attack. "
> 
> I fail to understand what the requirement is. One can not really prevent TCP
> SYN attacks...unless it runs over a secure channel e.g.: you only accept
> IPSECed packets. This is not acceptable in PANA i.e.: we can not assume a
> secured channel because PANA's purpose is to authenticate a user and
> potentially generate session keys.
> 
> Furthermore, employing a cookie (as has been suggested) to protect against
> DoS attacks may be a false promise. The process of generating and agreeing
> cookies may themselves provide opportunity for DoS attacks. i.e.: an
> attacker can send a large number of cookie establishment requests. So, a
> cookie only makes sense if the process that you try to protect is
> *significantly* more computational and expensive! This is why ISAKMP is
> using cookies as far as I can tell.
> 
> I do not understand why PANA needs anything similar. In particular, if EAP
> is used, as a number of proposals suggest, I think cookies at the PANA layer
> are useless. This is because the need for a cookie is dictated by the
> complexity of the EAP method that it is chosen, as I indicate above. If the
> chosen method needs cookies or any other protection, then the method itself
> is likely to employ them. e.g.: if you run TLS over EAP over PANA, what
> would you need to protect at PANA layer on top of what TLS is designed to
> protect?

If EAP-TLS message exchange always occurs only between PaC and PAA, I
agree with you.  On the other hand, if EAP-TLS messages are carried
through a AAA infrastructure, the AAA infrastructure is subject to a
blind masquerading attack if the very first EAP message (EAP
Response/Identity message) is allowed to unconditionally enter the AAA
infrastracture throuth the PAA without letting the PAA locally perform
a cookie-like reachability check for the originating node of a PANA
message.  I think 802.1X has this problem.  This may be also a topic
of EAP BoF.

Yoshihiro Ohba

> 
> Please let me know if I am totally off the mark here...I am still working on
> this but I thought to let you know of my current thoughts in case I have
> misunderstood something.
> 
> Regards
> George
> 
>