[Zope-PTK] PROPOSAL: A Confidence Mechanism in User Role Management

[Christopher Petrilli]

On 2/9/00 3:20 PM, Mike Pelletier at mike@digicool.com wrote:

>> Confidence is an important concept in the security world, and so I
>> think its critical to keeping the "authentication method" SEPERATE
>> from the Roles granted.  Blurring these is a sure recipe for confusion
>> and holes.
> 
> Hmm.  So you're saying, instead of manipulating the role constraints
> directly, the authentication mechanism should manipulate the confidence
> value?  That's fine, there simply wasn't a concept of confidence yet.  ;-)

It's foreign to most environments, it's really more of a PKI issue at least
in its origin.  It really does make things easier once you begin to
understand that trust is not a light-switch, but a rheostat. :-)

> Do you think these ideas are far enough along that I should be
> considering how to incorperate them in the UUF for the PTK?

Yes, I think they're critical to a lot of what the PTK wants to do... i.e.
provide amazon.com/yahoo.com/etc style of customization.  We need this to
express any of those ideas.

>> Um, how prey tell will a digital signature work over the Web? FTP? There's
>> no protocol for this, no expressive capability.  Or did you mean a X.509v3
>> certificate for client-authentication?  These are quite different
>> manifestations of a cryptographic protocol.
> 
> Chill thyself, 'digital signature' was just a bogus phrase I pulled
> out of thin air.  :-)  (I pictured the browser signing some token pulled
> from the previous server response with a private key.)  I only needed

Ah ok, having spent 3 years in the PKI world, these words have VERY distinct
meaning, and it's dangerous to throw them around :-)

> phrases with the proper connotations because it was only a hypothetical
> example.  I don't care what the actual authentication/identification
> mechanisms are, just that there are three of them (again, for the sake of
> example) and that each is less strong than the one before it.

Ok...

> Well, yes, I do see how the 0-100 scale can be used to express most
> any symbolic designations you like.  It's just difficult to work with,
> should you ever want to change it once it's in use.  You can do the BASIC
> programming trick of only using every 10th number to leave room for
> expansion, but then when you do expand you have to remember things like
> '20 to 30 is TWO steps, not one' etc., and you have to be able to find out
> how confident you are NOW to determine how much MORE confident you want to
> be.  If you can just insert new symbols into a list, changes to your
> policies would seem to be less painful and error prone.

Except for the difficulty in managing these lists, and the error prone
nature of moving things around in them.  At some point they're just an index
into a list ;-)

> I'm verging on
> (or have progressed to) devil's advocate here, cos I really don't care how
> confidence is expressed.  I'm sold on the general idea, I'm just quibbling
> on particulars.

Ken and I discussed in RT the idea of labels for the values, and leave it
there...  Also, if you see it as "percentages" and not a scale, then it may
make a bit more sense... i.e. you are 0% confiden, or 100% confident, or 75%
confident.

> If you have the time, I'm sure my concerns would be resolved by an
> example of how confidence values might be designated and interpreted.

I'm not sure what you mean by this?

> Alright, it's my understanding that SSL is considered more secure
> because the connection is encrypted, and so things like passwords can't be
> picked out of it.  It's my further understanding that authentication works
> the same way through SSL as through an unencrypted connection.  If these
> assumptions are incorrect, I'm probably spouting utter lark vomit (as they
> say).

No, this is basically correct.

> Theoretically, the first time a cleartext password is received, it's
> just as secure as prior passwords received through a secure pipe, because
> no one's had the opporunity to sniff it.  After that, logic suggests to me
> that not only do we have to be less confident about subsequent cleartext
> passwords, but also passwords received via SSL, since the password has
> been potentially sniffed.  What's to stop someone (who sniffed it) from
> using it via an SSL connection?

Nothing, it's also largely a fact that these passwords are not so easily
sniffed... they're much more easily guessed :-)

> So, if cleartext is less trustworthy because it's sniffable, it
> follows that using cleartext once compromises the secure channels as well,
> and so they should be no more trusted than cleartext UNTIL the password's
> been changed.  Oh.  But, if you are now less-than-confident of the remote
> user, you can't let them change the password so as to become trusted
> again!  D'oh.  Seems like a Catch 22, I must not be getting something.

Exactly, at some point you accept the risk :-)  BTW, you should be using
something like a volatile cookie during the session not apsswords... this by
calculating something liek:

    o UID
    o Ip address
    o random number

and taking the hash of it.

> Again, at this point I'm way over my head (obviously) and not trying
> to contribue so much as enhance my own understanding of these issues.

:-) I understand.

Chris
-- 
| Christopher Petrilli        Python Powered        Digital Creations, Inc.
| petrilli@digicool.com                             http://www.digicool.com