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

[Mike Pelletier]

On Wed, 9 Feb 2000, Christopher Petrilli wrote:

> I believe that anything based on this chaining is going to be
> difficult to explain, but perhaps what I've don is difficult as well.  
> How do you know when to stop trying to authenticate? Or do you only
> take one step at a time?

    You stop when you've run out of loginMethods, or a loginMethod is
successful.

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

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

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

> They are calibrated by the security office, otherwise you are dictating
> things to the security officer.  We could provide guidelines, but many
> people have different risk vectors they are willing to accept or mitigate as
> they see appropriate to their environment.  Call it 0-10 if you wish, call
> it red, orange, yellow, green, blue, indigo, violet, call it the periodic
> table of elements, it ends up being an arbitrary scale regardless, unless
> you dictate the security policy of the organization from a software
> perspective. 

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

    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.

> > Shouldn't receiving a cleartext password constrain the upper bound
> > that this user's confidence can EVER attain, until the password has been
> > securely changed?  Or does SSL not use the same password to authenticate?
> > (I don't know a lot about how SSL works, or what services it provides.)
> 
> Securely changed?  I'm no sure I follow.  SSL is a cryptographic system for
> private transmission of data, it MAY provide an authentication mechanism
> using X.509v3 public key certificates.

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

   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?

    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.

    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.

-- 
Mike Pelletier                          email: mike@digicool.com
Mild mannered software developer          icq: 7127228
by day, super villain by night.         phone: 519-884-2434