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

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

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. 

  The opposite is also true: if the mobile node is not re-authorized with
each
handover, does this not open up the opportunity for the authenticated node
to
steal service it has not been authorized to use?

  I do not believe that there are any easy answers to these questions.
Certainly,
tight security imposes greater complexity on the network and sometimes,
introduces
performance degradation. And the cost of security is inevitably passed on to
the
consumer. 

  I haven't followed the "authorization" discussion in AAA, but from the
postings
to this list is does sound that there is no solution on the horizon (please
correct
me if I am mistaken). 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.

  Just some thoughts.

Cheers,
Gary

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
> Sent: Monday, June 11, 2001 2:55 PM
> To: 'Charles E. Perkins'; Nakhjiri Madjid-MNAKHJI1
> Cc: 'seamoby'
> Subject: RE: Comments Re: [seamoby] ct problem statement
> 
> 
> 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: Arthur Ross <[email-masked]>
Date: Mon, 11 Jun 2001 14:17:55 -0700

At 13:06 -0700 06/11/2001, Gary Kenward wrote:
>It would seem that for a mobile solution, the preferred approach
>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.

... but we digress into solution space ....

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: Pat Calhoun <[email-masked]>
Date: Mon, 11 Jun 2001 14:09:53 -0700

On Mon, Jun 11, 2001 at 02:17:55PM -0700, Arthur Ross wrote:
> > 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.   
> 

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 :(

PatC

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 14 Jun 2001 17:58:52 -0700

Hello folks,

If I remember right, the token went under the nickname of "blob"
in those days.  When I try to apply the token theory to context
transfer, I get the following:

- Mobile supplies token
- New access router validates token
  == how does it prevent against another node "prematurely"
       using the token?
  == how does it prevent replay?
  == does the same token work for all nearby access routers?
- New access router asks old access router for context features
- Old access router sends stuff
- ...

In this scenario, I don't see much advantage because the
old access router could more easily check some credentials
produced by the mobile node as part of its request to get
stuff from the old access router.  Or maybe it's all a matter
of definition, and a "blob" and a "token" should be treated
as variations of some "credential data", and the only point
is which access router verifies it.  Or we might be worried
about how much data has to go over the air.

I don't doubt that the token theory can be made to work.
It's just a matter of picking the most economical solution.

Regards,
Charlie P.

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 15 Jun 2001 05:26:27 -0700

On Thu, Jun 14, 2001 at 05:58:52PM -0700, Charlie Perkins wrote:
> in those days.  
correct.

> When I try to apply the token theory to context
No, the access router provides the token to the mobile. The token includes
the amount of time the user has been authorized to have access, the features
the mobile has been authorized to use, an encrypted session key that the
access router uses to secure messages between itself and the mobile, a timestamp,
expiration time, and is digitally signed.

> - New access router validates token
correct.

>   == how does it prevent against another node "prematurely"
What does this mean?!? Once a token has been provided to the mobile,
it isn't premature....

>   == how does it prevent replay?
The token has a lifetime, which SHOULD be the same as the authorized
amount of the time the user may access the network (this, btw, is
returned by AAA).

>   == does the same token work for all nearby access routers?
yes. There is a need for all access routers to be able to verify the
validity of the token. This could require that they all share a Private
key, or some other mechanism on the back end that would allow them to
share the decrypted version of the token.

> - New access router asks old access router for context features
correct, and this is based on the info contained in the token.

> - Old access router sends stuff
which it agreed to do, based on the features in the token.

...

> about how much data has to go over the air.

I believe that the concern at the time was the amount of data
over the air, but this still significantly reduces the amount
of time it would take to construct all of this information if
AAA had to be contacted. 

Keep in mind, though, that the primary use for the blob at the
time was to carry session keys across access routers to eliminate
the need to re-establish an SA between the MN and the FA. This
was done prior to the context transfer work, and if CT exists,
then it most likely is much more efficient to simply CT this
information across ARs, instead of have the mobile supply it.

PatC

---

From: Cedric Westphal <[email-masked]>
Date: Fri, 15 Jun 2001 06:14:13 -0700

Pat,

quick question:

> expiration time, and is digitally signed.

If the token equals authorization, who performs the authentication?
(in new terminology, what credentials are necessary to obtain the token).
Thanks,

Cedric.

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 15 Jun 2001 06:24:13 -0700

> (in new terminology, what credentials are necessary to obtain the token).

When the mobile first gains access to the network, the user's home AAA
is contacted, and the mobile is granted access. The AAA message contains
the authorization lifetime, and this information is used by the FA in
creating the token (or blob). In the mobile ip case, the AAA server
would also create the MN-FA session key, and this data would be included
in the blob. All future mobile ip messages from the mobile would include
the MN-FA authentication extension, and new ARs would use the session key
embedded in the blob (which is encrypted, of course) to authenticate
the MN-FA authentication extension, eliminating the need for the AAA
to be contacted again.

PatC

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 15 Jun 2001 08:09:12 -0700

> expiration time, and is digitally signed.

To be more precise, my three-word description should have read:
"the mobile supplies to the new access router the token which was
 given to it by the previous access router."

> What does this mean?!? Once a token has been provided to the mobile,

If node X overhears my token, then it _could_ use it before I got
around to using it.  Thus, the answer to my question would be
"by encrypting the token".  I'm only just pointing out that the
whole tokenizing procedure needs care.

> amount of the time the user may access the network (this, btw, is

That's not good enough actually.  Again, I know it can be solved,
but the problem could be that someone might borrow my context
by asking it to be transferred again, even within the lifetime
of the token.  There are many variations.  It's worthwhile to note
that the previous access router SHOULD (or, maybe MUST) maintain
the state even for a little while after it has been requested,
because the context transfer SHOULD (or, maybe MUST) be resilient
to one or two dropped packets in the control message flow.

> share the decrypted version of the token.

This is the big disadvantage of the blob scheme compared to the scheme
whereby the previous access router itself checks the transfer credentials.

> of time it would take to construct all of this information if

Agreed.

Regards,
Charlie P.

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 15 Jun 2001 08:28:48 -0700

> whole tokenizing procedure needs care.

let him. Unless he has the somehow figured out how to retrieve the
session keys from your device, the token is useless...

Again, session keys are used to authenticate messages. The token isn't
useful at all to the mobile, it's an AR thing.

> to one or two dropped packets in the control message flow.

But your point here is that someone has stolen the session key, which
would be mandatory in order to generate such an attack. I would claim
that if someone has been successful in stealing your key, then there
isn't a whole lot that you can do to protect yourself against such an attack
(not to mention many others).

> whereby the previous access router itself checks the transfer credentials.

I think that we agree that even when the ARs communicate, they must
secure the data, so it happens either way. Having said that, I agree
that direct communication is preferable, but again, this was a SIMPLE
proposal way back when CT didn't even exist (well, not that it does 
today either, but you know what I mean)

Thanks,

PatC