Subject: RE: [seamoby] Authorization vs. authentication

From: Kulwinder Atwal <[email-masked]>
Date: Sat, 9 Jun 2001 23:58:24 -0400

I believe it has to do with the level of permission granted and the scope of
permission granted.

Just becuase your identity has been authenticated does not mean that you
will recieve the highest level of permission and the widest scope of
permission within the network.  Your scope and level of permission will be
appropriate with your job function/service aggreement.

For example, a node belonging to a End-User will not be authorized to do the
same things as a node belonging to the network administrator (higher
permission level).

Also, a node belonging to the network administrator will not be able to
access and control the same financial resources as a node belonging to the
Chief Financial Officer (Different Scope).  The scope has to be related to
the area of expertise.

Consider a node that has been authenticated, but has an overdue bill.
Should the Cellular Operator authorize the node to use wireless services
anyway?

Also, consider an employee that has been authenticated as being on the
payroll, but is trying to access resources on the network that the employee
is not qualified to control.  For example, a production worker in a factory
trying to change the software of a piece of machinery.

A node may only be permitted to access the network at:

- a certain time, 
- a certain place, 
- and use certain resources. 

The fact that the node has had its identity confirmed is but a single input
into the authorization decision making process.   

- Kulwinder.

> -----Original Message-----
> From: Charles E. Perkins [mailto:[email-masked]]
> Sent: Saturday, June 09, 2001 9:24 PM
> To: 'seamoby'
> Subject: [seamoby] Authorization vs. authentication
> 
> 
> 
> Hello folks,
> 
> It seems to me that this issue is too important to leave unsettled.
> I didn't find anything in the books I looked at to resolve the
> issue, but it's true that I don't necessarily know which books
> are best to consult.  Help will be appreciated, at least by me.
> If this mailing list is considered to be the wrong place for such
> information, let me know and I'll not post any more requests.
> 
> Roughly speaking, I understand a node to be "authorized"
> if it has permission to do something.  I understand the node
> to be "authenticated" if its identify has been verified.
> If that's wrong, then I'd like to find out why.
> 
> If it's right, then I'd like to find out why my discussion in
> the message below should be considered uneducated, nonsensical
> spew.
> 
> If the bottom line is that these concepts are too hard for
> people like me to understand, then the relevant charter items
> should be moved to a working group where the right kind of
> people are able to put in the effort to carry out the work.
> I find that very hard to believe, but I'm willing to be
> educated.
> 
> Thanks for your consideration of my request.
> 
> Regards,
> Charlie P.
> 
> 
> 
> Michael Thomas wrote:
> > 
> > Charlie,
> > 
> > There is no point in arguing with you. I gave you
> > the benefit of the doubt which was clearly not
> > justified; this is security 101. There is nothing
> > here in your rebuttal that shows that you have
> > even elementary clues. Please take some time to
> > educate yourself so that you can stop spewing this
> > uneducated nonsense. As for my supposed free time,
> > I have better uses for it. Maybe Dan Harkins would
> > be willing to help you.
> > 
> >              Mike
> > 
> > Charlie Perkins writes:
> >>
> >>
> >>>    Bzzt. You need authentication to know whether somebody's
> >>>    *impersonating* somebody who has authorization to do
> >>>    what the attacker wants to do.
> >>
> >> This is manifestly wrong, because one can carry something
> >> that gives authorization for some resource without having
> >> to be identified.
> >>
> >>>>> 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.
> >>>
> >>>    False. On your typical OS, you log in first. That is
> >>>    authentication first and foremost.   ...
> >>
> >> This is a case where authentication provides sufficient 
> authorization
> >> (according to the system design).
> >>
> >>>
> >>>> 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.
> >>>
> >>>    Uh, do you *really* think that credit card
> >>>    company doesn't attempt to authenticate you
> >>>    before they issue a card? All you're saying
> >>>    here is that you trust third party authentication
> >>>    (the credit card company) to make an authorization
> >>>    decision based on that identity (give service).
> >>
> >> It's often enough true, however, that someone can use a
> >> credit card to get authorization for transfer of resources,
> >> without being the owner of the card.  And this is often
> >> enough quite legitimate.
> >>
> >>>> 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.
> >>>
> >>>    False. Only a fool would authorize something
> >>>    without authenticating them first.
> >>
> >> False.  I would authorize a lot of things if you give
> >> me enough money, and I wouldn't care who you are.
> >>
> >>>> It seems to me that we don't need a general authorization
> >>>> algorithm.
> >>>
> >>>    There is no such thing.
> >>
> >> You seem so sure of yourself.
> >>
> >>>> 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).
> >>>
> >>>    Authentication can never solve authorization. They're
> >>>    apples and oranges.
> >>
> >> What about your OS login example?  Never say never.
> >> It depends on the system design.
> >>
> >>>> 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).
> >>>
> >>>    Pray tell, how can you tell if they are "the same node"
> >>>    if you don't authenticate them? Just because you claim
> >>>    to be the same node?
> >>
> >> If the node exhibits knowledge of a particular secret, I can
> >> believe they are authorized no matter who they are.
> >>
> >>>    Please people, I urge people who are confused
> >>>    to do some reading. This is really basic stuff
> >>>    and we're headed off into durable nonsense
> >>>    la-la land.
> >>
> >> It's always good to read and study and understand more.
> >> It's furthermore typically good to help others understand,
> >> given that time is available.  You seem to have enough time
> >> on your hands.
> >>
> >> ...
> >> Charlie P.
>

