Dmitry Yemanov wrote:

> "Alex Peshkov" <pes@...> wrote:
>
>>Fbclient detects that it has no login/password in DPB. Any remote server
>>will currently disable user's login in this case. Therefore such state
>>of DPB is a reason to try trusted authentication.
>
>
> This may also mean that the user intended to use ISC_USER/ISC_PASSWORD, but
> forgot to set them up. Alternatively, imagine a user which wants to use
> trusted authentication, but somebody else has set up the envvars and hence
> the connection will be done using the security database authentication.
> Wouldn't it be better to allow the user to explicitly specify that he wants
> a trusted authentication (via isc_dpb_trusted_auth)? I'd vote for that.
>

All cases you have described are something not very real. Certainly,
user may forget everything - for example, forget to connect to the
server at all:-). But getting serious - what to do, if all of
ISC_USER/ISC_PASSWORD/isc_dpb_trusted_auth are present in DPB?
Next, it will require modification of all and any client program to be
able to use trusted connections. It's pretty easy to add such switches
to isql, qli and gsec, but what to do with a lot of other programs?
Certainly, this is very small change, but, for example, you will have to
wait for next version of IbExpert (and any other third-party software)
to be able to use trusted connections. Migration appears problematic
sometimes.

>
>>Client creates
>>authentication object (AuthSspi) and gets data from it to send to the
>>server. That data is added to the DPB (I've added isc_dpb_trusted_auth
>>tag). Server receives such DPB and the first thing it does when finds
>>isc_dpb_trusted_auth - removes it from dpb and sends to server's
>>AuthSspi object to validate credentials. At this moment server needs to
>>send some data to the client and get an answer to this question. To
>>implement such data exchange I had to add new packet type
>>(op_trusted_auth) with single field - authentication data.
>
>
> AFAIU, any new packet type should mean a protocol version bump.
>

Certainly in the general case. And when we will implement full schema
with plugins - this is required step. But in the short run it's pretty
possible to live without it.

>>1. It doesn't break remote protocol in any way - exchange with packets
>>of new format begin in that and only that case, when both client and
>>server understand what is trusted authentication.
>
>
> What if the older cliend sends isc_dpb_trusted_auth (e.g. I specify it in
> DPB manually)? The server will start negotiation with the code which is not
> ready to process op_trusted_auth packets.

Yes, it's possible to add it manually. But it's not enough to make
server start negotiation. You must send actual data in DPB, because
before sending op_trusted_auth packet server validates them. And any
wrong bit (in a chain of about 100 bytes) makes negotiation impossible.
Certainly, as soon as you do 2 or 3 WinAPI calls (each with about 10
parameters, some of them pointers to structures, containing pointers to
another structures - all in the best traditions of MS) you can easily
send real data in DPB. But if you've learned to do all this - will you
still use old fbclient? And even if you have done all this - client
should fail with protocol error and disconnect port. Nothing criminal.

> So I think that it should be done
> using a new protocol version with the appropriate protection code.
> isc_dpb_trusted_auth should be ignored if both the server and the client
> don't agree on a protocol version which supports op_trusted_auth.
>

Let's distinguish between long and short terms.

In long terms we plan to have different trusted authentication plugins,
is not it so? At least one more with fixed private/public key's pairs
should obviously exist. As soon as we give people public interface for
writing plugins, they may write own plugins. But if we want to avoid
client-side configuration, new protocol version becomes really required
step to let server send list of possible methods during firts handshake.
Moreover, format of data should be changed - if server suggests not only
single way to perform trusted authentication, client must let it know,
what way it selects.

In the short terms (as long as we use experimental branch with NTLM only
authentication) I don't see real need in it. Let's not make things more
complex then we really need.
The only thing I should do is to sync with vulcan - I suppose Jim might
add new op's for new API calls. It will also be good idea to learn fb2
behave correctly in case of receiving such packets from vulcan client.

And if we want to have real protection in protocol - what about
Interbase and borland? The may add new kinds of packets too. We have
good protection in ODS, but protocol seems to be unprotected. Correct me
if I'm wrong.

>
>>What main problem I see - if we decide to have plugins for trusted
>>authentication (now everything is inside client/server code, which is OK
>>for experimental version), we will have 2 places in firebird for
>>authentication plugins. One in fb_authenticate_user() and another in
>>remote subsystem.
>
>
> This doesn't look good, but I don't see a better solution either.
>

It's possible to pass status_vector from fb_authenticate_user() with
special meaning - trusted authentication iteration needed. Moreover,
it's possible to pass trusted authentication data as counted string in
that buffer. And if we find a way to save authentication object between
iterations, this will work. But I'm afraid this is even worse then two
kinds of plugins.