RE: "Onion model" explained

> From: Pete Wenzel [mailto:pete@seebeyond.com]
[snip]
> I didn't state it as an axiom, just an example of the simplest authZ
> policy possible that still depends on authN.  If my only requirement
> is to ignore people whose identities I can't ascertain, then I don't
> need a higher resolution authZ policy than that.
> 
> Your heartbeat example likely isn't even this simple.  If Bob receives
> a signal from Carol, even though he can authenticate it as being from
> her, his authZ policy probably says that only Alice can reset the
> "Proc A" counter.  (Maybe Carol's signal will cause a "Proc C" counter
> to be reset instead.)

I already said in previous messages that the
close coupling between authN and authZ is widely
understood.  It's trivial to add extraneous elements to the case
of origin, e.g. adding authZ policy to the mix, to show the two
go together, not unlike adding sugar to water to show sugar and
water always go together, all the while the point of value is
that sugar and water are separate entities. :-)  That is, the
point of interest I expressed is in discerning the nuances of
the two as discrete aspects in security.
(BTW, a negative trigger, which I alluded to in Bob, doesn't
necessarily need authZ policy to fire.) 

> > Note the keyword "often" in the glossary definition.
> > The arguments you and Pete made was to make it "always."
> 
> I am fine with the definition as-is, because of course one is free to
> ignore an authentication result and not use it for any immediate or
> future purpose.  But as I have already said, this is a degenerate
> case, of no practical value, in which authN was therefore not needed
> in the first place; so we could just as well not waste resources
> performing it.  "Sometimes, authN by itself is even too much."

If Bob doesn't spend the resource authenticating (the origin of data),
how is he to know for sure whose heartbeat he's just received?
There're other cases where authN and authZ are clearly separate
and independent.  (I just explained to someone using IPSec's
Authentication Header, which he was more comfortable
working with; and he got it right away.  So I'm satisfied
that my point wasn't lost in all.)

Joe Hui
Exodus, a Cable & Wireless service
=====================================================


> --Pete
> 
> > -----Original Message-----
> > From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
> > Sent: Tuesday, July 23, 2002 11:52 AM
> > To: 'Pete Wenzel'; Joseph Hui
> > Cc: www-ws-arch@w3.org
> > Subject: RE: "Onion model" explained
> > 
> > 
> > 
> > I agree with Pete. In my mind you have an AuthZ policy with 
> two distinct
> > steps, something like this: 
> > 
> > 1. If (authentication of suitable type does not suceed) 
> ignore message 
> > 
> > 2. Update the info associated with the party sending the request. 
> > 
> > Since you made an implemention choice to do this in program 
> code, you
> > choose to view these steps as part of the application. However, they
> > could have just as well been done using an authorization policy
> > infrastructure, in which case it would be obvious that this 
> constituted
> > authorization.
> > 
> > The WSA glossary defines Authentication as: 
> > 
> > To positively verify the identity of a user, device, or 
> other entity in
> > a computer system, often as a prerequisite to allowing access to
> > resources in a system
> > 
> > The SAML definition is similar: 
> > 
> > To confirm a system entity's asserted principal identity with a 
> > specified, or understood, level of confidence. 
> > 
> > Neither says anything about MAKING USE of the identity. I 
> claim that as
> > soon as you do so, you are doing Authorization or 
> generating Audit trail
> > or something else.
> > 
> > Hal 
> > 
> > > -----Original Message----- 
> > > From: Pete Wenzel [ mailto:pete@seebeyond.com
> > <mailto:pete@seebeyond.com> ] 
> > > Sent: Tuesday, July 23, 2002 2:11 PM 
> > > To: Joseph Hui 
> > > Cc: Hal Lockhart; www-ws-arch@w3.org 
> > > Subject: Re: "Onion model" explained 
> > > 
> > > 
> > > Thus spoke Joseph Hui (Joseph.Hui@exodus.net) on Mon, Jul 22, 
> > > 2002 at 08:03:51PM -0700: 
> > > > >From:      Hal Lockhart [ mailto:hal.lockhart@entegrity.com
> > <mailto:hal.lockhart@entegrity.com> ] 
> > > > [snip] 
> > > > >1. I still maintain that Authentiation is never an end 
> in itself, 
> > > > >   it is a step that collects data to be used in some other 
> > > > >   decision. 
> > > > ... 
> > > > The point I made, as I recall, was to show the fallacy 
> > > > of "authN by itself was *never* enough" [Assertion A]. 
> > > > ... 
> > > > here's one heartbeat app with a negative trigger. 
> > > > Every N seconds Alice sends an "I'm-alive" signal to Bob. 
> > > > By sharing a common secret, only Bob knows how to 
> > > > authenticate the signals from Alice.  Bob will invoke 
> > > > Proc A if M heartbeats from Alice are missed. 
> > > > See?  No authZ whatsoever, 
> > > 
> > > But authentication of Alice's signal has a side-effect:  
> it causes 
> > > Bob to reset his watchdog timer-counter.  Signals that cannot be 
> > > authenticated as coming from Alice should not result in the reset 
> > > behavior.  In other words, we can say that Alice is authorized to 
> > > reset Bob's counter (or, equivalently, that Alice is 
> authorized to 
> > > prevent Bob's execution of Proc A). 
> > > 
> > > > not even Integrity or 
> > > > Encryption (as in the cases of H-MAC or dsig), 
> > > > was involved.... 
> > > 
> > > Yes, these have independent uses; clearly sometimes 
> AuthN+AuthZ is 
> > > enough.  However, the heartbeat example doesn't 
> demonstrate that AuthN
> > 
> > > is enough by itself, because there is more taking place than just 
> > > AuthN. 
> > > 
> > > --Pete 
> > > Pete Wenzel <pete@seebeyond.com> 
> > > SeeBeyond 
> > > Standards & Product Strategy 
> > > +1-626-471-6311 (US-Pacific) 
>

Received on Tuesday, 23 July 2002 19:50:58 UTC