From: edguer@ces.cwru.edu (Aydin Edguer)
Newsgroups: comp.infosystems.wais
Subject: Re: Missing Piece In WAIS Protocol?
Date: 2 Oct 1992 01:34:57 GMT
Organization: Computer Engineering and Science, Case Western Reserve University
NNTP-Posting-Host: sentinel.ces.cwru.edu

In article <Bv5Mq6.4M5@sti.com> westes@sti.com (Will Estes) writes:
>In article <192ifhINNf7i@usenet.INS.CWRU.Edu> edguer@ces.cwru.edu (Aydin Edguer) writes:
>>In article <BuE4AL.9y7@sti.com> westes@sti.com (Will Estes) writes:
>>In order to achieve user access control, you have to have cooperating
>>server and client software that performs some sort of authentication
>>protocol.  
>
>I think you are confused about the difference between authentication and
>user access control.

Hardly.  You cannot have user access control without authentication.
If you cannot tell who a person is you cannot say what they are allowed
to have access to!

>Authentication asks the question: is this client or server what it
>claims to be?  In other words, it gives a client a way to verify that
>you really are edguer@ces.cwru.edu (or some network-wide kerberos
>userid) and not someone who is putting out faked packets and claiming to 
>be you.
>
>User access control - as I am defining it - asks an entirely different
>question: what documents is edguer@ces.cwru.edu allowed to see?  There
>are some off-hand references to user access control in some of the WAIS
>documents that I have seen, and WAIS may mean something else by user
>access control.  By the way, if someone here knows what Z39.50 means by
>"user access control," I would appreciate being educated. 

Have you read the text of z3950-spec.txt available from think.com?
[note: this is the version 2 document]

As it states is section 3.2.1.1.1, a z39.50 server (target) can determine
whether the client (origin) is allowed to access a database using the
Id/authentication option.

Section 3.2.1.1.2 goes into this further:

        Security is invoked at different levels. In addition to user
    authentication at the outset of an association, security might be
    invoked to control access to a particular database, record,
    result-set, or use of a command.

        If the origin is not capable of receiving an Access-control request,
    and if security requirements on the target system mandate that security
    (other than that which might be provided by the parameter
    ID/authentication) be invoked at the outset of an association, then the
    target should reject the association by setting the parameter Result to
    "reject", and specifying "will use" for "access-control".  However, if the
    target invokes security, but not at the association level, then the target
    may choose to accept the connection.  In that case, if the target
    subsequently receives a command that would trigger an Access-control
    request, the target agrees to suppress the request and respond to the
    command with an error status indicating that a security challenge was
    required but could not be issued.

Does WAIS implement all these things?  Not at this time.

>To implement user access control, you do not necessarily need
>cooperating clients and servers.  In theory, all the user access
>control can, and should, reside on the server.  If you put such security
>on the client, you allow for the possibility of a hacker modifying
>object code to circumvent the security logic.  That's equivalent to no
>security at all.   

NO!!! How can you have user access control only on the server?  The server
has to be able to talk with the client to authenticate the client.  The
client has to understand the authentication request or else you have 
"no security at all".

Thus to access the server your client would need to supply id information.
If the id information was wrong then the request would be denied and the
client could not find out what information is available.

You have to have cooperating clients and servers - how else will you
use challenge-response or any other security that PREVENTS cracker
break-ins?

>>Depending upon security through obscurity [not listing the
>>database in the table of contents] is ludicrous.
>
>I think you are really confused about what I am trying to say.  The
>dual issues of how easy a WAIS client is to use, and how easy it is to
>navigate Internet WAIS servers, have nothing to do with the choice of an
>underlying protocol that allows the client to query a server about what
>databases it offers.
>
>If there were some protocol in place that allowed a client to request a
>list of databases from a server, it would be possible to design a client
>that is no more difficult to use, and no less useful, than any existing
>WAIS client.  The only difference would be that such a protocol would
>allow for the *possibility* of a secure server, and only where such
>security was needed.

I think I understand what you are saying, I just don't see how what you
are saying makes sense.  How is this different from having a directory
of sources that authenticates you and only returns the list of sources
that you are allowed to access?  Then each server from the list you
access will also authenticate you before allowing you access.  Why do 
you need some special protocol to request what other databases a server
has?

Aydin Edguer