Re: 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:

He has not.

I continue to be very disappointed in the way the IETF security WG's
operate in that it is impossible for someone to contribute without
attending the meetings in person.  This is a shame.

I cannot respond in detail to Pier's points because I am still confused.
As I said in my first message:
> > 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?

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

I disagree that my use of the "rights" is constricted or unusual.  My
intent is to put things into the simplest possible terms:  a client presents
a list of "things" which say "I am John.  Bob also says I'm his cousin."
He presents this list (which is his identity) with his request "I want to
read the 'foo' database" to the server.  The server decides whether or
not John can read 'foo' and takes the appropriate action.

As I read the document, the client says "I am John.  Bob says I can read
'foo'.  I want to read 'foo'".  Is that right?  If not, what is a right?
My model says a client merely has an identity, and the server decides if
the client has the correct rights to perform the requested operation.

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

I think proxy is a bad term.  When I send a print /tmp/foo request to the
printer, then the printer system will be acting as my proxy when, later,
it asks the filesystem for the contents of that file.

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

I'm not sure what you mean by "extended registry attribute type."  An
extended attribute, e.g., MVS login information, is identified by a
uuid.  The type and value of that data is separate from the attribute;
the uuid is basically the name so that attributes are really name/type/value
triplets.

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

So I get something like
	<tag-indicating-unix-uid, 93>
	<tag-indicating-mvs-acct ied3321:cteowd>
	<tag-indicating-multics-acct rsalz.tech.guest>
?

Does it really help to know "1440" without, say, qualifying it by
sulphur.osf.org?
	/r$