Mailing List Archive

Could this be used to incrementally increase a user's rights depending
on their
"past good behavior" in a somewhat automated way ? Thus as confidence in
a usre's
good behavior increases the system automatically (or with some human
filtering) allows him
greater privileges ( perhaps short of admin).

Am I grokking this right ?
Nitin Borwankar

Christopher Petrilli wrote:
>
> [. This is something I've been mulling for years in the PKI world, and so
> springs forth a bit more mature, I hope :-) This is also posted on my
> Zope.org area: http://www.zope.org/Members/petrilli/ConfidenceMetric ]
>
> I've attached it, unfortunately it gets incorrectly formatted by my email
> manager, and I can't figure out how to fix it :-)
>
> Please respond to the list :-)
>
> Chris
> --
> | Christopher Petrilli Python Powered Digital Creations, Inc.
> | petrilli@digicool.com http://www.digicool.com
>
> ------------------------------------------------------------------------
> Name: Confidence.stx
> Confidence.stx Type: Plain Text (text/plain)
> Encoding: base64

This is pretty neat. I explored accomplishing a number of the goals
this enables with the UniversalUserFolder stuff Ty and Phillip are working
on. Instead of each loginMethod (the back end which authenticates a user)
returning a confidence value, they are arranged in the order of the
confidence we have in that method's method of authenticating a user, most
confident to least confident. The first one that returns a user object is
the one you use. Since the loginMethod itself returns the user object,
you have the ability to munge the user beforehand, constraining the roles
to whatever is appropreate for the method you used. If you try to do
something for which you have the 'granted roles' but not the 'available
roles', the login interface is presented (retina scanner prompts you,
whatever) and you have the opportunity to authenticate yourself with
higher confidence and so receive the needed roles to continue.

For instance, the first loginMethod may look for a digital signature
(granting access to sensitive company and personal data), the second may
look for a password (granting access to sensitive personal data), and the
third may just look for some sort of identity cookie (granting access to
no sensitive data, but putting the user's preferences into effect).

The role-munging hasn't received any formal treatment in the UUF, but
I see that maybe it should. Perhaps instead of actual munging, the
loginMethod should be able to specify the restrictions, which are applied
by getRoles or something.

What I like about this system is it doesn't have a confidence int.
Perhaps it's just my bias speaking, or I may be missing some key point,
but I don't like arbitrary scales like this. I much prefer to use some
sort of (possibly extensible) enumeration, such as a list of strings, to
express graduations like this. That way every possible value has a
defined meaning. I don't necisarilly know that all subsets of the
possible set of confidence values are 'calibrated' the same. That is, the
difference between 10 and 11 and the difference between 99 and 100 could
be and probably are significantly different. 'Add 10 to your confidence'
is pretty meaningless. I have no idea what the actual result of that
action will be. I'd have to know what each confidence level actually
means, and then I'd end up doing something like 'upgrade_confidence(50 -
get_confidence())' which seems to defeat the purpose of the interface,
though I admit I'm not certain what the purpose is.

What are the advantages of using a confidence value over
confidence-sorted loginMethods?



The rest just out of personal interest.

Your document states:

"In addition, it may (and should) be important to differentiate
the method by which these credentials are presented. A password
sent as clear text may be less trustworthy than one sent over an
SSL session. One might even argue that one sent over a 40-bit SSL
session is less trustworthy than one sent over 128-bit SSL. These
are all security officer decisions in the process of risk
mitigation."

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


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

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

>
> This is pretty neat. I explored accomplishing a number of the goals
> this enables with the UniversalUserFolder stuff Ty and Phillip are working
> on. Instead of each loginMethod (the back end which authenticates a user)
> returning a confidence value, they are arranged in the order of the
> confidence we have in that method's method of authenticating a user, most
> confident to least confident. The first one that returns a user object is
> the one you use. Since the loginMethod itself returns the user object,
> you have the ability to munge the user beforehand, constraining the roles
> to whatever is appropreate for the method you used. If you try to do
> something for which you have the 'granted roles' but not the 'available
> roles', the login interface is presented (retina scanner prompts you,
> whatever) and you have the opportunity to authenticate yourself with
> higher confidence and so receive the needed roles to continue.

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

