RE: "Onion model" explained

> 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. 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.

My point is that AuthN alone is never sufficient. 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.

  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.

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 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,
but if authenticated entities are allowed to do X and unauthenticated
entities cannot do X, that is AuthZ.

Hal
> 
> Joe Hui
> Exodus, a Cable & Wireless service
> ==================================.
> 
>  -----Original Message-----
> From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
> Sent: Wednesday, July 10, 2002 2:41 PM
> To: Joseph Hui; www-ws-arch@w3.org
> Subject: RE: "Onion model" explained
> 
> 
> Apparently I am on the www-ws-arch mailing list, so you don't 
> have to add me explicitly. 
> With respect to the onion model, my question was not so much 
> what it was, as how was it relevant to the three STF 
> objectives. This was explained as relating to the charter 
> requirements objective, which answered my question.
> With respect to the priority, I know it is unreasonable to 
> expect to convert the world to my thinking overnight, but I 
> will take the opportunity to introduce my views. 
> I now firmly believe that Authorization, while a significant 
> technical problem, is not a fundamental service. The ONLY 
> purpose of Authentication is to provide inputs to other 
> security services such as Confidentiality, Integrity, 
> Authorization and Audit Trail.
> For current purposes I will settle for consensus around the 
> idea that "Authentication without Authorization is 
> insufficient". This is what major end users and industry 
> gurus have been saying for the last five years or so.
> Hal 
> > -----Original Message----- 
> > From: Joseph Hui [mailto:Joseph.Hui@exodus.net] 
> > Sent: Wednesday, July 10, 2002 3:14 PM 
> > To: www-ws-arch@w3.org 
> > Cc: hal.lockhart@entegrity.com 
> > Subject: "Onion model" explained 
> > 
> > 
> > Hi all, 
> > 
> > During today's STF telcon I took an action item to 
> > explain in the mailing list what the "onion model" 
> > that we sometimes referred to in the WG's security 
> > related threads was about. 
> > 
> > So here it goes. 
> > 
> > The "Onion model," for the lack of a better term, is in 
> > essence a grouping of the WSAWG sec reqs for the benefit 
> > of prioritizing them for a phased approach in delivering 
> > our sec solutions/standards.  (The phased approach came 
> > about inconsideration of the time-to-market factor often 
> > recited in the WSAWG's discussions.) 
> > 
> > The model comprises, in descending priority: 
> > 
> >    Layer 1) Confidentiality, (Data) Integrity, Authentication; 
> > 
> >          2) Authorization; 
> > 
> >          3) Non-repudiation; 
> > 
> >          4) Accessibility 
> > 
> >          5) The remainder of the WSAWG sec requirements, 
> >             including Auditing. 
> > 
> >    Note that a phase may consist of one or more laysers. 
> >    E.g. the first phase may include layer 1 only, or 
> >    layers 1 & 2, dependent upon future decisions. 
> > 
> > Cheers, 
> > 
> > Joe Hui 
> > Exodus, a Cable & Wireless service 
> > 
>