Data Protection and Security

VII

Identification and Entity Authentication

VII.III

Authentication Protocols

SSH (Secure Shell):

In some cases, only one of the parties in the conversation has a public key/private key pair. In SSH for instance, it is assumed that the servers have public keys and clients might not have. Servers are authenticated by default using public key cryptography and after the session key is established the client is authentication using the encrypted channel.

The protocol works as follows:

1. The client (C) opens a connection to the server.
2. The server (S) sends its public RSA host key and server key.
3. C encrypts the random number (session key) with S’s both keys.
4. S decrypts session key, sends an encrypted confirmation to C.
5. C is authenticated to S (in a number of ways, see below).
6. Both sides can send packets asynchronously.

The client authentication in SSH can be:

• Traditional password authentication
• Pure RSA authentication
• RSA + .address-based (using rhosts or hosts.equiv) authentication
• Adding new methods is easy.

In SSH, even when a PKI is established (will be discussed in the next chapter) and it is possible to securely bind public keys both with servers and clients, there is a limitation in using public key cryptography in client authentication. This problem is that since private keys are long enough to prevent users to type it while authenticating themselves, it is a general practice to store private keys on client’s machine after they are encrypted with the user’s password. Only if correct password is entered, the private key is decrypted correctly and the authentication takes place. This is a shortcoming of SSH because we again end up with the problems associated with passwords (low entropy, dictionary attacks, etc.)