Re: Authentication, security requirements

Jim Whitehead wrote:
> 
> [...]
> 
> Authentication.  It should be possible to guarantee that a given HTTP
> message comes from a particular person.

"person" is probably too, ah, personal. Some term that embodies the
notion of an automated process (eg., "drone", aka "manager". No, no!
Don't use that one! :-) would probably be more accurate. Servers need to
be authenticated too, and having them masquerade as a "person" is a bit
contrived.

> 
> When writing a document, it is necessary to check that the person writing
> the document has write permission.  In most access control schemes, this
> involves taking the name of the person and performing a lookup in an access
> control table or determining membership in an access control list.
> Checking access control permissions requires knowledge that the person
> requesting the action is, in fact, who they say they are.  Similar problems
> result when performing a checkout, a checkin, or taking out a lock, which
> require checking for permission to perform the operation, and storing the
> name of the person who requested the operation.
> 
> The HTTP/1.1 protocol, in section 11, "Access Authentication," provides a
> framework which can be used by many different authentication schemes.
> 
> Secure transmission.  It should be possible to write either a full or
> partial resource so there is a reasonable guarantee the contents will be
> private during transit.
> 
> Transmitting a resource over the network in its native format opens up the
> possibility that a third party could snoop network packets and recreate the
> contents of the resource.  This is clearly undesirable in a wide variety of
> contexts.  There is a need to ensure that people using remote authoring can
> do so with reasonable confidence they are not compromising their
> information.
> 
> ** Is this capability provided by SSL?
> 

There are (at least) three areas of concern (as enumerated above):
Authentication, authorization and privacy.

SSL's current strengths are authentication and privacy during
transmission.

The authentication phase is done (as *everone* knows) with certificates.
Certificates do have fields that uniquely identify the holder of the
certificate, but that identity does not readily map to an identity that
is acceptable by popular operating environments. Using HTTP's Access
Authentication to establish authorization is doable, but one must be
careful about the association between the identity established using a
certificate and the identity being presented in the HTTP protocol.

There is an effort in progress within in SSL/TSL world to add "attribute
certificates" to address the fine grain access control issues. The
schedule for availability of that feature may make it inappropriate for
this forum, though we (Netscape and I) believe that it is the right
strategic solution.

AO
-- 
Alan O. Freier		Corporate Cynic
<freier@netscape.com>	(415) 937-3638 (work)

Received on Wednesday, 25 September 1996 13:29:41 UTC