Oleg:
Hello!
Sorry to have been vague in my last email. I have few new
thoughts regarding the nature of the "steel tube" between two
Kaboodle users. As you know well, we need to ensure support of
low-latency "intensive bilateral data streams" as well as support
for ad-hoc application-specific channelization. That's a lot of
processing done before and after the encryption engine even gets
involved.
As you also know, I've also suggested the SSH protocol
was close to what I thought would be suitable. The spec for SSH
on www.OpenSSH.org describes the protocol as having 3 pieces:
1. The transport layer provides algorithm negotiation and a key
exchange. The key exchange includes server authentication and
results in a cryptographically secured connection: it provides
integrity, confidentiality and optional compression.
2. The user authentication layer uses the established connection
and relies on the services provided by the transport layer. It
provides several mechanisms for user authentication.
3. The connection layer multiplexes many different concurrent
channels over the authenticated connection and allows tunneling
of login sessions and TCP-forwarding. It provides a flow control
service for these channels. Additionally, various channel-specific
options can be negotiated.
We've not changed how Kaboodle currently handles it's
transport layer very much since we started. And you've made a lot
a progress in how Kaboodle handles in connection layer, especially
all the socket interactions (with a big remaining hurdle being the
combining of all data into a single "steel tube" --if we could
accomplish this in the short term without adopting a whole new
protocol such as SSH, we'd have a releasable piece of software).
What I've been worrying about most is the design of how
Kaboodle handles the user-authentication methods. The existing
partnership authentication and session-key exchange is pretty well
described in thee spec. The shortcoming which I see in the this piece
is that, right now, a partnership cannot be created "in privacy".
That is, every partnership file is recorded in some manner in our
database server.
So, Kaboodle should have a means by which two users could
create and essentially "self-sign" a partnership certificate. This
could be known as a "private partnership" mode. The web-based database
server will continue to handle the other mode, a "verified partnership"
mode in which the server's private key is used to sign the partnership
files it helps create.
Of course, the coding required to implement these two modes
is done in the user-authentication layer, which should have little to
do with the nature of the "steel tube" between two Kaboodle users.
I've only started specifying how these two partnership modes should
act and interact with the user, and will be adding those sections
into the software spec.
Please let me know if details of those interactions affects
your "steel tube" design decisions and scheduling and I'll finish
up the work sooner rather than later.
-Scott
PS: Happy New Year!
_______________________________________________
Kaboodle-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kaboodle-devel
