Subject: RE: Comments Re: [seamoby] ct problem statement

From: "Gary Kenward" <[email-masked]>
Date: Mon, 4 Jun 2001 12:17:39 -0400

I agree Charlie, but how is this different from other 
data transfers requiring explicit authentication and authorization?

Gary

> -----Original Message-----
> From: Charles E. Perkins [mailto:[email-masked]]
> Sent: Monday, June 04, 2001 12:00 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: [email-masked]'; 'seamoby'
> Subject: Re: Comments Re: [seamoby] ct problem statement
> 
> 
> 
> Hello Gary,
> 
> >   The second point troubles me somewhat: ct is essentially 
> an information
> > transfer operation. I do not understand (and I can only 
> state this as my being
> > confusion) why it is not enough to say that this 
> information transfer
> > must be secure. Why would a ct be any different from any 
> other data transfer
> > that needs to be secured?
> 
> Some features (e.g., QoS or security associations) that might 
> be handled
> as part of the context transfer mechanism should be 
> transferred only upon
> assurance that the requester has at least some implicit 
> authorization to
> make the request.
> 
> Regards,
> Charlie P.
> 
> 
> >   I personally don't see any new vulnerabilities; based 
> upon my superficial
> > understanding of security, I read the examples you have 
> provided as specific
> > instances of general security problems which I understood 
> to have been
> > addressed. In other words, how are these scenarios not 
> already addressed by
> > the existing security solutions?
> > 
> >   I am not against providing security for ct - not at all. 
> However, I do want
> > to ensure that security remains an option to the operator 
> (and is not build
> > into the protocol), the overhead imparted the ct can be 
> minimized, and the
> > performance goals attained.
> > 
> > 
> >    I am sure the wg will have input on the security issue, 
> and the security
> > section will be enhanced, I am uncomfortable with that idea 
> that ct has novel
> > requirements.
> > 
> > Thank you for the response,
> > Gary
> > 
> > > -----Original Message-----
> > > From: Allison Mankin [mailto:[email-masked]]
> > > Sent: Friday, June 01, 2001 9:21 PM
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]
> > > Cc: 'seamoby'; 'Pat Calhoun'; [email-masked]
> > > Subject: Comments Re: [seamoby] ct problem statement
> > >
> > >
> > > Hi, Gary,
> > >
> > > > Pat:
> > > >
> > > >  I'm afraid to ask, but I must. What's up with the ct
> > > problem statement?
> > > >
> > > > Gary
> > >
> > > Since Pat said he'd consult the ADs to answer this:
> > >
> > > I note that the WG last call on the CT problem statement ended two
> > > days ago.  Were there issues brought up to any of the authors or
> > > in the design team mailing list?  The working group list did
> > > not surface
> > > any, that I saw, so I'll surface some that should be 
> addressed before
> > > we put the draft forward for advancement:
> > >
> > >
> > > 1. The draft is very concise and easy to read - you want to spoil
> > >    us in the IESG by continuing this good trend by Seamoby (in the
> > >    footsteps of the paging problem statement)?  [Needless
> > >    to say, this is _not_ an issue :> ]
> > >
> > > 2. I would like to see some discussion of the problem space of
> > >    how to evaluate when Internet CT makes sense and when it might
> > >    not.  For instance, the point that if a feature context has
> > >    information that took many exchanges and/or computation to set
> > >    up, it is a better candidate.  Frequency of change of features
> > >    would affect when CT is a good choice.   The goal is not
> > >    to make any evaluations, but to give a problem space for the
> > >    protocol design work to come.
> > >
> > >    How can the problem be described so that designers and eventual
> > >    deployers can distinguish between optimizations that
> > > provide benefits
> > >    only in narrowly constrained network circumstances and designs
> > >    that provide broad enough benefits to be used at 
> Internet level.
> > >
> > > 3. Security considerations - the point about the sensitivity of
> > >    information carried in the CT is good, but the point about
> > >    CT not raising new security concerns is too much of a leap.
> > >    Even with the good design point of having the MN work but just
> > >    have a slower handoff when CT fails, there are risks to net and
> > >    nodes.  Examples thought of quickly:
> > >
> > >      Malicious context transferrors that give incorrect but
> > >      information that is not malformed, and damage/alter the MN's
> > >      connectivity
> > >
> > >      Malicious CT requests causing DoS to the Forwarding 
> Nodes that
> > >      have to process them.
> > >
> > >    These are from quick thought.  A safer comment would be that CT
> > >    probably will have novel security and requirements and 
> design will
> > >    have to address.  Check out draft-rescorla-cons-03.txt for more
> > >    ideas for the requirements phase.
> > >
> > > Thanks,
> > >
> > > Allison
> > >
> > >
> > >
> > >
> > >
> > >
>

