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:       "Hal Lockhart" <hal.lockhart@entegrity.com>, <www-ws-arch@w3.org>        
                      s.net>                   cc:                                                                                
                      Sent by:                 Subject:  RE: "Onion model" explained                                              
                      www-ws-arch-reque                                                                                           
                      st@w3.org                                                                                                   
                                                                                                                                  
                                                                                                                                  
                      07/11/2002 03:23                                                                                            
                      PM                                                                                                          
                                                                                                                                  
                                                                                                                                  




>From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
[snip]
>> Besides playing auxiliary roles for Conf, Integrity, Authz, etc,
>> Authentication can by itself be of some value to applications.
>> E.g. Applications Alice and Bob communicate online.
>> Alice only cares that Bob is really what he claims he is, and
>> nothing else,
>> i.e. conf, integrity, auditing, etc are of no concern to them
>> both.
>
>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?

>I doesn't matter if the AuthZ
>policy is hard coded, expressed as an ACL, a policy language or
>in some other way, it is still an AuthN decision.

AuthN decision?

>My point is that AuthN alone is never sufficient.

The heartbeat notifiers I gave as an example prove this to be false.
What can be true is: AnthN alone is usually insufficient.
It mostly depends on the security policies of the parties in question .

>The Authenticated identity is either ignored or used in some way,
>such as 1) altering the interaction (AuthN) 2) written down (Audit Trail),
>3) used in future interactions (Confidentiality), etc.
>
>> How would
>> Alice go by accomplishing that?  She asks whoever claims to be Bob
>> to present her a CA signed certificate; verifies it; and
>> accepts or rejects
>> the claim accordingly.
>
>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.

>  In practice, this may be done by Alice as a
  >> TLS client asking its server for a certificate, and negotiating only
>> for a null ciphersuite.
>
>I don't get your point here. There are many forms of Authentication which
>vary in many properties, strength being one. I suppose mere assertion of
>identity can be viewed as the limiting case of weak AuthN, but this does
>not match most definitions which are something like "verification of a
>claimed identity." Even using an IP address could argued to involve
>(admitedly weak) verification, as the architecture of the network may
>tend to provide independent evidence of the claimed value.

I don't think you did, judging from disconnect that I've been sensing.

>But I don't see how the properties of the AuthN method, including
>strength, have any bearing on the how the data might subsequently be used.
>
>>  Secured heartbeat notifier[s] are one app
>> class that can fulfill its purpose in life using authc alone.
>
>I am not sure I know exactly what you mean by secured heartbeat notifier,

Oh, so here could be the source of the disconnect.
Heartbeat notifiers are, well, heartbeat notifiers.
(I think by now you know what they are from Roger's message in
this thread.  I'm afraid I can't make it more clear than that.)

>but if authenticated entities are allowed to do X and unauthenticated
>entities cannot do X, that is AuthZ.

I don't know why you would set a scenario up this way.
Is it your point that Authentication is a part of Authorization?
BTW, it's a given that their close association is widely understood.

Joe Hui
Exodus, a Cable & Wireless service

Received on Thursday, 11 July 2002 15:35:14 UTC