> For instance, the first loginMethod may look for a digital signature
> (granting access to sensitive company and personal data), the second may
> look for a password (granting access to sensitive personal data), and the
> third may just look for some sort of identity cookie (granting access to
> no sensitive data, but putting the user's preferences into effect).

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.

> The role-munging hasn't received any formal treatment in the UUF, but
> I see that maybe it should. Perhaps instead of actual munging, the
> loginMethod should be able to specify the restrictions, which are applied
> by getRoles or something.

Hmm, I think these two ideas should not be combined. The determination of
Roles is a "confidence" issue, not directly a result of authentication. If
you were to mix and match authentication in the future, you'd still have a
problem with understanding the interaction of roles.

> What I like about this system is it doesn't have a confidence int.
> Perhaps it's just my bias speaking, or I may be missing some key point,
> but I don't like arbitrary scales like this. I much prefer to use some
> sort of (possibly extensible) enumeration, such as a list of strings, to
> express graduations like this. That way every possible value has a
> defined meaning. I don't necisarilly know that all subsets of the
> possible set of confidence values are 'calibrated' the same. That is, the
> difference between 10 and 11 and the difference between 99 and 100 could
> be and probably are significantly different. 'Add 10 to your confidence'
> is pretty meaningless. I have no idea what the actual result of that
> action will be. I'd have to know what each confidence level actually
> means, and then I'd end up doing something like 'upgrade_confidence(50 -
> get_confidence())' which seems to defeat the purpose of the interface,
> though I admit I'm not certain what the purpose is.

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.

The purpose is not think about the number, bu your requirement, in
retrospect, get_confidence() shouldn't exist. Because developers might do
what you're arguing which is distinctly non OO in my opinion. My mistake.

> What are the advantages of using a confidence value over
> confidence-sorted loginMethods?

Issues of abstraction and the fact that login methods create confidence, and
you might change them around as technology/policy changes, but that Roles
are metric driven, not authentication method driven. The two are largely
detached, and I believe out of distinct necessity.

> The rest just out of personal interest.
>
> Your document states:
>
> "In addition, it may (and should) be important to differentiate
> the method by which these credentials are presented. A password
> sent as clear text may be less trustworthy than one sent over an
> SSL session. One might even argue that one sent over a 40-bit SSL
> session is less trustworthy than one sent over 128-bit SSL. These
> are all security officer decisions in the process of risk
> mitigation."
>
> 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.

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

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

At 02:29 PM 2/9/00 -0500, 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?

Let's say you have:

* LoginMethod 3: Token cookie w/SSL
* LoginMethod 2: Basic auth
* LoginMethod 1: REMOTE_USER auth

If they are checked in this order, Loginmethod 3 checks if the request is
SSL and there's a valid token cookie. If not, it passes and LoginMethod 2
checks for basic auth. If basic auth isn't there or doesn't match, it
drops to LoginMethod 1. If LoginMethod 1 sees a REMOTE_USER environment
variable, it asks a UserSource for the user object, and then asks the user
object to authenticate based on the credentials the LoginMethod extracted
from the request. The LoginMethod does *not* "authenticate" the user,
(with the current exception of the REMOTE_USER LoginMethod, which avoids
calling the user's authenticate() method since authentication has been done
by the web server).

LoginMethods are pluggable seperately from UserSources, and it is the
UserSources (and user objects themselves) that determine roles.


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

It's seperate. Actually, it sounds like you might want to have the
LoginMethod have a way to tell the user object where it got the credentials
from. But probably confidence as well as roles are a function of the
user/UserSource objects to determine. I'd prefer to keep LoginMethods as
just strategy objects for dealing with the mechanics of marshalling
authentication data from the REQUEST.



>> For instance, the first loginMethod may look for a digital signature
>> (granting access to sensitive company and personal data), the second may
>> look for a password (granting access to sensitive personal data), and the
>> third may just look for some sort of identity cookie (granting access to
>> no sensitive data, but putting the user's preferences into effect).
>
>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.

I think he means client certificates, although it's entirely possible that
you could create a custom LoginMethod for a specialized application.


>> The role-munging hasn't received any formal treatment in the UUF, but
>> I see that maybe it should. Perhaps instead of actual munging, the
>> loginMethod should be able to specify the restrictions, which are applied
>> by getRoles or something.
>
>Hmm, I think these two ideas should not be combined. The determination of
>Roles is a "confidence" issue, not directly a result of authentication. If
>you were to mix and match authentication in the future, you'd still have a
>problem with understanding the interaction of roles.

We do mix and match authentication now. That's one of the key ideas behind
the UUF (now called Login Manager), is that it eliminates the N x M problem
of writing UserFolders for N login methods and M sources of user data. But
the design currently leaves roles entirely to the user objects, which in
turn can delegate that to their UserSource if appropriate for the specific
implementation.


>> What are the advantages of using a confidence value over
>> confidence-sorted loginMethods?
>
>Issues of abstraction and the fact that login methods create confidence, and
>you might change them around as technology/policy changes, but that Roles
>are metric driven, not authentication method driven. The two are largely
>detached, and I believe out of distinct necessity.

So, should we have loginMethods have a confidence property that gets passed
to the user object with the authenticate() operation? (The user can treat
it additively, if that's what's desired.) Or do user objects not care what
the login method is? Now would be a good time to know before the protocols
get any more hardened.

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

I think I would find the calculated confidence value confusing when trying
to figure out what permissions would actually be granted to which users
under what conditions, at least as I understand the proposal.

"What?! Someone downloaded our top secret data using a password they
were able to sniff from the network because it was sent in cleartext??"

"Yeah well, a few weeks ago I thought I might boost the confidence
value a little bit for people who used hard-to-guess passwords, you know,
if they put in lots of numbers and uppercase letters and stuff, but I
didn't realize it would boost the confidence value past the 70% point which
allows access to top secret data when combined with the confidence boost
they get for being on an internal LAN IP addresss, sigh..."

Of course, this may merely be an indication that I shouldn't be working in
the security office :-)

The idea of constraints is great. That allows a security policy to
actually enforce a requirement such that sensitive functions can only be
accessed over a secure channel.

Automatic escalation of the required security of the login to make a role
transition is cool, but a word of caution for the admin who naively marks a
"manager" role as needing "https", and thinks that makes the access secure.
Guess what? Unless I have to use a different password, I just logged in
ten minutes ago on cleartext http with the same password.

What about an enumeration of things that someone might care about in a
security policy:

- has the user actually provided credentials, or are we just guessing
who they are based on a cookie or whatever at this point.

- was authentication (i.e. the password) sent using a secure mechanism?
Or more precisely, never gets sent insecurely?

- is there someone vouching for a connection between the identification
(such as a username) and the actual identity of the user? (employer
vouches for employees, friends for friends, perhaps some certificate
authority checks driver's license)

- can a user let their account be used by a friend, relative, or
collegue (probably)


Andrew

Hi,
Opps, I sent this to the wrong list last night.

Cc: zope@zope.org
Subject: [Zope] RE: [Zope-PTK] PROPOSAL: A Confidence Mechanism in User
Role Management


I love this Confidence Rheostat! Along with an integrated content
tagging framework you can really tailor security to need. Your
POST via SSL & volatile cookie/tokens make it work. I just have
couple of concerns and one addition. I am just seeing this thread
so forgive me if this has been asked and answered.

Would this mechanism allow for chaining of access requests? Something
analogues to "Oh, you want to see THAT file, well I don't know but,
I know you does, hang on.." So specific resources or capabilities
would delegate access authorization to other systems.

Can this dynamic security mechanism store different confidence
levels for different conditions? Multiple user logon in one
6 hour period from client location in time zone 10 hours apart
could trigger higher required confidence.

With these type of fundamental security model changes it would be
great to enable a very fine grained distributed security model. This
would enable any system user to create, manage, and use system
security capabilities. A user could then share one file from their
Member Folder with other select system users. They could also allow
only a subset of these users to "vouch" for access by other not
originally on the list. This could be a very lightweight list of
"locks" associated with each resource and list of "keys" associated
with any consumer of a resource. Your SSL enabled creation of a
cookie token would be just a special case of one of these "keys".
Each "Key" would have a TTL and a set of resource locks it might
be able to open.

I am sure that all of this is way more then you had in mind to solve.
At the least I would hope that this mechanism would allow any two
portals to share the client cookies confidence level. I understand that
there needs to be distinct cookies for each site and each client machine.
The target would be to simplify the life of an honest users you is the
member of multiple portal communities and uses multiple machines. A
ring of cooperating portals could automagically generate a new cookie
if a valid cookie from a brother portal was found. Actually this last
idea seems totally undoable but, the need still exists.

Sorry for the long message. In any case, if your proposal could be
quickly implemented it would be so much better then the way things work now.

Best,

Chip Vanek
chip@upcast.com

>-----Original Message-----
>From: zope-ptk-admin@zope.org [mailto:zope-ptk-admin@zope.org]On Behalf
>Of Christopher Petrilli
>Sent: Thursday, February 10, 2000 6:08 AM
>To: Rob Page; Mike Pelletier
>Cc: zope-ptk@zope.org
>Subject: Re: [Zope-PTK] PROPOSAL: A Confidence Mechanism in User Role
>Management
>
>
>On 2/9/00 11:47 PM, Rob Page at rob.page@digicool.com wrote:
>
>>> 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.
>>
>> This is a valid point. This is why many sites have you
>login over SSL.
>> Perhaps they assign you an expiring cookie which you can carry around
>> and over unsecure channels. Ideally, password specification and
>> password presentation are all done over secure comm - then you don't
>> have to discount the confidence in the password as an accurate
>> authentication mechanism.
>
>This is what I was mentioning at the bottom of another email,
>which is that
>you have the following chain of events:
>
> * User is presented a login form over HTTP
> * Form is POSTED via SSL, which sets a cookie in the browser
> * Cookie is volatile and used for auth during session
>
>The cookie must be something non-guessable, so I proposed the
>following:
>
> base64(sha1(username + ip_address + random_int))
>
>This gives you a token that should not be "guessable" and in
>addition, as
>long as you keep the random integer chosen around, you can
>validate that the
>cookie is valid using 2 options:
>
> * Recompute auth information and compare (the correct way,
>long story)
> * Store IP address and precalced cookie, and compare those.
>
>Chris
>--
>| Christopher Petrilli Python Powered Digital
>Creations, Inc.
>| petrilli@digicool.com
http://www.digicool.com


_______________________________________________
Zope-PTK maillist - Zope-PTK@zope.org
http://lists.zope.org/mailman/listinfo/zope-ptk



_______________________________________________
Zope maillist - Zope@zope.org
http://lists.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope-dev )

On 2/11/00 1:30 PM, Chip Vanek at chip@upcast.com wrote:

> I love this Confidence Rheostat! Along with an integrated content
> tagging framework you can really tailor security to need.

We already have this, just to be clear. It's based on Permissions on
objects interacting with Roles. Did you intend another "framework" that
isn't there at this point?

> Your POST via SSL & volatile cookie/tokens make it work. I just have
> couple of concerns and one addition. I am just seeing this thread
> so forgive me if this has been asked and answered.

This is a common paradigm actually, used by a bunch of people ;-) I hardly
thought this idea up... though I should patent it anyway! :-)

