Extending SSH Authentication Protocol with RSA Secure ID
Introduction
SSH (Secure Shell) is a protocol used to remotely login to another computer over a network. It provides a very secure communication channel using strong authentication methods and proven encryption algorithms.
SSH can be used as a replacement for the traditional remote access programs such as telnet, rlogin, rsh, rcp and ftp which are highly insecure because of their fragile authentication methods and the unencrypted data exchange. For eg., most of these programs send passwords in clear-text format during authentication and exchange unencrypted data to the server, thus becoming easily vulnerable to eavesdropping and network attacks.
SSH specification allows you to add stronger authentication methods to the existing set of methods to provide a highly secure and reliable communication channel.
The purpose of this whitepaper is to explain how the RSA SecureID Authentication can be used to supplement the SSH Authentication protocol to enhance the system security by defining a set of SSH key exchange methods which use the RSA ACE/Server Authentication APIs to authenticate the SSH client using RSA SecureID.
SSH Authentication Protocol
The SSH protocol mainly consists of the following sub-protocols :
- SSH Transport Layer Protocol - This layer is a secure low level transport protocol which provides strong encryption, server authentication and integrity protection.
- SSH Authentication Protocol - This protocol authenticates the client to the server using a set of authentication methods such as password authentication, RSA public key authentication and host-based client authentication methods defined in the server.
- SSH Connection Protocol - This protocol provides the interactive login sessions, remote execution of commands, forwarded TCP/IP connections, and forwarded X11 connections multiplexed in a single encrypted tunnel.
The SSH Authentication protocol is used as a general-purpose user authentication protocol which is run on top of the SSH Transport Layer Protocol which provides the secure, encrypted and confidential communication tunnel to the Authentication layer.
The Authentication layer uses one or more of the following authentication methods to validate the user:
- Password Authentication
- RSA/DSA Public-Key Authentication
- Kerberos Authentication
- Host-based Client Authentication
When the SSH client connects to the server, the server sends client a series of authentication methods required to authenticate the client. The client must respond to them one by one to continue the session. These authentication methods are identified by a name.
All authentication requests uses the following packet format :
All the authentication requests uses the SSH_MSG_USERAUTH_REQUEST message identifier and should include the user name and the service name. The service name specifies the service to be started after the user is authenticated in the server. The method name specifies which authentication method is to be used for the authentication. For eg., "publickey", "password", "kerberos" and "hostbased".
The authentication process is started by the client by sending a packet with message id - SSH_MSG_USERAUTH_REQUEST and an authentication method name acceptable by the server. The server then validates the request and sends an SSH_MSG_USERAUTH_SUCCESS message if the authentication succeeds, else an SSH_MSG_USERAUTH_FAILURE message is sent.
The client sends additional authentication requests if the previous one succeeds by sending a new SSH_MSG_USERAUTH_REQUEST message.
If the server rejects an authentication request, it also sends a list of authentication method names with the SSH_MSG_USERAUTH_FAILURE packet, that can be used by the client to continue the authentication process.
All the message identifiers used by the SSH Authentication protocol are in the range 50 - 79. Out of these, 50 - 59 are used by generic user authentication messages and 60 - 79 are used by client specific user authentication methods.
The following are the generic message identifiers used by the Authentication protocol:
RSA SecureID Authentication
RSA SecureID is a solution for strong user authentication built on a method called "two-factor authentication" using the RSA ACE/Server authentication engine.
The normal password authentication methods provides a low proof of authenticity, since anyone who steals the passwords can also get into the secure systems. The SecureID solutions adds a second level of authentication in addition to a predefined PIN. A user is required to provide an additional passcode which is dynamically generated during authentication which makes it hard to break into SecureID systems.
The SecureID system issues individually registered devices to authorized employees, that generate single-use passcodes (tokens), which change based on a timecode algorithm. A new tokencode is generated every 60 seconds and the RSA ACE/Server authentication engine validates these changing tokencodes. A user is required to provide this dynamic tokencode in combination with a predefined PIN assigned to him during authentication.
The RSA ACE/Server is used to issue authenticators (token generator devices) to individuals, setup security policies and create logs of user accesses to the network resources managed by the system.
In addition, RSA Security provides device specific software agents called "RSA Ace/Agents", to enable strong authentication in network resources and webservers.
The RSA Security system also provides the RSA ACE/Server Application Programming Interface that allows developers to integrate RSA SecureID Authentication into their applications.
Adding RSA SecureID Authentication in SSH
The SSH Authentication protocol is a general-purpose user authentication protocol and uses some predefined authentication methods such as password, public-key, kerberos and host-based client authentication to authenticate a client to the server.
This section describes how to add a new authentication method to the existing set of methods in SSH Authentication protocol to authenticate using RSA SecureID. We will name the new authentication method as "secure-id".
Message Exchange in an SSH Authentication session
Before explaining how to add the new method for RSA SecureID validation, let us take a look at how the protocol exchange happens between an SSH client and an SSH server during a simple authentication session which uses the public-key authentication ("publickey") and password authentication ("password") methods for validation.
Listing 4.1:Message sequence for a simple SSH authentication session.
Client Request 1
Server Response 1
Client Request 2
Now the client sends a new authentication request to the server for password authentication by providing the user name and the plaintext password. (Client Request 3)
Server Response 2
Client Request 3
Server Response 3
The client initiates the authentication process by sending a user authentication request for the public-key authentication method (method name: "publickey"). It also sends the user name, public key algorithm name and the public key itself in the packet to the server. (Client Request 1)
If the SSH server supports the specified public key algorithm, it responds with an SSH_MSG_USERAUTH_PK_OK message. (Server Response 1)
The client then sends another request as a part of the public-key authentication which contains a signature created using the private-key of the client. (Client Request 2)
The server checks the validity of the signature created using the private-key of the client. If it is valid and there are no more authentication methods to follow, it sends an SSH_MSG_USERAUTH_SUCCESS message to the client. If the signature is validated and there are more authentications required by the server, it sends an SSH_MSG_USERAUTH_FAILURE message back to the client along with the authentication method names to be used to continue the authentication process. In the above listing, the server sends an SSH_MSG_USERAUTH_FAILURE message along with the password authentication method name - "password" to be used for the next authentication. (Server Response 2)
Now the client sends a new authentication request to the server for password authentication by providing the user name and the plaintext password. (Client Request 3)
The server authenticates the user name and password from the client request and sends an SSH_MSG_USERAUTH_SUCCESS message back to the client if the authentication succeeds. (Server Response 3)
These steps authenticates the client to the server using the public-key and password authentication methods.
Messsage Exchange for SecureID Authentication
Now, our task is to add the new authentication method ("secure-id") to the above sequence of messages in Listing 4.1. Both the SSH client and the server has to be modified to support the new method.
The following listing shows how the messages are exchanged between the client and the server during the secure-id authentication.
Listing 4.2: Message sequence for the new secure-id authentication method.
Client Request 3 (from the Listing 4.1)
Client Request 4
Client Request 5
Server Response 5
The server is modified to send an SSH_MSG_USERAUTH_FAILURE message to the client after the password authentication method ("password") succeeds, to continue with the secure-id authentication. (Server Response 3)
The client prompts the user to enter the PIN + SecureID combination and sends it to the server in a new authentication request using the authentication method name - "secure-id". (Client Request 4)
The server validates the secure id using the RSA ACE/Server API. The server may respond with the following messages depending on the validation:
- SSH_MSG_USERAUTH_SUCCESS, if the secure id is valid.
- SSH_MSG_USERAUTH_FAILURE, if the secure id is invalid or the authentication process should continue with another authentication method.
- SSH_MSG_USERAUTH_SECUREID_NEXTTOKEN_REQUIRED, if it requires the next token from the authenticator device in order to complete the secure authentication.
In the above listing, we assume that the server asks for the next secure id token to complete the authentication by sending a message with message identifier - SSH_MSG_USERAUTH_SECUREID_NEXTTOKEN_REQUIRED. (Server Response 4)
The client then prompts the user to enter the next secure id token and sends a new authentication request as part of the secure-id authentication which contains the next token. (Client Request 5)
The server validates the next token using the RSA ACE/Server API and responds with an SSH_MSG_USERAUTH_SUCCESS message if the authentication succeeds. (Server Response 5)
In the above listing, we defined a new key exchange method - "secure-id" for authenticating the user with RSA SecureId and a new message identifier used by the SSH server to request the next secure-id token from the client.
Listing 4.3: New message definitions for SecureID Authentication.
new secure-id authentication method name : "secure-id"
Authenticating the SecureID using RSA ACE/Server APIs
The RSA ACE/Server Application Programming Interface allows developers to integrate SecureID user authentication into custom applications.
In Windows, the SecureID authentication APIs are installed as a dynamic link library named "aceclnt.dll" and as a library archive named "libaceclnt.a" in Unix.
The following code shows how to validate the SecureID using these APIs :
Listing 4.3: Code for verifying SecureID using RSA ACE/Server API
The above code can be used to create a simple console based application which authenticates a user using RSA SecureID.
The creadcfg() function call (Line 11) is used to load the ACE Server configuration file (sdconf.rec) into memory. This function should be called first before calling any other function in the API. This function assumes that the configuration file is in the path specified by the environment variable "VAR_ACE".
The sd_init() function call (Line 14) initializes the socket and makes a call to the ACE Server to verify the communication. This function should be called after a successful call to the creadcfg() function and before calling any other function.
The sd_check() function call (Line 17) is made next to check the validity of the secure-id given by the user. This function returns ACM_OK if the validation is successful, ACM_ACCESS_DENIED if the secure-id authentication fails and ACM_NEXT_CODE_REQUIRED if a next tokencode is required to complete the authentication. This function should be called only after the successful completion of the sd_init() method.
The sd_next() function call (Line 27) is used to validate the next secure-id tokencode if it is required to complete the authentication. This function should be called only in response to the ACM_NEXT_CODE_REQUIRED return from sd_check(). This function returns ACM_OK if the next token code is validated successfully and returns ACM_ACCESS_DENIED if the authentication fails.
Finally, sd_close() call is used to close the socket opened by sd_init(). This function should be called after attempting to authenticate the user, regardless of whether or not the authentication was successful.
Summary
This paper provides an overview of the SSH Authentication protocol used for validating a client to the SSH server. It also explains the basic concepts of RSA SecureID authentication and describes how to extend the SSH Authentication protocol to support the authentication using RSA SecureID. The code fragment in the Listing 4.3 show how you can validate a secure-id token using the RSA ACE/Server APIs.
There are also some proposals for adding a generic authentication protocol to the SSH protocol. The internet draft - "Generic Message Exchange Authentication for SSH" by Cusack, F., and Forssen, M. (see the references section) describes a general purpose authentication method for the SSH protocol, suitable for interactive authentication sessions. The major goal of this method is to allow the SSH client to support a set of new authentication methods without knowing about the specifics of the actual authentication implementations. With this generic authentication protocol, the clients will not be required to change their code to support new authentication methods.
Addendum
There are two versions of SSH - SSH1 and SSH2, which operate almost in the same manner, although there are some differences in their configurations and the way the message exchange happens. SSH1 and SSH2 have different message formats and they encrypt at different parts of the packets. SSH1 uses server and host keys to authenticate systems where SSH2 only uses host keys. SSH2 is a complete rewrite of the SSH1 protocol, with improvements to security, performance and portability.
References