---

From: "Gary Kenward" <[email-masked]>
Date: Mon, 4 Jun 2001 12:28:05 -0400

Well, to begin with, "at the operators option" would include
the option to provide privacy or not to the service users. In
a competitive environment, the user could then decide whether to
subscribe to the service or not, if that privacy was not provided.

As for securing "keys" (which is necessary to maintain the committed
level of security that operator has chosen to support), as been discussed
repeatedly on this list, no one has suggesting transferring keys openly.
What I stated was that I do not understand where the requirements for CT
differ from any other secure data transfer between peers.

Gary

> From: Michael Thomas [mailto:[email-masked]]
> Sent: Monday, June 04, 2001 11:33 AM
> Cc: [email-masked]'; 'seamoby'; 'Pat Calhoun'; [email-masked]
> Subject: RE: Comments Re: [seamoby] ct problem statement
> 
> 
> Gary Kenward writes:
> state this as my
>  > being confusion) why it is not enough to say that this 
> information transfer
> However, I do
>  > want to ensure that security remains an option to the 
> operator (and is not
>  > build into the protocol), the overhead imparted the ct can 
> be minimized, and
>  > the performance goals attained.
> 
>    Anything that transfers keys of any kind cannot be
>    done "at the operator's option". There are also
>    privacy issues which must be preserved for the MN
>    as well. At a base level, any transfer of context
>    must be at least as secure the mechanisms the
>    MN and AR used to create the original context. 
>    Anything less is a breach to the MN.
> 
> 	    Mike
>

---

From: Kulwinder Atwal <[email-masked]>
Date: Mon, 4 Jun 2001 18:28:25 -0400

I agree.
 
If we are already running IPSec out of band for CT,  do we need to run the
same security mechanism on top of the same security mechanism?
 
If IPSec is using MD5 do we also need SCTP to use MD5 and CT to use MD5 as
well?
Is there not some duplication of effort here?
 
Maybe we need to do a threat analysis in the protocol design phase to ensure
we have appropriate security measures at the appropriate level.
 
- Kulwinder.

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Monday, June 04, 2001 12:28 PM
To: 'Michael Thomas'
Cc: [email-masked]'; 'seamoby'; 'Pat Calhoun'; [email-masked]
Subject: RE: Comments Re: [seamoby] ct problem statement

Gary 

> From: Michael Thomas [ mailto:[email-masked] <mailto:[email-masked]> ]

---

From: Kulwinder Atwal <[email-masked]>
Date: Mon, 4 Jun 2001 18:43:54 -0400

> Sent: Monday, June 04, 2001 1:16 PM
> To: Gary Kenward
> Cc: 'Michael Thomas'; 'seamoby'
>  > So, instead, we want to develop solutions for the "good of 
> the operator",
>  > whether they are willing to pay for it or not?
> 
>    There are any number of ways that a shoddy operator
>    can find to provide shoddy service. The IETF doesn't
>    need to provide helpful hints.
> 
>  > A moot point, really, for if an operator does not want a 
> feature, they
>  > simply have to find a manufacturer who is willing to 
> provide the capability
>  > to the feature off.
>  > 
>  > Let's move on.
> 
>    No, let's not. The *user* figures in here too, and the
>    resulting RFC's should not allow for equivocation on this.
> 
> 	     Mike
> 

What if it is a private wireless network where there is no competition?

What if the private operator is an employer/government agency, or other
entity where the wireless service is provided as a way to delivery content
that is only available from a single employer/company/government agency?

Does the user find another job to work at, or another country to live in?

- Kulwinder.

---

From: Phillip Neumiller <[email-masked]>
Date: Tue, 5 Jun 2001 14:30:26 -0400

Hi Charlie,

Factoring is NP.

Trying all primes less sqrt(N) = O(e^ck); k = ln N, c= constant
Quadratic Field Sieve O[e@ck^1/2(ln k)^1/2]
Number Field Sieve O[e^ck^1/3(ln k)^2/3]