---

From: Michael Thomas <[email-masked]>
Date: Sun, 10 Jun 2001 07:13:54 -0700 (PDT)

Exactly. Something to note is that authentication
doesn't imply cryptographic authentication or even
strong authentication. It's just the process of
identifying an entity using some methodology,
including sticking a key into a lock and having
the tumblers line up (shared secret), looking
across the counter to visually cross check a
license (third party through DMV), searching a
finger print database for a match from a crime
scene (third party through cops), accepting your
mother's birth name and your social security
number to issue a credit card (very weak form of
shared secret), public key digital signatures
verified through a private database of public keys
(strong, quasi shared secret) or digital
signatures over X.509 certificates (strong, third
party).

None of these has the least bit to do with
authorization, and in fact just because you can be
authenticated in one realm implies that you should
be _authorized_ in another realm. For example, I
have a shared secret between my key and my door
lock. Presentation of that key to a bank teller
to, oh say, get $18,000,000 is not going to be
authorized because of an authentication
failure. The reason is not because the key was
bogus or anything like that, it's because the
realm I was trying to authenticate myself in does
not have any trust relationship with the door
lock's realm.

Note also that the ultimate authorization of my
$18,000,000 is by no means guaranteed even if I do
manage to properly authenticate in the bank's
realm: I need to have access via funds or credit
to that money. Notice that authorization checks
are necessarily a two step process: determine the
identity of the requestor within the realm, and
then determine whether the request from that
identity is allowable within the realm. Note also
that this has nothing to do with unique identites
either. In the case of my door lock, I may give
that shared secret to any number of humans I see
fit, which for the purposes of authentication
within my door lock's realm are equivalent. To
conclude this analogy, notice that mere insertion
of the key into my lock is not in and of itself
authorization; it is merely a potential. If I were
to throw a deadbolt or somehow override the
default authorization of allowing the bolt to be
retracted, the key would have authenticated itself
successfully to the lock, but it still wouldn't
have gained the necessary authorization to pass.

		Mike

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 11 Jun 2001 16:24:03 -0700

Sometimes, authorization is implicit in the process of authentication. When the
bartender okeys your id (authentication), you get authorization to consume
alcohol, as much as you can handle I guess, as long as you are accountable to
paying.
Similarly, it is possible that if authentication succeeds, then the message type
and content allow implicit authorization, weak or otherwise.

Regards,

-Rajeev