> Would this mechanism allow for chaining of access requests? Something
> analogues to "Oh, you want to see THAT file, well I don't know but,
> I know you does, hang on.." So specific resources or capabilities
> would delegate access authorization to other systems.

Um, I don't follow this? I don't think we have any intention of
externalizing the authentication and authorization code to an "external
system".

> Can this dynamic security mechanism store different confidence
> levels for different conditions? Multiple user logon in one
> 6 hour period from client location in time zone 10 hours apart
> could trigger higher required confidence.

What is a time zone on the Internet?

> With these type of fundamental security model changes it would be
> great to enable a very fine grained distributed security model.

Very fine grained security models have traditionally been abysmal failures
(I can point at some MSSI stuff done at NSA if you want examples). They are
too complex for 99.99% of the population, and valuable to an even smaller
percentage.

> This would enable any system user to create, manage, and use system
> security capabilities. A user could then share one file from their
> Member Folder with other select system users. They could also allow
> only a subset of these users to "vouch" for access by other not
> originally on the list. This could be a very lightweight list of
> "locks" associated with each resource and list of "keys" associated
> with any consumer of a resource. Your SSL enabled creation of a
> cookie token would be just a special case of one of these "keys".
> Each "Key" would have a TTL and a set of resource locks it might
> be able to open.

