RE: "Onion model" explained

Joe,

Please see below.

Cheers,

Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624


                                                                                                                                  
                      "Joseph Hui"                                                                                                
                      <Joseph.Hui@exodu        To:       Christopher B Ferris/Waltham/IBM@IBMUS                                   
                      s.net>                   cc:       "Hal Lockhart" <hal.lockhart@entegrity.com>, <www-ws-arch@w3.org>        
                                               Subject:  RE: "Onion model" explained                                              
                      07/11/2002 07:27                                                                                            
                      PM                                                                                                          
                                                                                                                                  
                                                                                                                                  



> From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
>> >If Alice makes a decision about her interaction with Bob,
>> >that is an Authorization decision.
>
>> No, not necessarily.  Alice may interact will anyone before making
>> an authz decision.  The interaction may only involve handshake
>> and trivial application data exchange.  That is, Alice's security
>> policy may say she's only concerned with really whom she is shaking
>> hands with, AND NOTHING MORE.
>>
> But does that not constitute an authZ decision?

Maybe I was trying to make a good point using a bad example.
In day-to-day convention, one can, as you and Hal did, indeed validly
interpret it as an authZ decision, by inferring Alice's sec policy
to be, in plain English: authorize authenticated Bob X.

But in sec-speak convention (as I know it or am accustomed to),
the same policy will be stated as, in two discrete parts:

   1) Authenticate all peers.
   2) Authorize Bob X.
   END-OF-POLICY

The authZ part kicks in if only if the authN part succeeds.

Now, the Alice sec policy I was using to drive the authN-alone
point across is:

   1) Authenticate all peers.
   END-OF-POLICY

There's no X inferred.

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.

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.

[snip]
>> >Presumably she requires some proof of possesion, a certificate
>> >alone proves nothing, but this is a side issue.
>>
>> A certificate proves nothing?  By certificate I meant a cert
>> that Alice
>> deemed trustworthy, say a CA signed cert.  Now, if a CA signed cert,
>> which millions of Internet shoppers trust their money to,
>> means nothing
>> to you, then I don't think we'll go anywhere on the issue.
>
> A certificate alone means nothing, even one that is CA
> signed, absent a CPS.

Well, it means whatever Alice deems trustworthy or otherwise,
assuming Alice already practices "safe certs," such as
checking the CRL (Cert Revokation List) with due dilligence.

[snip]

Cheers,

Joe Hui
Exodus, a Cable & Wireless service

Received on Thursday, 11 July 2002 19:58:26 UTC