IPP> SEC - Access Control: What's On The Wire

IPP> SEC - Access Control: What's On The Wire

IPP> SEC - Access Control: What's On The Wire

Carl-Uno Manros cmanros at cp10.es.xerox.com
Tue Jun 3 12:32:14 EDT 1997


Hi,


I am forwarding this contribution from the WEBDAV group which apparently is
struggling with some of the same security problems that we are.


Carl-Uno


>
>This might just be a more direct way of saying what you are saying.
>
>I think you will find that the only way to specify that credentials should
be sent without restricting the implementation to any particular method
(X.509, kerberos...) is to define a "credential cookie" which the client
sends to the server.
>
>Determining which form of credential to send (assuming the client has a
choice) would require the client and/or the server to send a list of the
supported credential "formats" in order of preference the one being used
being the highest commonly supported format (credential handshake).
>
>This implies that the minimum that this WG is going to have to do is
>
>1)  Decide which schemes we regard as candidates for credentials
>2)  Determine the extension to HTTP for the credential handshaking
explicitly naming the identified credential schemes and such that it can be
extended to support other schemes (similar to the MIME-type names)
>3)  Determine the extension to HTTP for the credential cookie transfer
>
>Cheers
>Dylan
>
>----------
>From:  Fisher Mark[SMTP:FisherM at exch1.indy.tce.com]
>Sent:  Mittwoch, 28. Mai 1997 22:39
>To:  'w3c-dist-auth'
>Subject:  Access Control: What's On The Wire
>
>The big question to me in WebDAV access control is, "What should go over
>the wire?".  I see 3 things that go from the client to server:
>	1) An HTTP method;
>	2) Credentials identifying the client; and
>	3) One (or more) URIs identifying the resource.
>The server then responds with a status code, along with a Reason-Phrase.
>
>Now, credentials can be several things.  The simplest non-null case is a
>single ID.  If you are in a relatively high-trust situation (like inside
>a company Intranet), merely tracking the author by ID may be sufficient.
> Or, for somewhat greater security, a one-time ID (like a SecurID
>without the PIN), may be adequate in some cases.  UserID/passwords are
>quite commonly used in multiuser OSes, while X509 certificates and
>signed PGP messages both have their advocates.  What goes over the wire
>from the client to server, however, are HTTP-method + credentials +
>URI(s).
>
>Since WebDAV is an extension for HTTP, any credential-sending mechanism
>(authentication method) considered by this group should be via HTTP.
>This is not to preclude other authentication methods (CORBA, Kerberos,
>etc.) being used, it is just to say that non-HTTP methods are likely out
>of this group's scope.  This is also not to say that adding
>authentication mechanisms to HTTP should not be considered, as work done
>on additional authentication mechanisms would benefit Web users as a
>whole.
>
>To make a long story short (too late! :( ), what WebDAV access control
>needs to be concerned with are the HTTP authentication methods to
>support, the HTTP methods needed for WebDAV, and the HTTP status
>responses.  Although there will be clients and servers that use DCE,
>NTLM/CIFS, etc. for access control, since they are not using HTTP, IMHO
>we should not be spending our time on this mailing list considering
>these options.
>==========================================================
>Mark Leighton Fisher          Thomson Consumer Electronics
>fisherm at indy.tce.com          Indianapolis, IN
>"ViaCrypt?  Vhy not!"
>
>
>
>
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros at cp10.es.xerox.com



More information about the Ipp mailing list