Way out of the scope of this discussion, so I won't even address it. This
is largely doable today with local roles.

> I am sure that all of this is way more then you had in mind to solve.

It needs to have a problem to solve first that is more than hypothetical I
believe.

> At the least I would hope that this mechanism would allow any two
> portals to share the client cookies confidence level.

How? Cookies are URI specific.

> I understand that
> there needs to be distinct cookies for each site and each client machine.

Yes. So what exactly have you gained?

> The target would be to simplify the life of an honest users you is the
> member of multiple portal communities and uses multiple machines.

I believe a documented case of said complexity would be a good starting
point. What complexity are you simplifying?

> A ring of cooperating portals could automagically generate a new cookie
> if a valid cookie from a brother portal was found. Actually this last
> idea seems totally undoable but, the need still exists.

How would they find this cookie? It's not available to any portal but the
one who created it. I'm not convinced the need exists based on any stated
requirement.

> Sorry for the long message. In any case, if your proposal could be
> quickly implemented it would be so much better then the way things work now.

Let's try and stay focused on a goal driven system, I think this is critical
to success and leave the "wild blue sky" for later.

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

Hi,

>-----Original Message-----
>From: Christopher Petrilli [mailto:petrilli@digicool.com]
>Sent: Friday, February 11, 2000 1:42 PM
>To: Chip Vanek; zope-ptk@zope.org
>Subject: Re: [Zope-PTK] PROPOSAL: A Confidence Mechanism in User
>RoleManagement
>
>
>On 2/11/00 1:30 PM, Chip Vanek at chip@upcast.com wrote:
>
>> I love this Confidence Rheostat! Along with an integrated content
>> tagging framework you can really tailor security to need.
>
>We already have this, just to be clear. It's based on Permissions on
>objects interacting with Roles. Did you intend another
>"framework" that
>isn't there at this point?
>

