[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Ideas from the I&A Forum

Hi Paul.


At 12:41 PM 7/10/96 -0700, PALAMBER.US.ORACLE.COM wrote:

>There are some open references to US government designs for authorization back 
>in the 1987, 1988 time frame.  The descriptions are a little obscure since the 
>signed authorization information was called an auxiliary vector.  This 
>"vector" augmented the longer term identity information.  Most of this work 
>was published by NIST as part of the SDNS program ... I will attempt to find 
>the references (somewhere in a box in my garage :-(.   

There's at least one person on the list who was at NIST, maybe in that
timeframe, and I've CC:'ed Denny Branstad.  Perhaps one of them has the
references.

Do you think we should add these citations to the I-D?

>Some of the SDNS work included attempts to create a language for access 
>control.  Labeling of information is a difficult problem for governments since 
>it needs to consider the many existing ways to label classified documents.  
>"Access" is only one aspect of authorization, but the use of labels to define 
>roles or capabilities needs to be considered in the broader problem set.  

I'm especially interested in this NIST work.  After the I&A forum, I want to
add an <auth> line for security clearance, at least, and cite NIST's
standard set of clearance labels.  If there is additional such labeling
information, that might help also.

In this case, we need to distinguish between access (or other (delete?))
permissions and labels for the objects being accessed (or otherwise
manipulated).  SPKI certificates make sense for the entity desiring access
but not for the data, IMHO.  Do you agree?

This issue threatened the bog down the I&A forum, for a short while.  Fine
grain access permission is wonderful stuff, but it depends on enforcement by
some system which holds the objects being accessed.  If that system is
vanilla UNIX, you don't have a whole bunch of options.

>The best mechanism to date that I have seen for the definition of machine 
>readable "security policies" is the W3C PICS work.  This work primarily 
>defines lables and would need some minor extensions to cover the broader set 
>of generic authorization requirements. 

That's a very good suggestion.  We should probably get <auth> statements
from the PICS folks.  The two I've heard asked for are:

BIRTH-DATE: <date>

and

NATIONALITY: <country-code>
which is really a subset of the "LOCATION:" <auth> option we did include.

Of course, I don't know who you would trust to be <issuer> for a birth-date
certificate.  The person's parent?  Who do you trust to attest to parenthood?


>Fairly complete authorization systems have been documented by ECMA in the 
>definition of Privilage Access Certificates (PACs).  PACs provide shorter 
>lived authorization services (signed) that are linked to the longer term X.509 
>identities. 

I'm not familiar with ECMA.

 - Carl

+--------------------------------------------------------------------------+
|Carl M. Ellison          cme@cybercash.com   http://www.clark.net/pub/cme |
|CyberCash, Inc.                              http://www.cybercash.com/    |
|207 Grindall Street           PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
|Baltimore MD 21230-4103       T:(410) 727-4288     F:(410)727-4293        |
+--------------------------------------------------------------------------+