Secure remote Password protocol

Testing the Secure Remote Password protocol

c m i c

Secure Remote Password

Why a secure password ?
How does it work.
Installation
Testing
The Windows client.
Drawbacks.

Why a secure password ?

In a LAN, some machines need a special security treatment: they might be servers, firewalls or routers. For these machines, not only the data they contain is important, but also their access. As Internet is now available on everyone's desk, the probability that a user get a LAN sniffer for free and than use it on the LAN is now very high. So you need to have your passwords crypted on the LAN. There are some proprietary solutions, and then the Secure Remote Password (SRP) protocol from Stanford University, which is free. You can install it on any Un*x machine and even on Windows platforms. Another important advantage of SRP is that there is no unexportable cryptographic algorithm (RSA for example) involved. Thus SRP is freely exportable and usable.

How does it work.

As a human, you must be identified by a computer. There are 3 categories of human authentication:

Something the human is (voiceprint, fingerprint, retinal scanner, ...),

Something the user has (ID card, smartcard),

Something a user knows (passwords, PINs).

SRP deals with the last category, also known as direct password, based on Asymetric Key Exchange (AKE). Suppose Carol want to be authenticated by a server:

Carol sends the server her username C and an public ephemeral key A, calculated with a generator and a private ephemeral key a.

The server looks up Carol password entry, fetches her password verifier v and her salt s in a password table. The server calculates his public ephemeral key B and sends it to Carol with s.

Carol computes a long-term private key x based on her password and the salt s; She also computes a value S based on the server public ephemeral key B, her long-term private key x and her private ephemeral key a. Carol sends the server a hashed form of S, M1.

The server calculates his S value with Carol public ephemeral key A, the verifier part v and the server private ehemeral key b. He verifies S against M1. He now knows that Carol is really who she pretends to be. Using his own calculated value of S, he hashed it into M2 and send it to Carol. Carol can verifies that the server is really the server who knows her password.

The whole process ensures that the password is never transmitted between Carol and the server, whether in clear text or encrypted form. However the two parts, Carol and the server, are now sure of who they are. You can read the article of Thomas Wu where the the mathematical process is described. Many documents are also available on the SRP site at Stanford.edu. Note that the RFC 2945 is the SRP proposed standard.
There is also a good article discussing the benefits of SRP at http://www.attrition.org/wrlwnd/crypto/srp/Telnet.html

Practical installation.

As of today, only telnet, ftp and login process are able to use SRP. The binaries page shows numerous ports from Solaris thru HPUX, VMS and Windows NT. There is a Linux-i86 ready distribution version 1.5.1, compiled with libc5 or libc6, but this doesn't provides you the whole secure access you are waiting for: there is no new password database and the password verification just falls back to the standard (read clear password) process of authentification. To use the whole application on a server, you need to download SRP and EPS (Exponential Password Suite). Or compile the sources.

I have tested SRP between a Linux client and a Linux server. I downloaded the SRP source package V1.5.0. This package is complete with SRP, EPS and even a Java telnet client. One thing you need is a crypto library. The standard one used by EPS is the Gnu GMP source package Version 2.0.2. Alternatively, you can find the binary distribution; In such a security context, I prefer to know what's inside the package, though.

You have to have root access to both machine to install the software. On the server side proceed this way:

Unpack and compile gmp-2.0.2:
```
   #cd /usr/develop
   #zcat gmp-2.0.2.tar.gz | tar xvf -
   #cd gmp-2.0.2 ; ./configure
   #make
   #make install
```
This package provides a multi precision library in C; you can work on big numbers, big floats and some big rational numbers. RTFM. This library is now installed under /usr/local.
Now unpack and compile SRP end EPS:
```
   #cd /usr/develop
   #zcat srp-1.5.0.tar.gz | tar xvf -
   #cd srp-1.5.0 ; ./configure
   #make
   
```
At this point I warn you (the files /usr/develop/srp-1.5.0/inst/INSTALL.EPS and INSTALL.SRP warn you too !) against the fact that the installation should be done carefulley. You are going to modify the following programs: su, in.telnetd, in.ftpd, passwd, login, telnet and ftp. Before using them, verify the scripts nasmed installeps and installsrp. Mine were correctly configured to make a backup copy of every original program.

Install EPS and SRP binaries:

   #cd /usr/develop/srp-1.5.0/inst ; installeps 
   #installsrp