I am rather new to Zope and do not yet understand the whole
roles & permissions implementation. Thanks for setting me straight.

>> Your POST via SSL & volatile cookie/tokens make it work. I just have
>> couple of concerns and one addition. I am just seeing this thread
>> so forgive me if this has been asked and answered.
>
>This is a common paradigm actually, used by a bunch of people
>;-) I hardly
>thought this idea up... though I should patent it anyway! :-)
>
>> Would this mechanism allow for chaining of access requests?
>Something
>> analogues to "Oh, you want to see THAT file, well I don't know but,
>> I know you does, hang on.." So specific resources or capabilities
>> would delegate access authorization to other systems.
>
>Um, I don't follow this? I don't think we have any intention of
>externalizing the authentication and authorization code to an "external
>system".
>

Yes, this comment was primarily focused on externalizing the
authorization requests for some users. I was interested in a way
to allow Zope to provide services to 10k++ users were some subset
of the users are members of another trusted system.

>> Can this dynamic security mechanism store different confidence
>> levels for different conditions? Multiple user logon in one
>> 6 hour period from client location in time zone 10 hours apart
>> could trigger higher required confidence.
>
>What is a time zone on the Internet?

OK the example sucks. I followed the thread back to your proposal
and see that you have the concept of constraints on the roles that
can be granted. This question was about having a constraint type
structure for user access method. HTTP is just the most popular
access type now. What about SOAP, XML-RPC, some ubiquitous Microsoft
access method like COM, WAP, or some emerging access method.
>
>> With these type of fundamental security model changes it would be
>> great to enable a very fine grained distributed security model.
>
>Very fine grained security models have traditionally been
>abysmal failures
>(I can point at some MSSI stuff done at NSA if you want
>examples). They are
>too complex for 99.99% of the population, and valuable to an
>even smaller
>percentage.
>

Yeh, if you could send me some of those pointers it would be
great. My daytime job is building services using HP new e'Speak
technology and they are introducing some security models and concepts
that are beyond my present understanding (no great stretch;).

>> This would enable any system user to create, manage, and use system
>> security capabilities. A user could then share one file from their
>> Member Folder with other select system users. They could also allow
>> only a subset of these users to "vouch" for access by other not
>> originally on the list. This could be a very lightweight list of
>> "locks" associated with each resource and list of "keys" associated
>> with any consumer of a resource. Your SSL enabled creation of a
>> cookie token would be just a special case of one of these "keys".
>> Each "Key" would have a TTL and a set of resource locks it might
>> be able to open.
>
>Way out of the scope of this discussion, so I won't even
>address it. This
>is largely doable today with local roles.

OK, As I understand more about Zope security and roles, I would
like to revisit this item.

>
>> I am sure that all of this is way more then you had in mind to solve.
>
>It needs to have a problem to solve first that is more than
>hypothetical I
>believe.
>
>> At the least I would hope that this mechanism would allow any two
>> portals to share the client cookies confidence level.
>
>How? Cookies are URI specific.
>
>> I understand that
>> there needs to be distinct cookies for each site and each
>client machine.
>
>Yes. So what exactly have you gained?

Nothing, stupid idea...

>
>> The target would be to simplify the life of an honest users
>you is the
>> member of multiple portal communities and uses multiple machines.
>
>I believe a documented case of said complexity would be a good starting
>point. What complexity are you simplifying?
>
>> A ring of cooperating portals could automagically generate a
>new cookie
>> if a valid cookie from a brother portal was found. Actually
>this last
>> idea seems totally undoable but, the need still exists.
>
>How would they find this cookie? It's not available to any
>portal but the
>one who created it. I'm not convinced the need exists based
>on any stated
>requirement.
>

