RE: "Onion model" explained

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