On the server, verify that the client and server process communicate correctly. I mean, if the server is called athena, do the following:
```
   # telnet athena
    
```
You should have a normal telnet session, but with the SRP banner. Logout from this session.
Now install binaries on the client side. This time, I choose to install the binary package for Linux compiled with the libc5. This package comes with telnet and ftp client and servers, but no EPS software. On the client, only the telnet and ftp client are needed, however. The SRP telnet and ftp client are fully compatible with any "standard" telnet and ftp server respectively. If they don't find any SRP aware server, they fall back to the usual process of login/password exchange.
```
   #cd /usr/new ; zcat srp-i386-linux5-export.tar.gz
   #installsrp 
    
```
The telnet, in.telnetd, ftp, ftpd binaries are now in place.
Go back to the server. As root, run the tconf utility to configure the new password file named /etc/tpasswd:
```
   #/bin/tconf
```
This command prepares the /etc/tpasswd.conf file with random keys. If you just want to test the software, choose the predefined key, because the computations can take quite a long time. Create a /etc/tpasswd file with mode 644:
```
   #touch /etc/tpasswd ; chmod 644 /etc/tpasswd
```
As a normal user, say cmic, log in normally to the server, and run passwd to record the verifier and salt in the /etc/tpasswd file

Testing.

At this point I installed a LAN analyzer on the server to monitor what is happening on the the LAN.

I log into the client machine as user cmic. Then I telnet to the server. The SRP banner shows up, finds the SRP telnetd daemon and authentification is done. I am connected. On the server side, the analyzer shows the user name, a lot of garbage, but not the password I type. The rest of my telnet session runs unencrypted on the LAN, however.

Installing the tcpdump analyzer on the server side reveals what happen in the wings. Here is an excerpt of a telnet session with the client zapata, a Windows 98 computer with TeraTerm Pro, and the server athena.

In the first phase, the server sends a banner asking for a login name and initiates a new TCP connection on the auth port (see RFC2416).
22:05:29.651074 zapata.1030 > athena.telnet: S 26949076:26949076(0) win 8192 (DF) 
22:05:29.651074 athena.telnet > zapata.1030: S 3008390492:3008390492(0)ack 26949077 win 16060  (DF) 
22:05:29.651074 zapata.1030 > athena.telnet: . ack 1 win 8760 (DF) 
22:05:29.661074 zapata.1030 > athena.telnet: P 1:16(15) ack 1 win 8760 (DF) 
22:05:29.661074 athena.telnet > zapata.1030: . ack 16 win 16060 (DF) 
22:05:29.671074 athena.1043 > zapata.auth: S 3013051018:3013051018(0) win 16060  (DF) 
22:05:29.671074 zapata.auth > athena.1043: R 0:0(0) ack 3013051019 win 0 
22:05:29.691074 athena.telnet > zapata.1030: P 1:4(3) ack 16 win 16060 (DF) 
22:05:29.691074 zapata.1030 > athena.telnet: P 16:19(3) ack 4 win 8757 (DF) 
22:05:29.691074 athena.telnet > zapata.1030: P 4:19(15) ack 19 win 16060 (DF) 
22:05:29.691074 zapata.1030 > athena.telnet: P 19:28(9) ack 19 win 8742 (DF) 
22:05:29.691074 athena.telnet > zapata.1030: P 19:29(10) ack 28 win 16060 (DF) 
22:05:29.801074 zapata.1030 > athena.telnet: . ack 29 win 8732 (DF)
When I type my user name and press the Enter key, these frames run on the LAN:
22:05:50.951074 zapata.1030 > athena.telnet: P 28:47(19) ack 29 win 8732 (DF)    
22:05:50.971074 athena.telnet > zapata.1030: . ack 47 win 16060 (DF) 
22:05:51.471074 athena.telnet > zapata.1030: P 29:103(74) ack 47 win 16060 (DF) 
22:05:51.661074 zapata.1030 > athena.telnet: . ack 103 win 8658 (DF)
Then zapata asks for my password. I type it, then press Enter key. The server authentificates me and send the usual message of welcome, no mail, etc. up to the prompt.
22:06:12.781074 zapata.1030 > athena.telnet: P 47:104(57) ack 103 win 8658 (DF) 
22:06:12.801074 athena.telnet > zapata.1030: . ack 104 win 16060 (DF) 
22:06:12.801074 athena.telnet > zapata.1030: P 103:160(57) ack 104 win 16060 (DF)
.......
.......

The Windows client.

If you launch the Windows telnet client (Windows NT or Windows 98) and try to connect to the server, the message "Warning: This session is not using secure authentication." shows up. Perfectly clear. On the SRP site, however, a telnet binary for windows is available for free. This is a modified version of TeraTerm Pro V2.2 named tterm.zip, which is SRP aware. You can install this package under Windows 98 or Windows NT. It really works with SRP aware servers. It comes with a resizeable window, multiple setup choices for the fonts, colors, and so on. Really nice.

Drawbacks.

The loggin process is a bit slower than usual, but works perfectly well. The ftpd server is not used on my server. If I look at the ftpd line in my /etc/inetd.conf file, I see that the ftpd line is out of service. The wu.ftpd server is used instead. So the SRP aware ftpd server is of no use.

However, if you log in daily on Un*x or secured servers, I recommend using SRP. Between Windows NT servers ans Windows 98 clients, you could use the native process of encrypted passwords on the LAN.