All exponential...

Now if you happen to have a quantum computer available to you
Shore algorithm for factoring is O[k^3], i.e. polynomial!!!

Thanks,

Phyil
> Sent: Tuesday, June 05, 2001 1:52 PM
> To: Mark Smith
> Cc: 'seamoby'
> Mark Smith wrote:
> >                    .........                             Do I
> > believe that the NSA (to whom the CIA would pass the data for
> > processing) has solved the NP-Complete problem yet?  If they have,
> > they've mannaged to keep their hats on probably one of the biggest
> > mathimatical advancements in history. 
> 
> Until I read this, I never thought that the strength of typical
> cryptographic algorithms was dependent on the NP-completeness
> problem.  Can you say more about the relationship of the two?
> 
> Regards,
> Charlie P.
>

---

From: gary kenward <[email-masked]>
Date: Wed, 6 Jun 2001 15:20:05 -0700 (PDT)

On Tue, 05 Jun 2001 09:01:56 -0700, Mark Smith wrote:

>  
>  (*) Where "good security model" is defined as "sufficient for the 
>  purpose."  Keep in mind that the idea behind security in a situation 
>  like this is just to make sure it's not the weakest link.  There's 
>  always Rubber Hose Cryptanalysis, where the Cryptanalysist beats the 
>  target over the head and shoulders with a rubber hose until they give up 
>  the information they're after.  _MUCH_ more effective than attacking the 
>  system or the encryption algorythm in a number of cases.
>

*chuckle*

Thanks.
Gary

_______________________________________________________
Send a cool gift with your E-Card
http://www.bluemountain.com/giftcenter/

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 7 Jun 2001 15:03:45 -0500

Allison,

