Skey authentication at INRIA Sophia

Version

• Presentation
• Installation
• Frequently asked questions
• Index

Presentation

/etc/inet/inetd.conf You will be (or are) confronted with an SKey authentification scheme. This document tries to help you by answering some typical questions. The proposed solutions are close to the local versions of the installed tools, and this might differ with the equivalent tools you find on different sites. Keep your eyes open, and try to be patient, with respect to these different behaviors. If you don't find the answer of one of your questions here, try reading the sophia.skey newsgroup. If you still don't find the answer, you can ask to Semir.

Installation

The SKey authentification mechanism requires the proper configuration of several things like:

• The usual communication commands (login, su, ftp...), which have been modified to be able to negotiate an SKey session. These tools have been modified by the System Managers.

• An initialization tool: keyinit, also installed by the System Managers.

• SKey password (One Time Password) generation tools: key, skey, xskey, also installed by the System Managers.

Each user needs to initialize SKey, using the keyinit command, for each machine on which he plans to connect from outside of INRIA (or from an unstrustable link See Index).

The Unix password will still be allowed on the console of the machine

This new authentification procedure is already in progress for the following platforms: Sun(Sun-OS4 and Solaris2), Dec(OSF1) Sgi(Irix) and PC(Linux).

The host-equivalence mechanism is still available.

Once you have initialized your SKey mechanism, nothing has changed if you try to connect on the console (Unix Password), or from a host-equivalent machine.

For the other untrustable connections (See index), you will need to use an SKey authentification.

The main difference with the classical Unix authentification (you type your password directly when you see the Password prompt) is that SKey is waiting for a password (called One Time Password (OTP)) that you can only produce with a separate tool (like key,skey,xskey).

The OTP generation tool needs two elements (Sequence and Seed), called the challenge, given by the connected machine at each connection, and your Secret Password. These three elements are the input of the generator which gives you the OTP. This OTP is the answer that the connected machine needs to figure if you can connect or not.

You can also simplify this generation phase, by pre-calculating a set of OTP, using the key command. See (the example bellow) for more details.

Frequently Asked Questions

This is a set of common questions that you may ask.

If this is unclear, or if you have a new question, you may find the answer in the sophia.skey newsgroup or by asking to Semir.

Installation:

• How can I initialize an SKey password?
• Should I initialize SKey on each machine of my project
• Can I initialize SKey from outside INRIA?
• Password Syntax
• Index.

  How to use it:

• Can I calculate a set of OTPs in advance? From outside INRIA?
• How can I avoid using SKey from outside INRIA?
• When can I use my Unix password ? And my SKey password?
• How many passwords will I have to memorize?
• How to force an SKey authentification?
• Ftp Feature.

  Practical questions:

• What do I have to do for my first connection on the console?
• Xskey does not automatically paste the challenge!
• Xskey does not recognize the local display and thinks it is unsecure !
• How can I make an authentification from a TX?
• Can I duplicate the skeykeys file from one machine to another?
• Can I duplicate the skey.access file from one machine to another?
• Why an SKey challenge inside INRIA?

  Abstract:

• Why SKey rather Unix password?
• How to use key and xskey outside INRIA

  How can I initialize a SKey password?

  You first need:

  • to be already connected to the machine on which you want to initialize the SKey authentification mechanism. If you cannot connect, you can use someone else's already active connection (Shell, Xterm, Shelltool, ...).

  • to have a locally installed version of OTP generators, like key or xskey.

  • to execute the keyinit command.

  When connected, run the command keyinit

  host% keyinit
  

  keyinit allows you to choose an iteration count (sequence) and a seed. If you just answer RETURN to these questions, the chosen values will be 9999 for the sequence and the seed will be random, which most of the time are accurate values.

  Each time you connect, the sequence will decrease, and the seed remains the same until you use keyinit again. Don't worry too much about these values, you don't need to remember them!

  Then, keyinit will ask you to enter a One Time Password. This OTP is a 6 English word sentence, which is computed by an SKey generator (like the key (terminal interface) or skey (X interface) commands)

  Sophia Version:

  • keyinit will ask you for an additional OTP that need to be calculated with two successive sequences. The reason is to verify that you dont't make a typo when typing your secret password. (Warning: a common mistake is to not recalculate an OTP here, and to give twice the same OTP to keyinit, which obviously will not work !).

  • if you had already initialized the SKey mechanism, keyinit will verify first what you know the old Secret Password, by asking you an OTP corresponding to this old one.

  The following example is a complete first initialization of the SKey mechanism for the user bill. Bill choose the two default values for the sequence and the seed, by answering (CR) to the first two questions. (CR) can be Return or Enter depending of your keyboard.

  Examples

  SKey initialization

  Sequence example 1:
  
  bill@host5% keyinit(CR)
  ********************************************************
  Remember: FOR ALL SKey OTP PASSWORDS that you will type
  You need a SKey OTP(One Time Password) calculation tool
  like xskey (prefered) or key applications
  ********************************************************
  Enter sequence count from 2 to 9999 [default 9999]: (CR)
  Enter new key [default xzf9800]: (CR)
  SKey 9999 xzf9800
  SKey OTP: 
  
  

  xskey

  LAKE EM BADE SWUM ROT TOAD(CR)

  SKey 9998 xzf9800 SKey OTP:

  xskey

  WORE COY GOWN FLO WEAN OINT(CR)

  ID bill SKey is 9998 xzf9800 WORE COY GOWN FLO WEAN OINT bill@host5%

  Reinitialization of a SKey Password

  The user bill wants to reinitialize his SKey Password. The reason can be one of the following:

  • Change the Secret Password

  • Change the sequence (for example because it is too high and takes long time to compute on his laptop, or because it is too low, and bill will no longer be allowed to connect soon)

  • Change the seed (keyinit proposes a new seed each time)

  The locally installed keyinit version works just like the usual Unix command passwd. The old password is requested and then it requests twice the new password. The only change is what you don't give your secret password directly to keyinit, but calculates it with an external generator.

  bill@host5% keyinit(CR)
  ********************************************************
  Remember: FOR ALL SKey OTP PASSWORDS that you will type
  You need a SKey OTP(One Time Password) calculation tool
  like xskey (prefered) or key applications
  ********************************************************
  
  Verifying user: bill
  Please use your old SKey password to compute the OTP
  SKey 9120 xzf9800
  SKey OTP: 
  
  

  xskey

  IKE WAD LYON GENE RIFT RAFT(CR)

  Enter sequence count from 2 to 9999 [default 9999]: (CR) Enter new key [default xzf9801]:(CR) SKey 9999 xzf9801 SKey OTP:

  xskey

  ALOE DUD FROM TOO GUM WORK(CR)

  SKey 9998 xzf9801 SKey OTP:

  xskey

  RAN NON NAIR FRY HUE HELM(CR)

  ID bill SKey is 9998 xzf9801 RAN NON NAIR FRY HUE HELM bill@host5% Locally new interface:

  You can notice that the (local) xskey application used for the last example has a slightly different interface that the one used for the first example (which is the one you could also find on another sites) In the following example, you can also notice that a WARNING message is printed, "Using an Insecure Channel". This comes as xskey is called on a nonlocal display.
  
  

  xskey -insecure

  This xskey session is TOTALLY insecure and MUST be AVOIDED !!!

  Why SKey rather Unix password?

  With SKey, your secret password (the one you are the only one to know) is never present on the network. It is typed in a local application (unless you use xskey or key in an insecure fashion).

  The message present on the network is the OTP, which (conformly to its name) cannot be reused.

  Of course, if you don't take the minimal precautions (run key on a distant machine or run xskey on a display different than [unix]:0), then your secret password will be present on the network and thus could be seen by anyone and used to produce an OTP by someone other than you. In this case, your account becomes as weak as before.

  Can I initialize SKey from outside INRIA?

  Because the keyinit command expects you to answer OTPs as passwords, the answer is YES. But you will need local versions of the OTP generators: key or xskey. Local means that the binary should run on the CPU where your keyboard is connected.

  Can I calculate a set of OTPs in advance? From outside?

  The key command allows you to do it. Given the 3 calculation elements (seed, sequence, and secret password), it can produce a listing of a set of valid OTPs.

      bill@host5% key -n 10 9998 ym06578(CR)
          Reminder - Do not use this program while logged in via telnet or rlogin.
      Enter secret password: **********(CR)
      9989: NOLL GLIB YET DIN BEG ELLA   
      9990: BABE DUSK COCA OMAN TUNA ONUS
      9991: CANE DIED AIM RILL WEED WHY  
      9992: BRAG CROW GAIN AWAY LAST SAD 
      9993: NUT DUD COCA SLAM REEF DONE  
      9994: RACY BALM MOP WAVY EEL RAGE  
      9995: COCO BADE LOP CODA CHOU KEEL 
      9996: GINA WONT OVA UNIT WOVE JOVE 
      9997: IONS HUM PAR LILT CALM TORN  
      9998: ALLY CURT SWAN DOLL HOLM ISLE
  ...
  

  Note that key asks you for your secret password. This command is really insecure and should be avoided from a nonlocal connection. (the reminder message warns you about it)

  Also, you should be careful to not have a large list (just in case you loose the paper) You should realize that the listing gives the ability to someone to connect at Inria on your account (This person should be also able to change your password with keyinit). Note too that the list does not give you the name of the target host or the seed, but it is really a weak protection, anyone could have traced which host you usually connect to.

  How many passwords will I have to memorize?

  You will have to remember at least 2 passwords:

  • your usual Unix password, which will be still efficient for a connection on the console, under XDM, or xlock.

  • your SKey secret password, which is necessary in all the other cases (external connection, internal connection on untrusted hosts, ...). This secret password should always be typed using a generator (key/xskey). Even if you have to initialize SKey on several machines, you can take the same secret password for all of these machines, because the random seed should randomize the OTP for each machine differently

  When can I use my Unix password? And my SKey password?

  The locally installed connection procedures are able to decide if the connection is secure or not(*), If it is secure, the Unix password will be allowed, if not, an SKey OTP will be required. You should easily recognize which one you can use by reading the command banner:

      Password:
  
  means that you can use the Unix password.
  
      SKey Sequence Seed
      Skey OTP: 
  
  means that you NEED to use a SKey OTP
  

  (*)

  The connection is either secure or allowed by the sysadmin. Allowed does not mean secure, it is sometimes necessary (for example, to unblock a situation) to temporarily authorize an insecure session. The /etc/skey.access file describes the allowed/denied connections.

  Ftp Feature

  The ftp banner prompt is a little bit funny. The problem comes from the fact that the program which prompts it is the client part of ftp (ftp) and not the server part (ftpd). Of course, we don't have control of this part of the software, because it runs on the machine where you come from (which is not inside INRIA). What we did to allow the ftp service to use SKey is to modify the server part. You can easily recognize if you are allowed, or not, to use a Unix password by reading the first message sent back by ftpd to the client.
  
  Ftp connection with SKey required
  
  
  

  Connected to hostx.inria.fr.
  220 hostx FTP server (Version 4.123 Thu Jun 15 14:53:07 MET DST 1995) ready.
  Name (hostx:bill): (CR)
  331 SKey OTP required for bill: SKey 9935 vu30727
  Password: EVEN GIRD JOT AWAY BOLO RAIN(CR)
  230 User bill logged in.
  ftp> 
  

  
  
  Ftp connection with both Unix password and SKey OTP allowed
  
  
  

  Connected to hostx.inria.fr.
  220 hostx FTP server (Version 4.123 Thu Jun 15 14:53:07 MET DST 1995) ready.
  Name (hostx: lucky): (CR)
  331 Unix password or SKey OTP with challenge: SKey 9911 v480129x
  Password: ********
  230 User lucky logged in.
  ftp>  
  

  lucky should have given the SKey OTP corresponding to the challenge 9911 v480129x

  Here you could have one more problem. If you are inside INRIA and using our local version of secure xterm, the xterm could have grabbed the keyboard automatically (Keyboard Grab). If you wanted to use an SKey OTP, then you have to ungrab the keyboard before typing your secret password in the key or xskey commands. This can be done by calling the first entry of the xterm menu (Control+Mouse Button 2).

  How can I avoid using SKey from outside INRIA?

  The sysadmin can modify the /etc/skey.access file, and :

  • allow a Unix authentification for you (your login name)

  • allow a Unix authentification for the machine where you come from.

  The machine should also be declared host equivalent, in your ~/.rhosts file.

  Be aware of the fact that the Sophia System Administration does not allow you to add an external machine in your ~/.rhosts file. Each external (i.e. untrustworthy) connection must be authentified with SKey.

  Should I initialize SKey on each machine of my project

  Not at all. You only need to initialize SKey on the machine(s) that you plan to connect from outside INRIA.

  The local connection on the console is always allowed with the usual Unix password. Inside INRIA you should never use SKey from one machine of your project to an another, because of default host equivalence.

  If you plan to connect to a machine from an another project, you should declare your own machine in your ~/.rhosts file. The only problem you could encounter here is that ~/.rhosts file is not visible (which should never happen).

  Xskey does not automatically paste the challenge !

  The user interface with Shelltool/Cmdtool/Winterm has not been modified so that copy/paste with xskey is not automatic. Only the xterm application, modified locally, has this feature.

  In this case (which can also append when you are outside INRIA), you have to copy the SKey challenge in the paste buffer and paste it in key or xskey. (WARNING: don't make a mistake when pasting, be sure to paste the sequence and the seed in the right place)

  Xskey does not recognize the local display and thinks it is insecure !

  You did not give the right value to the DISPLAY environment variable, which must be:
  
  unix:0

  or :0
  

  In this case, xskey does not think you are local (in fact, even if DISPLAY is set to hostname:0 the keystrokes you type go through the TCP layers of your machine, and can be sniffed) You could also type: xskey -display :0
  

  or restart you X-server, with a proper configuration file.

  What do I have to do for my first connection on the console?

  The Unix password is always allowed on the console.

  How can I make an authentification from a TX?

  At Sophia:

  On the TX Sun terminals, a xskey application is running locally at boot time.If you don't see it on the screen, you should call it by typing on the xskey button of the main TX menu

  On the TX Gipsy terminals, you can connect via a serial line to a terminal emulator, which is running a key application. You call it by cliquing on the Menu Setup/Serial Port Setup/Terminal Emulation button (You should check with the SEMIR if it does not work).

  For all of the remaining TX configurations, you should have a printed list of allowed OTPs , or ask to your sysadmin to authorize the TX in the TX server configuration file.

  How to force an SKey authentification?

  If a Sophia machine prompts a Unix password banner(*), and if I want to connect with an SKey OTP (for that machine I know that I already initialized it, of course !), I can receive an SKey challenge by typing (CR) at the Unix prompt. With this challenge, I will be able to compute the corresponding OTP.

  (*) If you come from a secure or an allowed host (see /etc/skey.access), the Unix password banner will be presented first, because the Unix password is allowed.

  How to use key, xskey outside INRIA

  The ftp-sop.inria.fr inria server contains a set of pre-compiled binaries for key and xskey for several Unix platforms and also for Macintosh and PC.

  Can I duplicate the skeykeys file from one machine to another?

  THIS IS TOTALLY FORBIDDEN

  , because if you do it, you will have several machines on the network, which have an initialized SKey mechanism with the same seed and sequence. And so, the OTP will be reusable on different machines.

  Can I duplicate the skey.access file from one machine to another?

  Yes, this is also a good method to give to all the machines of your project the same level of protection

  Remark: Authorizations could be known (whence set) as local (/etc/skey.acces, not a NIS map,...) and distributing copies of that file will open (or cut, depending on current file) unwanted access on other hosts.

  Why an Skey challenge inside INRIA?

  If the machine where you want to connect does think that the machine where you are coming from is insecure, it will require an SKey OTP. It depends if the two machines are not host equivalent.

  You should be really aware of the fact that if the Unix password is transmitted to the machine to which you want to connect, then your Unix password is transmited on the network. Typing a Unix password when you are abroad is INSECURE. Take care of the contents of the /etc/skey.access file.

  ---

  Index

  • Sequence

    : this is a counter, which is decremented each time you connect to a machine. It is initialized by keyinit and is part of the SKey challenge. Your secret password and the seed are the input of a crypt function. This crypt function is repeated Sequence times to give the OTP.

  • OTP

    : acronym of One Time Password. This is a set of 6 English words, which are the result given by a key or xskey command (or skey on PC or MacIntosh). This OTP is the result of the iteration of a crypt function on a combination of your secret password and a seed.

  • Password

    : or secret password. This is your SKey password. Your are the only one to know it (it is not even stored on a machine of INRIA). This password is never typed directly to a connection command (ftp/telnet/rlogin/su/login) but is given to an OTP generator, like key or xskey. This password is not your Unix password, and must be different from your Unix password. The locally installed version of key or xskey requires a minimal length for the secret password, and the presence of special characters.

  • Seed

    : a random set of characters, initialized by the keyinit command. On each machine of the network you should have a different seed, which is usually the case if you choose the keyinit default value. This value is constant between two keyinit calls.

  • skey.access

    : configuration file for SKey. It describes the Unix allowed connections.

  • skeykeys

    : this file contains the SKey information of all the users. It is the SKey equivalent of a passwd file.

  • Untrustworthy connection

    : every connection from outside INRIA, or every connection with an application which may be running from outside (ex: su on a rlogin/telnet session).

  Daniel Terrer

  Phone +33 04 93 65 77 22, fax +33 04 93 65 76 02

  email: Daniel.Terrer@inria.fr