RE*2: Revised list of restrictions and privelege attributes

[[e-mail]]

I guess Cliff will reply too. Here is my 0.02 on Rich's remarks:


> I am having a bit of trouble understand this whole first paragraph.
> Either some ASCII art, or a concrete example showing a user doing
> something like FTP speaking to an ftp server on another machine?
> 
> >  A proxy inherently grants certain rights
> 
> The server that controls the data (i.e., the reference monitor) is
> the entity that actually grants the rights -- it interprets the
> chain and decide whether or not to satisfy the request.

The definition of "rights" you suggest here is (I believe) needlessly
narrower that the conventional one, and seems to seek to give new
semantics to a normal English term. For most systems including those
outside the IT system world it is normal to consider as logically
separate the notions of (1) possessing rights, and (2) seeking authorisation
for a specific operation. It seems inappropriate to conflate the two
concepts.


> 
> >  A flags
> >field associated with each kind of attribute encodes the appropriate
> >behavior if the interpretation of the attributed is not known.
> 
> Reading the next section (Attributes and Restrictions), however, makes me
> think that I'm reading this wrong and that you do really intend to attach
> rights to identities, and not attach rights to objects inside the server.
> Is that right?  If so, that's wrong. :-)

Possession of a proxy (suggested general term which includes e.g.: DCE
privilege attribute cert) permits the assignee to assert privileges granted
by the assigner subject to specified restrictions.


> 
> Can someone explain why the Posix ACL model is not sufficient?

I assume that by the term "POSIX ACL model", you mean the general concept
of POSIX.6 D13 ACLs, ACLEs, and a non-POSIX-specific abstraction of the
POSIX.6 ACL evaluation algorithm (as DCE has, give or take the mask
which should be back in in the next draft anyway).

If so, I would be interested in learning where you see inconsistencies
as I believe that what is being proposed in the AAC WG is reasonably
compatible with the POSIX ACL model.

My view is that while the POSIX ACL model doesn't support restrictions,
it otherwise provides a reasonable framework for defining authorisation
management information outside the POSIX system,  unlike other possible
candidates such as say, the X.500 access control model, which is
excessively complex and too restrictive, and the Netware NDS model which
is not adequately restrictive.


> >Conceptually, the DCE privilege attribute certificate specifies both
> >group information and the local UID.  The name of the privilege server
> >is derived from the name of the principal signing the proxy.
> 
> A DCE pac does not include a local UID.  This information is available
> through the DCE security service, but it is *never* used in making DCE
> authorization decisions.  It is also important to note that a DCE PAC
> never includes any rights.

See previous remark about "rights".


>                        It contains only a set of DCE UUID's which
> identify the user and their group membership(s).  There are various
> levels of certification which can be used on this data.  The strictest
> is that a Kerberos-like session key is used to encrypt the PAC so that
> only the server can decrypt it; as an intermediate level it can be crypto
> checksum'd just to make it tamperproof.
> 
> >encourage the use of GROUP_MEMBERSHIP and LOCAL_UID instead.
> 
> Using LOCAL_UID is probably not a good idea; what does that mean on
> an MSDOS machine talking to an MVS and Unix server?

My understanding about DCE1.1 (without posessing the functional spec
which you have) is that the legacy system support extension (RFC6) uses a
UUID to identity each extended registry attribute type. True?

It was suggested during the 01NOV93 AAC meeting that the LOCAL_UID be
qualified in an analagous way with the identity of the applicable system
so you know whether it applies to UNIX, MVS, or indeed DOS (not).



Piers


-------------------------------------------------------
P V McMahon                                     13NOV93
ICL Enterprises
post:  Kings House, 33 Kings Road, Reading, RG1 3PX, UK
email: [e-mail]
  OR   [e-mail]
phone: [phone] extension 3285
fax:   [phone]
-------------------------------------------------------