Subject | Re: [Firebird-Architect] Crypto Extentions to Remote Protocol |
---|---|
Author | Mark O'Donohue |
Post date | 2004-10-26T23:38:09Z |
Hi Jim
Jim Starkey wrote:
code and how to establish callbacks from server -> client.
If changing the wire protocol, it would be nice to have the ability for
establishing a connection to be able to loop through client -> server
auth/session establishment messages until the process is complete.
This would enable a more comprehensive exchange of keys, and also enable
some good client authentication methods.
This could be done by either:
A) doing auth/session processing prior to calling isc_attach:
client -> server [isc_auth...] repeated until complete.
then:
client -> server [isc_attach]
or
B) doing auth/session processing after calling isc_attach.
client -> server [isc_attach] // attached but unauthenticated for
// protcol_version2.
then:
client -> server [isc_auth...] repeated until complete.
With option A) possibly this auth/session establishement could be a
variation of isc_attach_service that results in a database isc_attach.
Cheers
Mark
Im glad to see the discission, and I have some more comments on Jim
method but that will have to wait until Friday when I have time.
Jim Starkey wrote:
> I'm posting this proposal to both the devel and architecture listsAfter our previous discussion, I did have a bit of a look at the source
> because of general interest, but I would like to restrict discussion to
> only the architecture list.
>
code and how to establish callbacks from server -> client.
If changing the wire protocol, it would be nice to have the ability for
establishing a connection to be able to loop through client -> server
auth/session establishment messages until the process is complete.
This would enable a more comprehensive exchange of keys, and also enable
some good client authentication methods.
This could be done by either:
A) doing auth/session processing prior to calling isc_attach:
client -> server [isc_auth...] repeated until complete.
then:
client -> server [isc_attach]
or
B) doing auth/session processing after calling isc_attach.
client -> server [isc_attach] // attached but unauthenticated for
// protcol_version2.
then:
client -> server [isc_auth...] repeated until complete.
With option A) possibly this auth/session establishement could be a
variation of isc_attach_service that results in a database isc_attach.
Cheers
Mark
Im glad to see the discission, and I have some more comments on Jim
method but that will have to wait until Friday when I have time.