RE: "Onion model" explained

> From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
[snip]
> Actually, I see this as:
> 
> 1) authN all peers
> 2) Authorize <authenticated user> X
> END-OF-POLICY
> 
> where X is any action on any resource.
                 ------
You meant "action" [by the authenticated user], I presume.
But in the example right below, there's no X, action by the
the authenticated users or any resource within Alice's domain.
(By default Alice needs no authorization to X in her domain.)
Note that my point here is not that the line two you added is
no good, but a sec policy with line alone suffices in Alice's
situation (as described in my example right below).
 
>> Let's use this same authN-only sec policy in my next example,
>> but forget about Bob.
>> Alice doesn't care who sent her messages, i.e. authorization
>> is called for.  But she does care about the senders
>> authenticating themselves, not for the purpose of
>> authorizing anything for the senders' benefit, but of knowing
>> who to track down and get even with in case she's offended
>> by a message, like one that contains cyber-Anthrax, hopefully
>> there's no such thing.  In practice this may go as: Alice
>> receiving an xml-dsig'ed message; validating the digital
>> signature; reading the message upon positive authentication.
>> Realize that the last step may again be interpreted as
>> a form of authZ in day-to-day convention, but not in the
>> traditional sec speak that keeps authN and authZ as discrete
>> security aspects/facets, and only authN is in the play
>> in this example.
>> 
>> Another no-authZ example, closer to reality, is that when
>> you buy a book from Amazon.com online, you only care about
>> http://www.amazon.com authenticating itself to be the
>> real McCoy (through your properly configured browser
>> that will on your behalf verify the cert that from some
>> https://xyz.amazon.com site) before revealing your
>> credit card number.  Assuming you're like me and most
>> Internet shoppers, you don't really care to keep
>> an ACL sheet by your keyboard for authorizing who
>> may sell you books.
> 
> Actually, you make an (un)concious authZ decision to reveal
> your credit card # only when the site is authenticated against its CA
> signed cert (signed by a CA configured into your browser) and the 
> little lock icon is closed.

Again, this may be acceptable as a "day-to-day conventional"
interpretation.  It however in no way affects the tradition
in sec speak to treat the two discretely separate where
appropriate, in spite of their close coupling in most
real-world cases.

Anyway, my point, in the interest of shedding light on the fact
that authN and authZ are traditionally and IMV rightfully kept
as discrete security aspects, was to show there exists at least
one use case where authN alone suffices (without authZ).

Unless your point is: authN is a part of authZ, or the two
are one and the same, there's no more I can add.

Cheers,

Joe Hui
Exodus, a Cable & Wireless service

Received on Thursday, 11 July 2002 21:25:48 UTC