Sharing credentials between sites is likely a pipe dream so
ignore that crud.

>> Sorry for the long message. In any case, if your proposal could be
>> quickly implemented it would be so much better then the way
>things work now.
>
>Let's try and stay focused on a goal driven system, I think
>this is critical
>to success and leave the "wild blue sky" for later.
>
>Chris
>--
>| Christopher Petrilli Python Powered Digital
>Creations, Inc.
>| petrilli@digicool.com
http://www.digicool.com


Agreed,

Chip

On 2/11/00 6:29 PM, Chip Vanek at chip@upcast.com wrote:

> I am rather new to Zope and do not yet understand the whole
> roles & permissions implementation. Thanks for setting me straight.

You should do some especially focused looking a the concept of local roles
granted to a user on a specific object.

>> Um, I don't follow this? I don't think we have any intention of
>> externalizing the authentication and authorization code to an "external
>> system".
>>
>
> Yes, this comment was primarily focused on externalizing the
> authorization requests for some users. I was interested in a way
> to allow Zope to provide services to 10k++ users were some subset
> of the users are members of another trusted system.

If such a system provides an API for authentication, one could theoretically
construct a replacement UserFolder that interfaced with it. This would be
non-trivial in many cases.

>> What is a time zone on the Internet?
>
> OK the example sucks. I followed the thread back to your proposal
> and see that you have the concept of constraints on the roles that
> can be granted. This question was about having a constraint type
> structure for user access method. HTTP is just the most popular
> access type now. What about SOAP, XML-RPC, some ubiquitous Microsoft
> access method like COM, WAP, or some emerging access method.

This was at least discussed as being a potential factor in confidence,
however it's more interesting as different views of the same data, something
that Jim Fulton and I had a talk about the other day. Some data might not
be visible from certain perspectives, or presented in a totally different
way. This is a product, in my mind, of the model-view-controller pattern.

>> Very fine grained security models have traditionally been
>> abysmal failures
>> (I can point at some MSSI stuff done at NSA if you want
>> examples). They are
>> too complex for 99.99% of the population, and valuable to an
>> even smaller
>> percentage.
>>
>
> Yeh, if you could send me some of those pointers it would be
> great. My daytime job is building services using HP new e'Speak
> technology and they are introducing some security models and concepts
> that are beyond my present understanding (no great stretch;).

I will dig up what I can publish (much of the research is not public, but
not classified either, lalalala). The core issue is that the combinatorial
semantics of a fine-grained model makes it much much easier to make critical
mistakes. It also makes it harder to understand.

The current Zope model is exceptionally fine-grained by most people's
standards, in that it allows you to apply permissions on a per-object basis.
The only thing more "fine grained" one might want is to control a specific
method on a specific object, but even this can be done using a Proxy role on
another object.

>>> This would enable any system user to create, manage, and use system
>>> security capabilities. A user could then share one file from their
>>> Member Folder with other select system users. They could also allow
>>> only a subset of these users to "vouch" for access by other not
>>> originally on the list. This could be a very lightweight list of
>>> "locks" associated with each resource and list of "keys" associated
>>> with any consumer of a resource. Your SSL enabled creation of a
>>> cookie token would be just a special case of one of these "keys".
>>> Each "Key" would have a TTL and a set of resource locks it might
>>> be able to open.
>>
>> Way out of the scope of this discussion, so I won't even
>> address it. This
>> is largely doable today with local roles.
>
> OK, As I understand more about Zope security and roles, I would
> like to revisit this item.

My point was you are asking about an application level instantiation of some
security model at this point. We are discussing the model itself.

> Sharing credentials between sites is likely a pipe dream so
> ignore that crud.

This is simply a technical restriction of the current system. If you use
PKI-style client certificates then you already do share "credentials,"
however there is a pretty heavy cost to doing so.

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

>-----Original Message-----
>From: Christopher Petrilli [mailto:petrilli@digicool.com]
>Sent: Saturday, February 12, 2000 7:46 AM
>To: Chip Vanek; zope-ptk@zope.org
>Subject: Re: [Zope-PTK] PROPOSAL: A Confidence Mechanism in
>UserRoleManagement
>
>
>On 2/11/00 6:29 PM, Chip Vanek at chip@upcast.com wrote:
>
>> I am rather new to Zope and do not yet understand the whole
>> roles & permissions implementation. Thanks for setting me straight.
>
>You should do some especially focused looking a the concept of
>local roles
>granted to a user on a specific object.

