Subject: [seamoby] RE: Authentication & Authorization "in-the-large" was Re: [seamob y] ct problem statement

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Tue, 12 Jun 2001 17:08:48 -0500

of course. My intention was not to kill the whole thread, just the
definition wars that are going on :)

MN>> Pat, Ok so the thread lives on... Thanks, I cut a lot
of text for readability.

> 
> 1-How to prevent a pre-authenticated AR from doing unauthorized CT DoS.

I would claim that such events are unlikely to happen. When a user wants to
move
from one service area to another, the spectrum will be overlapping. The
operators
of these networks will allow/disallow CT between the routers handling these
service areas. If they permit it, then will ensure that secure communication
is available between them.

MN>> I am not quite sure I understand your point. I am not sure
how spectrum overlap comes in?
Anyway, seems like you are asuuming one and the same operator handling
both oldAR and newAR. What if they belong to two different operators.
And then one operator decides to mess with the other one, by having
its ARs that are already authenticated to its neighbor ARs (from the
other operator) do DoS, i.e.

OP1 (AR1) does a DoS on OP2(AR2) although AR1-AR2 had a pre-authentication.

Isn't that possible?

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 12 Jun 2001 16:32:23 -0700

> how spectrum overlap comes in?

Sorry, what I meant was that the service areas are close enough that it
makes sense to CT. If there is a long no-service time between both service
areas, then CT doesn't really make that much sense, right?

> both oldAR and newAR.

I didn't mean to assume this.

>  What if they belong to two different operators.

Right, so my point is that if CT is to occur between two ARs, they
MUST know about each other to begin with, right? If so, then a pre-existing
SA exists between the ARs, and security will ensure that no DoS attack
can exist.

Actually, there is one way to do a DoS attack that has just come to mind,
and involves a rogue mobile sending bogus L2 messages faking handoffs, but
this doesn't just affect CT, as it would also affect the handoff procedures,
and this only exists on wireless links that are not authenticated.

> OP1 (AR1) does a DoS on OP2(AR2) although AR1-AR2 had a pre-authentication.

That is not really an attack that we need to consider. Once you trust one side
of a conversation, there isn't a whole lot that you can do to protect
yourself against bad behavior (well, a good implementation can protect itself
properly).

PatC