From: Stephen Shortland Date: Sun, 5 Jun 1994 14:00:04 +0100 To: uri@watson.ibm.com Subject: DIP S/Key updates As promised, here are the diffs to 'bolt' S/Key onto dip-3.3.7b. The modifications were very straight forward, as you can see from the diffs. The diffs are against clean dip337b-uri. The earlier password diffs that I sent you are included in these diffs, so you can ignore my previous patch. To compile dip with S/Key support you will need to the skey-linux-1.1b package. You can get this from sunsite.unc.edu (the path is given in the makefile). Compile this package to give you libskey.a, which should be placed in /usr/bin or the dip directory. You only need libskey.a to re-compile dip - binary dists of dip will not need it. The S/Key support comes in two halves: DIP === There is a new command for dip scripts: skey [timeout] This tells dip to look for an S/Key challenge from the server. The challenge looks like: [s/key 98 tu12345] Once it has found the challenge it prompts the user for their secret password. It then uses the password, seed (tu12345) and challenge number (98) to generate a response, with it sends to the server. The user doesn't have to type in the 6 word S/Key response - it is all done automatically. The optional timeout parameter sets how long dip is to wait to see the challenge. errlvl is set to 1 if skey timesout. If skey successfully sends a response, errlvl is set to 0. A sample of a dip script using skey is given below. This is for two directly connected machines, and error handling has been removed for brevity. There is no regular password on the slip account - it uses S/Key authentication only. port cua0 speed 38400 send \r wait login: send slip\r skey 30 get $local remote get $remote remote get $mtu 296 default mode CSLIP DIPLOGIN ======== When a user logs in, diplogin checks their password field in diphosts. If this field is set to "s/key", diplogin will issue an S/Key challenge and wait for a response. If the user does not have S/Key authentication info in /etc/skeykeys, or if their response to the challenge is incorrect, the login session is terminated and an error is logged with syslog. If the passwd field from diphosts does not contain "s/key" diplogin works as it did before - i.e. no password checking is done. Below is a sample of an S/Key authenticated entry from /etc/diphosts: slip:s/key:gate:tuin:255.255.255.0:SLIP test:CSLIP,296 If you want to use S/Key authentication in diplogin, then diplogin will have to run as root, so that it can update /etc/skeykeys after a successful login. [I think that diplogin already has to run as root, so that it can configure the interface and routing tables]. This means that diplogin has to run suid root, which is not a good idea, as diplogin is not a secure program (reasons why are left as an exercise to the reader :-). An alternative, if you use getty_ps is to make diplogin the login program for a particular port. The advantage with this is that diplogin does not have to be suid, but the disadvantage is that the port is dedicated to slip logins. If you already have a login program which does S/Key authentication, then you can leave the password field blank, so diplogin does not try to do a second authentication. -=-=-=-=-=-=- I have been testing out the updates here between my two machines, and they seem to work very well. As I said earlier I am a bit concerned about making diplogin suid root, because of the security implications. How do people normally configure diplogin, so that it can configure the interface etc? A future enhancement may be to make the users password an optional parameter to the skey command, so that they do not have to be prompted. This is complicated a little by the fact that S/Key passwords do not have to be single words. Therefore do_command would probably have to be updated to accept a quoted string as a single parameter. Personally I do not like including passwords in scripts, but other people may find it useful. Anyway here is the patch. If you have any problems, or questions, please give me a shout. Stephen....