Subject: Re: [AAA-WG]: Diameter vulnerability to connection depletion DoS attacks

From: David Mitton <[email-masked]>
Date: Mon, 02 Jun 2003 16:25:02 -0400

Comments are embedded:

On 6/2/2003 08:32 PM +0200, Floroiu John wrote:

>Hi,
>
>AAA infrastructures  exhibit an obvious vulnerability to connection
>depletion attacks and in this context authenticating mobile hosts in a
>wireless hotspot, for instance, rises serious security concerns.
>
>The cause as well as a possible solution are briefly described below.
>
>Any comments would be greatly appreeciated.
>
>John.
>
>
>AAA clients, typically running on network access routers, create an AAA
>session for each authentication request they send to an AAA server. This
>contradicts the basic requirement an authentication protocol should
>meet, namely, avoiding as much as possible any resource (memory, CPU) to
>be allocated until the client is proved to be authentic.

This is not true.  Diameter clients should only create one transport 
session for any given authentication server.   Diameter sessions should be 
multiplexed over that session.   Section 2.5 of the Base explains some of this,
Section 5 explains how peer connections are established.

>The connection depletion problem is even more general because it
>ultimately affects all AAA agents located along the path between an AAA
>client and an AAA server. The reason is that all intervening AAA agents
>(even relay agents) are required to match the AAA answers against AAA
>requests (draft-ietf-aaa-diameter-12.txt section 6.2.2).
>
>Since no solution is provided to this problem in the current Diameter
>specification, here is the one I suggest.

You have overlooked the transport method as described.

>For AAA clients, the solution would be to create a AAA session only as
>result to receiving an (positive) AAA answer.

The AAA client still must hold the context of any AAA attempt, or it won't 
know what to do with the response when it receives it.  The request 
will///must be attempted via a real resource, it that resource will be held 
during the resolution of this request.  For example a NAS has a port.  An 
802.1x client has a virtual or physical port.

>Additionaly,
>* the AAA server must include in the answer all those attributes
>   specified in the request the AAA client requires in order to
>   consistently setup the AAA session;

huh?  too vague

>* the AAA client must compute a hash over those fields contained in the
>   request that uniquely and consistently identify a session and a local
>   timestamp, using a local key. The hash must be appended to the request
>   and the AAA server is required to echo the hash along with the answer.
>(see also "Stateless connections", T. Aura, P. Nikander, ICIS 1997).

This is beginning to sound like a RADIUS authenticator.

>AAA agents, in turn, would route the answers only based on the
>Route-Record AVPs, which must be appended by all relay and proxy agents
>(draft-ietf-aaa-diameter-12.txt 6.1.8), without matching the answers
>against the requests. This task will be accomplished by the AAA client
>(and AAA server implicitly).
>
>---

John,

All said, any AAA client or like implementation will have a finite set or 
resources and, yes, they can be exhausted.  This is a real world 
implementation concern, but I'm not sure that's a wire protocol issue, but 
more of a memory size and admission rate control issue.

Wireless access points have limits on the number of associated stations 
that would have to be factored into any robust implementation.  The AID 
table is so large, and there are errors for too busy or resources exceeded.

I'm not sure I'm convinced there is a problem here to be solved at the 
protocol level.

Dave.

---

From: [email-masked] (Floroiu John)
Date: Tue, 3 Jun 2003 10:55:53 +0200

David,

Thanks for the reply!

I actually used the term "connection depletion" in a more general
context, it is my fault for not being more specific. I didn't
necessarily refer to TCP related connection depletion attacks (I fully
agree with your comment regarding "connections vs. sessions"), but to
whatever requires a state to be maintained at a stage when the client
hasn't been yet authenticated. And this is demonstrated throughout
section 8.1 by the presence of state "Pending" in the client's state
machine (both stateless and stateful). 

More comments inline...

[...]
> You have overlooked the transport method as described.

(Pls. also see my comment above). This assertion regarding the AAA
agents was justified in particular by the fact that the hop-by-hop
identifier (on the incoming TCP connection) must be stored for each
request that is forwarded, and restored in the corresponding answer.

> 802.1x client has a virtual or physical port.

This kind of information is what the AAA client must append to request
and the AAA server must echo back in the answer, see first bullet below.

> >  consistently setup the AAA session;

Well, this really depends on the application. The NAS port you mentioned
above is one example. In Mobile IP for instance it may be the care-of
address. The Session-Id, App-Id, Origin Host/Realm, Destination
host/Realm are also part of the context but these will be included
anyway.

> This is beginning to sound like a RADIUS authenticator.

Possibly, I am not aware about how Radius authenticators are computed.
This technique is however widely spread. JFK for instance also uses it
and the authors of the above mentioned paper proposed it to be extended
to ISAKMP as well (ISAKMP doen't use it though, and this is the reason
why some people consider it "harmful").

> table is so large, and there are errors for too busy or resources exceeded.
 
I agree there might be physical limitations and I am not aware how
different wireless technologies allocate "channels" or "ports" (and
especially whether they are bound to the MAC address, for instance).
The problem as I see it, however, is that one won't be confronted with
thousands of attackers trying to attach to an access point, but with
only one, that uses one physical access port but injects thousands of
faked authentication requests (possibly spoofing MAC and IP addresses) 

> I'm not sure I'm convinced there is a problem here to be solved at the 

Myself I would incline to design authentication protocols as robust as
possible and ensure that at least all currently known threats are somehow
addressed. Anyway, thanks a lot for your comments.

John.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 3 Jun 2003 07:53:20 -0400

Hi,

> faked authentication requests (possibly spoofing MAC and IP addresses) 

draft-ietf-pana-pana-00.txt is taking this attack into account by
using a stateless cookie mechanism, and a different mechanism is also
being discussed in the PANA WG.  You may want to check
http://danforsberg.info:8080/pana-issues/issue15.

I think dealing with this kind of attack is a design or implementation
issue of any AAA front-end protocol such as 802.1X and PANA, but not
necessarily an issue of Diameter or RADIUS.

> addressed. Anyway, thanks a lot for your comments.

Yoshihiro Ohba