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

From: "Gary Kenward" <[email-masked]>
Date: Mon, 11 Jun 2001 16:44:57 -0400

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
> Sent: Monday, June 11, 2001 3:57 PM
> To: 'Pat Calhoun'; Arthur Ross
> Cc: Charlie Perkins; Kulwinder Atwal; 'seamoby';
> [email-masked]
> Subject: [seamoby] RE: Authentication & Authorization 
> "in-the-large" was
> Re: [seamob y] ct problem statement
> 
*snip*
> 	
> 2- Why some people think authentication is not important, while
> authorization
> is central for CT.

Just to clarify this for myself: I didn't hear anyone say that
authentication
was not important. And perhaps this is where the confusion began. I thought
I heard it being stated that the mobile's authentication had to be conveyed
to
the new AR. This could be done either by moving the mobile's authentication
with the mobile's context, or by a transferrence through a trust
relationship between the two ARs (the idea being that if A trusts B and B
trust C then A should trust C?).

The latter proposal brought out a discussion of authentication between ARs,
and how the ARs within one administrative domain should have an implicit
trust, and thus "authentication between ARs was not necessary".  

I am not sure how one would mount a DOS using CT without first gaining
access to one or more of the ARs to manipulate the CT stacks. Expressed
another way, to introduce a bogus CTP stream into the network, I would
presumably have to inject the stream through the edge of the network, but
the network edges should not be allowing CTP through interfaces that talk to
other networks (or hosts), unless those networks have also established
authentication/authorization on that interface.

(In the case of an ad-hoc wireless network, the authentication of the ARs
becomes a very tricky issue, and one I still feel is outside of the scope
for CT).

The question also came up of whether the receiving AR needed to authorize
the MN for the services and service features that were supported by the
transferred context. I happen to believe that within a single administration
domain, the ARs should be assumed to be trusted entities, and the
authorization and authentication information for an MN should be transferred
as part of the context. I believe that authentication is necessary to
prevent DOS, and authorization is necessary to prevent TOS (theft of
service). Since CT happens only between AR's, in the intranet wireline case,
I don't see the need for extra "CT" security, other then that which is
usually provided when shipping this information around an administrative
domain.

I should point out that "authorization" to use a service at an AR does not
imply that the AR has the capacity to provide the service to a particular
mobile's traffic (it must have the capability, otherwise the authorization
should have failed).

I hope this makes sense.

Gary

