RE: Access Control Draft

Phill, you wrote:
>Please rememebr that security can be a serious rat hole, particularly 
>if questions such as access control are to be discussed. to discuss
>security seriously I would like to see someone such as Jeff Schiller,
>Butler Lampson, Ron Rivest or Taher ElGamal involved. I would urge
>the group to look to other working groups such as SPKI to solve this
>aspect of the problem.
Personally, I think it would be great if one of the aforementioned
security gurus joined our discussions.  Although I do a lot of
security-related work here at TCE, it is these gentlepeople and others
like them to whom I look for guidance on my work.  It would also be good
if Jeff and/or Tom Weinstein from Netscape (and their counterparts at
Microsoft (Bob Atkinson among others)) would join in the discussion.

There are (in my mental model) 4 basic components to computer security:

1) Authentication -- are you who you say you are?
2) Access Control -- are you allowed to perform this operation in this
way?
3) Auditing -- just what was it that you did?
4) Encryption -- Is your data protected from prying eyes?

As our group is mainly concerned with the HTTP protocol, (3) may be out
of scope (as this is a server-side issue), unless there is a good reason
to have user agents examining their audit trails.  As for (4), there are
mechanisms in place (SSL, PCT) to protect the data as it goes over the
wire.  If the data is to be decrypted after it has been dumped into an
object (file, memory buffer, etc.) on the receiving machine, this is
likely out of scope for this group.  That leaves (1) Authentication, and
(2) Access Control, as the topics I think (IMHO) we need to concern
ourselves with.

>I would not particularly recommend the API approach. I have serious
>doubts about GSAPI, particularly since it does not solve the problem
>it was intended to (export) and I have never quite been able to wring
>a coherent explanation of objectives, purpose or mechanism from 
>the specs. I get the same feeling that I get when reading the 
>Windows NT operating system manuals, mechanism without explanation
>of stategy or architecture.
The API approach ties us too tightly to a particular architecture or
architectures.  What our concern (again, IMHO) is the actual protocol
changes needed to support WebDAV.  Whether we have a JavaStation
user-agent talking to a Cray proxy server talking to a 6800 embedded
HTTP server for the MIT Coke(tm) machine (updating a translation of the
directions into Hindu) should not matter.  What matters is that all
machines agree on the extended HTTP protocol for performing WebDAV
operations.


Maybe the problems with Windows NT stem from their having a "stategy"
when they should have a "strategy", instead... :)  (MLF, a long-time
Windows NT user who thinks that in Windows NT, Microsoft (perhaps
inadvertently) created a real operating system, but who thinks they need
to slow down their pace of development to the point that they can
consistently address security issues.)
==========================================================
Mark Leighton Fisher          Thomson Consumer Electronics
fisherm@indy.tce.com          Indianapolis, IN
"ViaCrypt?  Vhy not!"

Received on Friday, 16 May 1997 10:53:07 UTC