Thanks for the comments and sorry for the delay.
I like to give my personal response (not on behalf of the group
and it seems other people provided their opinions already.

As far as WG and group feedback, well, I must say that
 the draft went through a serious downsizing,
thanks to editors good work. However, unfortunately I am not sure if the
second version enjoyed as much attention as the first, since there
were several hot debates regarding requirements at the time, I can see
now that the security parts are somehow severely downsized, I will comment
on the security issues in a separate email.

I am glad that, the reduced draft seems to have served the very
purpose of acclimatizing its audience to CT as a solution (even
if it might be an optimization only), since we
are having this healthy overview conversation here. 
Also I am glad that this discussion came up now after all the
 requirement discussions that we had in the past months, 
which had made most of us understand the CT problem through 
its requirements, so revising problem statement after
the requirement discussions seems like a healthy thing.

However, at the same time in the interest of consistency the following 
has been removed from the draft, 
1-list of various feature contexts where removed, 
2-different approaches to CT
3-security considerations
4-Some requirements (especially on security) in the appendix

Regarding 1 specifically, during the requirements phase, several
 issues on timing and reliability came up such as
	-If you were able to send context partially and 
	handle individual features' requirements on  
	timing and reliability, then CT could be seen as
	an optimization by helping the timing.
	-If the chief concern is security, then CT might 
	help provisioning security, although it might introduce 
	latency compared to an insecure system, but  
	that way achieve another type of optimization.

Regarding 2, there were a few issues such as

	-proactive and reactive CT and their timing requirements:
	If you were able to send context to a bunch 
	of handover candidates proactively (without even 
	knowing exactly which one you hand over to),
	you might reduce service disruption period by
	removing context transfer out of critical path. 
	My personal opinion is:
	 that issue is related to AR discovery/ CNP and MM teams work.

	-the issue of being able to fall back on base line
	in case CT fails was brought up and I am not sure
	 if it made it in the draft. Comparing CT with a 
	no-CT baseline (I am not sure if that is Mobile 
	IP or not) is important, but it again involves 
	considering various features and their requirements
	as well as recognition of MIP or something else as a baseline.

	In summary, I think most of us agree (Although I am 
	not sure it is reflected anywhere) that CT must be seen
	 as an optimization procedure, if it can meet various 
	features timing and reliability requirements.
	And exact recommendation for designers and implementers
	as far as when to use CT and when not might be a bit
	too early until we have clear understanding of feature
	requirements and their relations to various handover
	solutions (such as MIP fast handovers) out there.

I will comment on the security issues in another email.

Regards,
Madjid

-----Original Message-----
From: Allison Mankin [mailto:[email-masked]]
Sent: Friday, June 01, 2001 8:21 PM
To: Gary Kenward
Cc: 'seamoby'; 'Pat Calhoun'; [email-masked]
Subject: Comments Re: [seamoby] ct problem statement 

Hi, Gary,

> Pat: 
>  
>  I'm afraid to ask, but I must. What's up with the ct problem statement? 
>  
> Gary 

I note that the WG last call on the CT problem statement ended two
days ago.  Were there issues brought up to any of the authors or
in the design team mailing list?  The working group list did not surface
any, that I saw, so I'll surface some that should be addressed before
we put the draft forward for advancement:

 would show that some contents
it 
is now harder to see the  at the same time
it had to hide some of the issues

   How can the problem be described so that designers and eventual
   deployers can distinguish between optimizations that provide benefits
   only in narrowly constrained network circumstances and designs
   that provide broad enough benefits to be used at Internet level.

     Malicious CT requests causing DoS to the Forwarding Nodes that
     have to process them.

   These are from quick thought.  A safer comment would be that CT 
   probably will have novel security and requirements and design will
   have to address.  Check out draft-rescorla-cons-03.txt for more
   ideas for the requirements phase.

Thanks,

Allison

---

From: Phillip Neumiller <[email-masked]>
Date: Fri, 8 Jun 2001 10:39:34 -0400

I like the farm thing, but.... The internet is much more
like a city these days.  Cities have police forces, we have
the FBI, we have the national gaurd, etc.  People aren't 
supposed to carry guns around like in the old west.  I 
imagine that is what it was like in the early days of the
Internet.  Let's face it.  The scale of the security problem
is huge, and the IETF needs its own police force or army, if
you will, to work the issues and protect the rest of us from
the script kiddy weenies out there vandalizing the net.  
I still don't get it....

-pdn

> From: Melinda Shore [mailto:[email-masked]]

> 
> Down on the farm the policy is "when you open a gate,
> close it behind you."  It seems to me that if you're
> introducing security exposures in your protocols it's
> your responsibility to deal with those exposures.
> 
>

---

From: "Gary Kenward" <[email-masked]>
Date: Mon, 11 Jun 2001 14:01:40 -0400

Well, given enough money, I'd be willing to authenticate Pat as
being Bill Gates (not that it would do him much good).

Gary

> From: Pat Calhoun [mailto:[email-masked]]
> Sent: Monday, June 11, 2001 1:20 PM
> To: Charlie Perkins
> Cc: Kulwinder Atwal; 'seamoby'
> On Sun, Jun 10, 2001 at 07:15:21AM -0700, Charlie Perkins wrote:
> > Isn't it possible to have authorization without authentication?
> 
> To me, it doesn't make a whole lotta sense. If you are going 
> to authorize
> something prior to authentication, then I would consider the 
> latter step
> as unnecessary.
> 
> I agree with some that given enough money, you'll authorize anything,
> but you still want to make sure that the person asking is in fact the
> one that provided you with the cash, right?
> 
> > 
> > In other words, isn't it possible to grant authorization based
> > on verification of some credential that doesn't provide any
> > assurance of identity?
> 
> verification of credentials implies authentication. Authentication
> doesn't necessarily provide that you'll know the identity of the
> requestor. It really depends on the type of authentication involved.
> 
> > 
> > Currency comes to mind, and then electronic cash, but other
> > credentials are possible and relevant to the discussion.
> 
> Right. But if having a bank account number is sufficient to
> withdraw money, then this is a form of (admittedly weak) 
> authentication.
> 
> Once you've provided your bank account number, authorization would
> kick in when you request the amount you want, and the bank's policy
> in determining whether you've been authorized is probably something
> like:
> 1. Do you have enough in your account
> 2. Does it blow your daily limit
> 3. Do they even have enough in hard cash to give you
> 
> > I realize that such things begin to blur the line between a
> > credential and a tradable resource.  As you have pointed
> > out, relying on credential verification itself begins to blur the
> > line between authentication and authorization.
> > 
> > Maybe an example would help.  Suppose I put something
> > in a treasure chest, which cannot be opened except with
> > a key I happen to have.  Then I give you the key and tell
> > you how to use it to open the treasure chest.
> 
> Which is similar to giving me your bank account number (above)
> What you've done is authorize someone to have your credentials,
> which is used during the authentication process.
> 
> > 
> > Doesn't your possession of that key mean that you have
> > authorization to open the treasure chest?  Surely, the
> > treasure chest isn't going to care about your identity.
> > To me, this means that authorization does not require
> > authentication.
> 
> No, having the key is authentication. Authorization is allowing
> the person to take what they do (and assumes that there is an
> entity checking this, persumably you).
> 
> Note the fact that no one is at the vault implies that your
> example involves authentication, but not authorization.
> 
> Hope I haven't muddied the waters worse than it already was.
> 
> PatC
>

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Mon, 11 Jun 2001 13:54:57 -0500

Hello Charlie,

I must appologize for not reading the rest of the thread 
before sending this email, here it goes anyway.
Let me first clear a few points based on my understanding,
so you can tell me if I am correct or not:

1-I would say that authentication is to say that the authenticating
party shows evidence that he (put a /she from now on)
 is actually who he says he is, the credential is an ID/ password/ keys...

2-Authorization, would then be the step afterward; 
The network says, ok now I know, who the party that
 just authenticated itself is, but  
IS the party authorized to use the service he is requesting?
 for example this would be applicable when
a network provides various level of service.

3-Generally,(I think) today in most of cases, the networks authenticate
and authorize the user at the same time, of many reasons that you
know much better than me: say either, they don't offer too many
different kinds of services, QoS is not implemented in internet,
so the cost of using different services is the same for the ISP
(but we all know this is not true with your cable company, you want
more movie channels, you pay more :) )
So in effect, when the network authenticates and authorizes at the same
time, the credentials used for authentication and authorization are the
same.

