/ elib / distrib / vattp

SSL & VatTP

Last updated: [1998/05/21 Bill Frantz]

Author(s): Bill Frantz (frantz-at-pwpconsult.com).

The E Comm system

The E Comm system currently supports one cypher suite. It is most similar to SSL's ID_SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA, which uses Diffie Hellman (DH) key agreement to provide perfect forward security, the Digital Signature Standard (DSS) to authenticate the connection, triple Data Encryption Standard encryption operating in CBC mode (3DES_EDE_CBC) for data privacy, and SHA for data authentication.

Most of the cypher suites in SSL do not provide perfect forward security. This valuable property causes the session key which protects a communication session to be discarded after the connection is closed. The user can not be coerced into revealing it because all forms, encrypted or not, have been discarded. The ID_SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA suite has this property, but most SSL implementations do not support it. (It does not appear that the Baltimore or Phaos commercial Java implementations support this mode yet. See Commercial Java SSL packages.)

Issues:

X.509 vs. Key Centric Identity

SSL supports the heiarchial X.509 view of identity. In this view, every identity has a globally unique name, the "Distinguished Name", and there exists a heiarchy of Certificate Authorities (CAs) which bind those names to the public/private key pairs used for authentication.

The E Comm system uses a very different model of identity. In this model you are identified by your public key. You are authenticated by demonstrating that you know the private key associated with that public key. There are no certificate authorities or certificates.

To use SSL, we would have to package our keys as certificates. The Baltimore support would allow us to override the acceptCertificate method of SSL<client/server>Support to examine the key presented and accept it. However, this override would not be compatible with the SSL specification.

Another hack which is probably "legal" SSL is as follows: Our application is set up to accept a key pair "cert" as the top level CA. We distribute both the public and private keys to that CA as part of the application. When a vat goes to create an identity, it creates a certificate which associates the RegistrarID (the hash of the public key) as the X.509 destinguished name with the new public key for the identity. When it builds a SSL connection, it passes that certificate to the other end. We will need to add certificate checking that ensures that the distinguished name is indeed the hash of the public key, but I suspect all implementations will have an exit for that kind of checking. (The Baltimore implementation does.)

RSA vs. DSS.

SSL was developed when RSA was the only digital signature scheme with any degree of acceptance. Since then, DSS has received a degree of acceptance. RSA is a patented algorthm, with "mad dog" patent lawyers defending it. DSS is available for use without patent problems. That is why we use DSS in the E comm system. My understanding from talking with Tim Oren is that RSA licenses are only available on a "unit sold" basis, and are not available for generating certificates (so Verisign can maintain its monolopy).

Client Server vs. Peer to Peer

SLL is designed for Client/Server communications. The E Comm system is designed for peer to peer communications. In the SSL model, the client always builds connections to the server. In our model, either end can build the connection, and we have to handle the case where both decide to do it at about the same time. SSL has no such support. If we try to use it for our style of communications, we would have to deal with this problem.

Support for PLS.

A SSL client always knows where to contact his server. It is port 443 on host foo.bar.com. The domain name foo.bar.com allows runtime lookup of the IP address for the server. There is no way to dynamically look up the port number.

The E comm system supports a way of dynamically finding not only the IP address, but also the port number on which the other E system is listening. This is the Process Location Server (PLS), a service which is not available with SSL.

The advantage of dynamically looking up the port number is that an instance of the E comm system can be installed without need for administrative intervention. It also allows more than one E comm system to run on a single computer.

The principle disadvantage is that it makes it harder to punch a hole through a firewall for E communications.

If we were to go to a fixed port number, we would need to get a assigned port number from the Internet Assigned Name Authority. We would still need some kind of PLS like lookup service for users who are dynamically assigned IP addresses and domain names by their ISPs. (The PLS currently has a fixed port assignment.)

Commercial Java SSL implementation

There is a Java SSL implementation available from Phaos Technology in New York. Their API is available with their evaluation package.

The Cryptix group is working on a Java SSL package. They have not released anything yet.

Baltimore Technologies SSL is an example of a commercial Java SSL package. It defines two major classes: SSLServerSocket and SSLSocket, for servers and clients respectivly.

SSLServerSocket (Client sockets are quite similar)

The constructors take a port number, maximum number of unaccepted connections, and a SSLSupportFactory which defines the SLL support.

There are two methods: accept and toString. accept returns s newly-created, non-authenticated SSLSocket connection to a remote host. Calling any of the accessors on the returned socket, such as getInputStream() or getOutputStream() will initiate the authentication handshake.

The SSLSupportFactory provided determines all the SSL parameters. They provide an implementation which only supports RSA for authentication