> 
> If people cannot contribute to the CT DoS discussion, I suggest they
> do cryptography discussion to a security mailing list, before 
> Pat kills
> this thread.
> 
> We are just trying to get CT PS ready for shipping.
> 
> Thank you,
> Madjid
> 
> 
> -----Original Message-----
> From: Pat Calhoun [mailto:[email-masked]]
> Sent: Monday, June 11, 2001 2:04 PM
> To: Arthur Ross
> Cc: Pat Calhoun; Charlie Perkins; Kulwinder Atwal; 'seamoby';
> [email-masked]
> Subject: Re: Authentication & Authorization "in-the-large" was Re:
> [seamoby] ct problem statement
> 
> 
> On Mon, Jun 11, 2001 at 11:30:21AM -0700, Arthur Ross wrote:
> > Au contraire, Pat -
> 
> Je ne pense pas.
> 
> > I keep thinking that a good illustrative, prehistoric
> example/philosophical
> > model of the kind of thing I am thinking of is the ol' Unix 
> heirarchical
> > file system. Everything has a nonad [a word I just invented, meaning
> "group
> > of nine"] of priviledge flags, corresponding to all 
> possible combinations
> > of {read,modify,execute} with {owner, group, world}. In this view,
> > authentication determines which of the three categories an 
> supplicant
> > belongs to, and authorization says which of the three actions he can
> > perform. Attached are the owner and group IDs.
> 
> I wonder why this thread even exists, but I find myself 
> having to correct
> your example above. The very fact that a set of permissions 
> have been setup
> on a file is NOT authentication. Before I even get access to 
> the said files,
> there is another program, Unix login, which checks my 
> credentials, and then
> executes the shell with my user and group id. Requesting 
> access to the file
> is an authorization decision on the part of the OS. Do I have 
> access to the
> file?
> What is my user id? group id?
> 
> Obviously, we aren't going to agree on the very fundamental difference
> between
> authorization and authentication, and we can just agree to disagree.
> 
> PatC
>

---

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

-----Original Message-----
From: Phillip Neumiller [mailto:[email-masked]]
Sent: Tuesday, June 12, 2001 5:24 PM
To: 'Nakhjiri Madjid-MNAKHJI1'; 'Pat Calhoun'
Cc: Arthur Ross; Charlie Perkins; Kulwinder Atwal; 'seamoby';
[email-masked]
Subject: RE: [seamoby] RE: Authentication & Authorization "in-the-large"
was Re: [seamob y] ct problem statement

Some comments....

> Sent: Tuesday, June 12, 2001 6:09 PM
> 
> 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.

A better question is what if they belong to YOU as an individual.  I 
am really hoping that we can drive the stake into the heart of the
large telecommunications monopolies and put the control of wireless
back where it belongs, in the hands of the people.  Think about how
the world would be where everyone everywhere is laying down wireless
routers and doing so because its cheap.  Using simple calculations 
with the Shannon capacity equation the future clearly lies in super
wide bandwidth radios all inter-connected over short distances over
the surface of the Earth in a Mesh.  This of course will have the
tendency to light up a lot of that fiber that is now dark....  Don't
let the 3G propaganda drag you down.  THIS IS BOUND TO HAPPEN.  I
hope folks on this list will be some of the folks that help realize
this potential future.  

Thanks,

Phil (Pat, sorry for cross-posting to SeaMoby and WirelessInternet
but I did not start it).

MN>>Hey, I didn't look at the email list, I just replied all, I hope
I don't get the blame for this. I am out of here :)

I just want to see whether the DoS scenario I was explaining
is a real one, or not.

---

From: "Gary Kenward" <[email-masked]>
Date: Wed, 13 Jun 2001 10:19:14 -0400

Phil:

  Kewl idea Phil, but how does this work with anything but best effort?

  For voice traffic, as an example, it would be better if the IP stack
continued to run, and the packets were lost (up to a point).

  CT really has little use for good ol' vanilla BE IP. It's all the other
state dependent features that were put in place for *cough* real time
services.

  Or have I mis-read your message?

Gary

> Sent: Wednesday, June 13, 2001 9:13 AM
> To: 'Pat Calhoun'; Nakhjiri Madjid-MNAKHJI1
> w as Re: [seamob y] ct problem statement
> 
> 
> 
> Hi,
> > 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?
> 
> Pat,
> 
> There are companies that build products (WRQ's reflection comes
> to mind) that freeze the state of the IP stack (gracefully in
> the application sense), until the flow of IP traffic can resume.
> This is sort of an ultra-slow handover.  I see no reason why THIS
> can not be made seamless with CT.  Why should CT not be capable
> of accomodating this Pat?
> 
> Thanks,
> 
> Phil
>

---

From: "Gary Kenward" <[email-masked]>
Date: Wed, 13 Jun 2001 15:17:55 -0400

> From: Emil Sturniolo [mailto:[email-masked]]
> Sent: Wednesday, June 13, 2001 12:53 PM
> To: Phillip Neumiller
> Cc: 'seamoby'; wirelessinternet

*snip*

> occurs would allow for much smoother handoffs. From our experience,
> depending on the OS, handoffs today can take a significantly long time
> (many, many seconds). Be glad to privately answer any 

It's scraps of information like this that makes ARDiS, Mobitex, DataTAC look
like really, really good mobile wireless data solutions (Phil at least
should understand 
my reference ;^} ). In those networks, handovers are measured in terms of
tens of milliseconds, not seconds. 

*sigh*

Gary

*snip*

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 14 Jun 2001 16:08:39 -0500

-----Original Message-----
From: Pat Calhoun [mailto:[email-masked]]
Sent: Wednesday, June 13, 2001 8:29 AM
To: Phillip Neumiller
Cc: 'Pat Calhoun'; Nakhjiri Madjid-MNAKHJI1; Arthur Ross; Charlie
Perkins; Kulwinder Atwal; 'seamoby';
[email-masked]
Subject: Re: [seamoby] RE: Authentication & Authorization "in-the-large"
w as Re: [seamob y] ct problem statement

> of accomodating this Pat?

Sure, they could, but what is seamless in this sense? The user has
no service for some time, so what is an extra couple of seconds while
signalling occurs over the air to update the local ARs state?? The
user would probably not even notice.