Yup, after I get some of this initial work on PTK done I will
focus my attention on the existing security model. I am sure that
it is very capable but for me not yet "self-revealing" ;)

>
>>> Um, I don't follow this? I don't think we have any intention of
>>> externalizing the authentication and authorization code to
>an "external
>>> system".
>>>
>>
>> Yes, this comment was primarily focused on externalizing the
>> authorization requests for some users. I was interested in a way
>> to allow Zope to provide services to 10k++ users were some subset
>> of the users are members of another trusted system.
>
>If such a system provides an API for authentication, one could
>theoretically
>construct a replacement UserFolder that interfaced with it.
>This would be
>non-trivial in many cases.
>
>>> What is a time zone on the Internet?
>>
>> OK the example sucks. I followed the thread back to your proposal
>> and see that you have the concept of constraints on the roles that
>> can be granted. This question was about having a constraint type
>> structure for user access method. HTTP is just the most popular
>> access type now. What about SOAP, XML-RPC, some ubiquitous Microsoft
>> access method like COM, WAP, or some emerging access method.
>
>This was at least discussed as being a potential factor in confidence,
>however it's more interesting as different views of the same
>data, something
>that Jim Fulton and I had a talk about the other day. Some
>data might not
>be visible from certain perspectives, or presented in a
>totally different
>way. This is a product, in my mind, of the
>model-view-controller pattern.

It was the different view of the same data element that I was
trying to express. I would like to allow users to see certain new
items via their cell phone browsers or wireless PDAs. They should
also be able to add new content or reply using wireless pages or
popup forms on other websites.

>
>>> Very fine grained security models have traditionally been
>>> abysmal failures
>>> (I can point at some MSSI stuff done at NSA if you want
>>> examples). They are
>>> too complex for 99.99% of the population, and valuable to an
>>> even smaller
>>> percentage.
>>>
>>
>> Yeh, if you could send me some of those pointers it would be
>> great. My daytime job is building services using HP new e'Speak
>> technology and they are introducing some security models and concepts
>> that are beyond my present understanding (no great stretch;).
>
>I will dig up what I can publish (much of the research is not
>public, but
>not classified either, lalalala). The core issue is that the
>combinatorial
>semantics of a fine-grained model makes it much much easier to
>make critical
>mistakes. It also makes it harder to understand.

Thanks! I have been reading a number of ideas in the space including
the work at www.erights.org. With inclusion of some of these attributes
Zope could become a killer app.

>
>The current Zope model is exceptionally fine-grained by most people's
>standards, in that it allows you to apply permissions on a
>per-object basis.
>The only thing more "fine grained" one might want is to
>control a specific
>method on a specific object, but even this can be done using a
>Proxy role on
>another object.
>

Aboslutely, One of the things that attracted me to Zope was the secure
exposing of individual objects to the web. I am still far from fully
understanding how this works now but, would like to keep tabs on your work
as motivation to get "myself up to speed."


>>>> This would enable any system user to create, manage, and use system
>>>> security capabilities. A user could then share one file from their
>>>> Member Folder with other select system users. They could
>also allow
>>>> only a subset of these users to "vouch" for access by other not
>>>> originally on the list. This could be a very lightweight list of
>>>> "locks" associated with each resource and list of "keys" associated
>>>> with any consumer of a resource. Your SSL enabled creation of a
>>>> cookie token would be just a special case of one of these "keys".
>>>> Each "Key" would have a TTL and a set of resource locks it might
>>>> be able to open.
>>>
>>> Way out of the scope of this discussion, so I won't even
>>> address it. This
>>> is largely doable today with local roles.
>>
>> OK, As I understand more about Zope security and roles, I would
>> like to revisit this item.
>
>My point was you are asking about an application level
>instantiation of some
>security model at this point. We are discussing the model itself.
>

The interplay between local roles and Zope security is still not
"self revealing" to me yet. I hope to clear up my mental fog soon...


>> Sharing credentials between sites is likely a pipe dream so
>> ignore that crud.
>
>This is simply a technical restriction of the current system.
>If you use
>PKI-style client certificates then you already do share "credentials,"
>however there is a pretty heavy cost to doing so.
>

It is cost of using ful scale PKI that I am trying to avoid. I spend
3 years fighting to get a full PKI infrastructure in place inside
Hewlett-Packard and still feel the scars. They now have over 50k
certificates and a CA linked to a master directory or all 125k users
but, I no longer have any love for a corporate IT job.

Best,

Chip


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