4-If you would need to authenticate and authorize separately, then
the credentials and processes need to be different.

Impact on context transfer security and its immunity against DoS:
Say the two ARs are pre-authenticated, you have a secure pipe between
the ARs based on their identities and authentication keys.
You use this pipe for context transfer, so nobody besides the ARs
can do a context transfer, unless they are able to spoof ARs ID/auth key...
But this does not prevent an AR from doing a DoS against the other,
say I am an AR in network provider A' network and can hand my mobile's 
context to  you, an AR in network provider B's network. I am now
angry because you did not meet our billing agreement (sorry if this
is a poor scenario for DoS). Now I can do a DoS sending a lot of bogus
context to you and bring you down.

Is this an authentication problem? maybe not.
Can this be solved by an authorization prior to each CT?

I guess so, the AR is already authenticated (if not, that would
add a lot of delay to CT) but one authentication (that last
forever, does not solve DoS problems.

And I don't know why you say authentication is not important
but authorization is a central requirement for CT?

I am no expert in AAA, but The only place *I* have seen
different credentials for authentication and authorization
discussed in AAAArch.

Regards,
Madjid

-----Original Message-----
From: Charles E. Perkins [mailto:[email-masked]]
Sent: Friday, June 08, 2001 6:12 PM
To: Nakhjiri Madjid-MNAKHJI1
Cc: 'seamoby'
Subject: Re: Comments Re: [seamoby] ct problem statement

Hello Madjid,

I think people usually want secure authorization, and they
ask for authentication because it's less abstract somehow.

You and I wrote:

>> Sure. I get it, but my question is:
>> do we have different credential for authentication and authorization
today?
>
> It seems to me that today we typically use authentication when
> we really need authorization.  I guess the theory is that if you
> really know who is on the other side of the communiations fence,
> you'll be able to track them down if anything goes wrong.

Then you wrote:

> That was exactly my point, today there is no difference between
> the credential

I'm not very clear on what you mean.  If you mean that today people
usually accept authentication credentials as good enough for authorization,
then I reckon that may be true, but I am not sure why it is relevant
to the discussion we were having.

> The reason that I asked the question
> was your following answers to Phil:
> 
> [
> > Is authentication needed?
> 
> Probably not.
> 
> > Is authorization needed?
> 
> I think this is the central requirement.
> ]
> 
> how would we separate the two?

We can separate the two in a lot of ways, depending on the
purpose for which authorization is needed.  If you want to
know that someone can pay, and the credit card company says
they can pay, that is good enough.  If you want assurance
that someone is authorized to see your documents, you need
some other sort of authorization; it still doesn't have to
be done by authenticating their identity.  If you have an
access control list of authorized identities, then you can
use authentication.

It seems to me that we don't need a general authorization
algorithm.  We could use a general authentication algorithm,
but then we have to decide whether that implicitly solves
the authorization problem (whatever the latter is determined
to be).

I believe that we can and should separate authorization and
authentication for the purpose of context transfer.  All that
matters is that the requester is the same node that used to
own the context at the previous access router.  It doesn't
really matter what IP address belongs to the requester (for
this purpose of authorizing a context transfer).

Regards,
Charlie P.

---

From: "Gary Kenward" <[email-masked]>
Date: Tue, 12 Jun 2001 11:25:51 -0400

Great minds think alike.

Too bad this isn't the AAA group ;^}

Gary

> From: James Kempf [mailto:[email-masked]]
> Sent: Tuesday, June 12, 2001 11:07 AM
> To: [email-masked]; [email-masked]
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; [email-masked];
> [email-masked]; [email-masked]
> >> This is very close to what I have long thought might be a 
> good solution 
> >> to this problem, i.e. the notion of a "token" that the MN 
> might carry 
> >> around from AR to AR, presenting it as a sort of "ticket 
> for service". 
> >> The token would be some sort of public-key thingy, which would be 
> >> delivered to the MN upon successful initial authentication and, 
> >> possibly, authorization. It, or some complementary key 
> variable might 
> >> also be pre-distributed by the network to neighbor ARs 
> (for suitable 
> >> definitions of "neighbor") in anticipation of possible movement. 
> >> Successful use upon change of access point would require 
> some sort of 
> >> combination of a "secret" in the MN with the over-the-air token, 
> >> perhaps some sort of challenge-response technique.   
> >> 
> >> ... but we digress into solution space .... 
> >
> >indeed, and it is interesting that I proposed something very similar
> >in MIP at least 2 years ago, and it was never adopted as a 
> WG document :(
> >
> 
> I've also felt for about a year that such a token
> would go a long way to solving problems with authentication and
> authorization. I've proposed something like this on the BURP list.
> 
> 		jak
> 
>

---

From: James Kempf <[email-masked]>
Date: Tue, 12 Jun 2001 08:28:53 -0700 (PDT)

Well, if we all think it's a good idea, maybe we ought to do a draft
for BURP (presuming it becomes a workng group).

		jak
		
>From: "Gary Kenward" <[email-masked]>
>To: "'James Kempf'" <[email-masked]>, [email-masked], 
[email-masked]
>Cc: [email-masked], [email-masked], [email-masked]
>Date: Tue, 12 Jun 2001 11:25:51 -0400
>
>Great minds think alike.
>

---

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

Thanks Gary,

See below:

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Monday, June 11, 2001 3:06 PM
To: 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. Perkins'
Cc: 'seamoby'
Subject: RE: Comments Re: [seamoby] ct problem statement

Madjid, Charlie, et al: 
  Madjid, I think you have captured the essence of the real issue.
Authentication 
and authorization are different, but for the most part, authorization has 
never really been needed for the internet, mainly for the reasons you
describe. 
  The real interesting issue (besides how to authorize every doorknob and 
aircraft carrier on the planet), is whether, in a mobile environment, how
often 
one needs to authenticate. 
  Consider that a mobile node travelling through the network will, with each

handover, open up opportunities for an interloper to steal a service, if
that 
service is only authorized and the service user is not authenticated. 

MN>> I think the point of DoS is missed here.
Note, we are not discussing service theft here (that
is the operators problem). Stealing service by an un-authorized
user is not the issue. The issue is launching a DENIAL of service
attack by a node that can do CT (you can translate it as authorized
to do CT), so we are talking about authorizing oldAR to send CT
or authorizing newAR to request CT.

It seems that a lot of folks are confusing service theft with
DoS attack. With service theft, you are just not paying for usage.
With DoS attack, you are making the network so busy, it can not
give service to anybody, *DENIAL* of service.

Madjid

---

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

Again, this is not a AAA discussion. it is not about usage authorization and
theft of service, it is about Denial of service attack.
THe notion of token can be interesting to prevent an AR doing DoS on the other, but
if the mobile is supposed to carry these token, that kind of defeats the purpose
of CT, specially when we are doing proactive CT to several neighboring ARs.
 
Madjid

-----Original Message-----
From: Arthur Ross [mailto:[email-masked]]
Sent: Monday, June 11, 2001 4:18 PM
To: Gary Kenward; 'Nakhjiri Madjid-MNAKHJI1'; 'Charles E. Perkins'
Cc: 'seamoby'
Subject: RE: Comments Re: [seamoby] ct problem statement

At 13:06 -0700 06/11/2001, Gary Kenward wrote: 

It would seem that for a mobile solution, the preferred approach 

would incorporate some sort of "authorization" tokens that would could be passed between ARs as part of the mobile node's context (in a secure fashion of course). There would have to be a tight association maintained between the authentication information and these authorization tokens. If this is the best approach, then once again, it would be difficult to distinguish authentication from authorization. 

Gary et al: 

This is very close to what I have long thought might be a good solution to this problem, i.e. the notion of a "token" that the MN might carry around from AR to AR, presenting it as a sort of "ticket for service". The token would be some sort of public-key thingy, which would be delivered to the MN upon successful initial authentication and, possibly, authorization. It, or some complementary key variable might also be pre-distributed by the network to neighbor ARs (for suitable definitions of "neighbor") in anticipation of possible movement. Successful use upon change of access point would require some sort of combination of a "secret" in the MN with the over-the-air token, perhaps some sort of challenge-response technique. 

What this is about is creating a formalism for "trust propagation" in ways that are cryptographically secure against the well-known threats, e.g. hijacking the channel, spoofing, man-in-the-middle, etc. 

There are, BTW, already some ways of coping with the "aging" of the credential, such as the cellular authentication standards, which permit out of the blue challenges at the network's whim. Similar approaches might be ok here, if one is concerned with performance (speed of handover, QoS) vs security ... Sort of a Ronnie Reagan principle of CT: "Trust but verify." :-) 

-- ahmr

---

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

It sure feels like a AAA discussion!!

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Tuesday, June 12, 2001 10:26 AM
To: 'James Kempf'; [email-masked]; [email-masked]
Cc: Madjid.Nakhjiri; [email-masked]; [email-masked]
Subject: RE: Comments Re: [seamoby] ct problem statement

Great minds think alike. 

Gary 

> From: James Kempf [ mailto:[email-masked] <mailto:[email-masked]> ]

---

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

Well, Madjid. I agree with what you say, but would add two points:

	1. I think Pat said it, but if the intradomain ARs cannot be 
         trusted then it's game over; no amount of rules and procedures
         will save you if your police force is corrupt ;^}. I believe
         this also holds true for interdomain ARs, once the trust
relationship
         is established between the operators. 

         Note that I am referring to explicit DOS attacks here. Faulty
         ARs are a different problem, and I don't believe that you 
         provide fault tolerance through security procedures.

      2. When you get down to it, the *only* security problem the wireless
         operators have ever really been concerned with is theft of service.
         Back in the early 90s, AT&T claimed they lost $1M / day in stolen
         service. This was because AMP had a very simple security scheme.

         I am sure that operators are somewhat concerned about
eavesdropping,
         particularly given all the high profile cases that occurred in the
'90s.
         However, I believe that the general consensus is that the channel 
         coding is sufficient with 2G networks. Does anyone have a real
industry
         analysis, from the operators p.o.v?

This is somewhat off track. My only observation is that I do not recall any
similar
conversation on DOS being reported out of 3GPP, 3GPP2, 3GIP, or MWIF. But
maybe I
missed it.

Gary

> From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
> Sent: Tuesday, June 12, 2001 6:17 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]; Nakhjiri 
> Madjid-MNAKHJI1; 'Charles
> E. Perkins'
> Cc: 'seamoby'

---

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

Ok, Thinking a bit further about this problem, I can see that
I should not have posed the problem as an authentication or authorization
problem (since the credentials are the same anyway).

I should not have posed the problem as an AR goes crazy problem
either, since there is no measure against the corrupt police force
(you are right).

However, this is the problem:

By doing a pre-authentication between the ARs that are CT-peers,
you are doing a CT source authentication once and only once
for all the upcoming CTs.
This does not prevent a third node/ AR to come and pretend it
is one the CT peers and send context (in a DoS), we did 
not talk about message authentications or signatures (sort
of like what MIP does with its binding updates). Note that
I am not proposing the use of AH for CT, we all know where that
might lead to from MIPv6 experience. But This case sounds like
a man in middle attack or DoS attack, does it not?

Finally, as I said again, I don't think IETF cares about 
theft of service, that is operator's headache.

Madjid