Subject: RE: [seamoby] Authorization vs. authentication

From: Parviz Yegani <[email-masked]>
Date: Sun, 10 Jun 2001 02:06:17 -0700

Agree . In cellular, for example, authentication and authorization are not the same. 
Authentication is the process by which information is exchanged between a 
mobile station and base station for the purpose of confirming the identity of the 
mobile station.  A successful outcome of the authentication process occurs 
only when it can be demonstrated that the mobile station and base station 
possess identical sets of shared secret data.

Authorization, however, is an action to make a service available to a subscriber. 
The provision may be:
• general: where the service is made available to all subscribers (subject to
compatibility restrictions enforced) without prior arrangements being made with
the service provider.
• pre-arranged: where the service is made available to an individual subscriber
only after the necessary arrangements have been made with the service provider.

Hope this would help the group settle the issue as quickly as possible. No more
flames please!

Thanks,
Parviz

At 11:58 PM 6/9/2001 -0400, Kulwinder Atwal wrote:
>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: "Phillip D. Neumiller" <[email-masked]>
Date: Sun, 10 Jun 2001 06:22:43 -0500

I prefer not to alter the English language.  If one just uses the English
definition, authentication tells me undeniably who somebody is, and
authorization gives the somebody the right to act.  So authentication
is something you would normally do before authorization according to
the Queen's English.  The Queen tells the gaurds in her garrison to
authenticate the identify of would-be visitors before authorizing
them passage to her throne room.

au·then·ti·cate (ô-thnt-kt)
tr.v. au·then·ti·cat·ed, au·then·ti·cat·ing, au·then·ti·cates
To establish the authenticity of; prove genuine: a specialist who
authenticated the antique samovar.

Synonyms: confirm, corroborate, substantiate, authenticate, validate,
verify
These verbs mean to affirm the truth, accuracy, or genuineness of
something.
Confirm implies removal of all doubt: "We must never make experiments
to confirm our ideas, but simply to control them" (Claude Bernard).
Corroborate refers to supporting something by means of strengthening
evidence: The witness is expected to corroborate the plaintiff's
testimony. To substantiate is to establish by presenting substantial or
tangible evidence: "one of the most fully substantiated of historical
facts" (James Harvey Robinson). Authenticate implies the establishment
of genuineness of something by the testimony of an expert: Never
purchase an antique before it has been authenticated. Validate refers
to establishing the validity of something, such as a theory, claim,
or judgment: The divorce validated my parents' original objection to
the marriage. Verify implies proving by comparison with an original
or with established fact: The bank refused to cash the check until
the signature was verified.

au·thor·ize (ôth-rz)
 tr.v. au·thor·ized, au·thor·iz·ing, au·thor·iz·es

    1.To grant authority or power to.
    2.To give permission for; sanction: the city agency that authorizes
      construction projects.
    3.To be sufficient grounds for; justify.

Synonyms: authorize, accredit, commission, empower, license
These verbs mean to give someone the authority to act: authorized her
partner to negotiate on her behalf; a representative who was
accredited by his government; commissioned the real-estate agent to
purchase the house; was empowered to make decisions during the
president's absence; a pharmacist licensed to practice in two states.

Tally ho, 

Phil