Chip Vanek wrote:
...
> >My point was you are asking about an application level
> >instantiation of some
> >security model at this point. We are discussing the model itself.
> >
>
> The interplay between local roles and Zope security is still not
> "self revealing" to me yet. I hope to clear up my mental fog soon...

Rmember when Disneyland had different kinds of tickets fo rdifferent
rides? TO me, the Zope Roles/Users setup is like that. When the user
logs in, s/he gets a ticket(role), or a set of tickets(roles). When s/he
goes to 'ride a ride' (use a db method, view a page, etc..), Zope looks
to make sure s/he has the right ticket.

And Zope has a helluva lot more rides then DL. ;^)

> >> Sharing credentials between sites is likely a pipe dream so
> >> ignore that crud.
> >
> >This is simply a technical restriction of the current system.
> >If you use
> >PKI-style client certificates then you already do share "credentials,"
> >however there is a pretty heavy cost to doing so.
> >
>
> It is cost of using ful scale PKI that I am trying to avoid. I spend
> 3 years fighting to get a full PKI infrastructure in place inside
> Hewlett-Packard and still feel the scars. They now have over 50k
> certificates and a CA linked to a master directory or all 125k users
> but, I no longer have any love for a corporate IT job.

AHA! So _YOU'RE_ the one to blame!! ;^)



--
In flying I have learned that carelessness and overconfidence are
usually far more dangerous than deliberately accepted risks.
-- Wilbur Wright in a letter to his father, September 1900

>-----Original Message-----
>From: ucntcme@libc.org [mailto:ucntcme@libc.org]On Behalf Of Bill
>Anderson
>Sent: Saturday, February 12, 2000 1:28 PM
>To: Chip Vanek; zope-ptk@zope.org
>Subject: Re: [Zope-PTK] PROPOSAL: A Confidence Mechanism in
>UserRoleManagement
>
>
>Chip Vanek wrote:
>...
>> >My point was you are asking about an application level
>> >instantiation of some
>> >security model at this point. We are discussing the model itself.
>> >
>>
>> The interplay between local roles and Zope security is still not
>> "self revealing" to me yet. I hope to clear up my mental fog soon...
>
>Rmember when Disneyland had different kinds of tickets fo rdifferent
>rides? TO me, the Zope Roles/Users setup is like that. When the user
>logs in, s/he gets a ticket(role), or a set of tickets(roles).
>When s/he
>goes to 'ride a ride' (use a db method, view a page, etc..), Zope looks
>to make sure s/he has the right ticket.
>
>And Zope has a helluva lot more rides then DL. ;^)

Hey, That description really helped! How did you know my mind
needs examples from childhood. Thanks for the clear mental
map.

>
>> >> Sharing credentials between sites is likely a pipe dream so
>> >> ignore that crud.
>> >
>> >This is simply a technical restriction of the current system.
>> >If you use
>> >PKI-style client certificates then you already do share
>"credentials,"
>> >however there is a pretty heavy cost to doing so.
>> >
>>
>> It is cost of using ful scale PKI that I am trying to avoid. I spend
>> 3 years fighting to get a full PKI infrastructure in place inside
>> Hewlett-Packard and still feel the scars. They now have over 50k
>> certificates and a CA linked to a master directory or all 125k users
>> but, I no longer have any love for a corporate IT job.
>
>AHA! So _YOU'RE_ the one to blame!! ;^)
>
>
Sorry ;( We all need work. I have matured since then...

Best,

Chip
>
>--
>In flying I have learned that carelessness and overconfidence are
>usually far more dangerous than deliberately accepted risks.
> -- Wilbur Wright in a letter to his father, September 1900
>

Chip Vanek wrote:

> >Rmember when Disneyland had different kinds of tickets fo rdifferent
> >rides? TO me, the Zope Roles/Users setup is like that. When the user
> >logs in, s/he gets a ticket(role), or a set of tickets(roles).
> >When s/he
> >goes to 'ride a ride' (use a db method, view a page, etc..), Zope looks
> >to make sure s/he has the right ticket.
> >
> >And Zope has a helluva lot more rides then DL. ;^)
>
> Hey, That description really helped! How did you know my mind
> needs examples from childhood.

My day job is at HP ... in IT ;)

> Thanks for the clear mental
> map.

No Problem, glad it helped. Hey, mebbe I'll put this on Zope.org as a
tip or something...

--
In flying I have learned that carelessness and overconfidence are
usually far more dangerous than deliberately accepted risks.
-- Wilbur Wright in a letter to his father, September 1900