Actually, you seem to imply something that I am not sure that I've
been thinking about that much, which is the mobile updating the
AR's state. This, btw, can be problematic, since the mobile doesn't
necessarily share an SA with the AR (hence DoS attacks), and a
malicious mobile could send bogus (mal-formed) CT packets in an 
attempt to crash (or cause mis-behaving) ARs.

Something to think about in the DoS space.

MN>> Yes, involving the MN is CT is definitely a whole other
ball of wax. As I said earlier the assumption was that the CT happens
AR to AR and I was exploring the DoSs for that case.
The MN is not authenticated to the newAR, so all kinds of security
problems exists until the MN is "properly introduced" to the newAR.

Madjid 

PatC

---

From: Kulwinder Atwal <[email-masked]>
Date: Thu, 14 Jun 2001 17:45:37 -0400

> Sent: Thursday, June 14, 2001 5:09 PM
> To: 'Pat Calhoun'; Phillip Neumiller
> Cc: Nakhjiri Madjid-MNAKHJI1; Arthur Ross; Charlie Perkins; Kulwinder
> Atwal; 'seamoby'; [email-masked]

> problems exists until the MN is "properly introduced" to the newAR.

What do you mean "properly introduced" to the newAR.  The MN can certainly
authenticate to the newAR.  The MN can just show up at the new AR and
introduce itself.  It called "Reactive" Context Transfer.

The preferred case, of course, is when the oldAR transfers trust to the
newAR. 

But, certainly we must consider the case of an MN just showing up at the
newAR.  The newAR is then faced with finding out where the MN was last
attached and invalidating the oldSA.  The MN has to present a credential to
the newAR that the oldAR will accept as valid. 

- Kulwinder.

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 14 Jun 2001 17:01:33 -0500

-----Original Message-----
From: Kulwinder Atwal [mailto:[email-masked]]
Sent: Thursday, June 14, 2001 4:46 PM
To: 'Nakhjiri Madjid-MNAKHJI1'; 'Pat Calhoun'; Phillip Neumiller
Cc: Arthur Ross; Charlie Perkins; Kulwinder Atwal; 'seamoby';

MN>>> Kulwinder, by "properly introduced", I meant to skip the security
details between MN and newAR. Yes, MN can authenticate itself to newAR but
not as part of CT, and for sure not before CT completition, especially, if
the intention of CT was to transfer MN's for-AAA-Security-needed context.

I don't think reactive context transfer was meant to be initiated by MN and
definitely not after "MN's introduction itself to newAR". What does this
introduction mean in context of "context transfer" anyway. If CT is supposed
to happen between ARs, where does this introduction come in? Unless you are
talking about an L2 connectivity signal or even an L2 authentication (which
is not very fast!!!). 
The scenario is an AR-AR CT, then an MN-newAR authentication (proper
introduction)
based on transferred credential after CT is complete.

MN>> Of course. That is why I mentioned "properly introduced"

MN>> Yes, but that is not where CT helps, you are out of the
CT-is-an-optimization
territory. MN does a lot of negotiations for establishing the context
anyway.

BTW, I just noticed that my initials and acronym for Mobile Node are the
same :(
"MN>> means I am talking :)

Madjid

---

From: Kulwinder Atwal <[email-masked]>
Date: Thu, 14 Jun 2001 18:30:09 -0400

> Sent: Thursday, June 14, 2001 6:02 PM
> To: 'Kulwinder Atwal'; Nakhjiri Madjid-MNAKHJI1; 'Pat 
> Calhoun'; Phillip
> Neumiller
> Cc: 'seamoby'; [email-masked]
> definitely not after "MN's introduction itself to newAR".

Of course it was intended.  Read the Archive.  If the MN is switching
between wireless and wired, _as_stated_in_our_charter_, there is no other
way other than MN initiated CT. 

What do you expect will happen when an MN loses connectivity between ARs and
just shows up at the newAR?  Do you _really_ expect the End-User to drive
back during Rush Hour to the oldAR and try again?
 
> What does this

How does the newAR even know that the MN has arrived if the MN does not
annouce itself?  Why should the newAR waste time doing a CT for an MN that
is not authorized?  Sounds like an opportunity for a DOS attack.  Authorize
first.  Then do CT.  Especially for an MN that has arrived unannouced at the
newAR due to a service disruption will moving between ARs.

- Kulwinder.