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