Abstract

The intelligent pervasive network environment is thing which invisible computer that is not shown linked mutually through network so that user may use computer always is been pervasive. As a number of pervasive network services are available and smart environment is expanding into ubiquitous computing environment, we need to protect intelligent pervasive environment system from illegal accesses and a variety of threats. Intelligent pervasive environment is exposed to various cyber attacks of Internet, involves hacking, malicious codes, worms, viruses, Dos attacks, and eavesdropping since it is connected to Internet. So in this paper, we propose authentication in a intelligent pervasive environment security for guaranteeing reliability and availability including authentication, authorization system. We proposed S/Key based authentication, scheme for secure remote access in intelligent pervasive environments. Furthermore, we describes smart environment authentication which is the basic and essential element in the pervasive network security. And our device authentication concept can offer pervasive network service users convenience and security.

1. Introduction
In any computing environment, passwords provide the first line of defense against unauthorized use. Users who are able to respond with the correct password at 1

the Password: prompt are presumed to be who they say they are. Anyone can guess or steal a legitimate user's password. Guessing can be made much less probable by avoiding the selection of easily -guessed passwords. Theft can be minimized by not writing down passwords, not telling them to others, and not allowing anyone to see them when they are typed in. Presumably, users are savvy (knowledgeable) enough not to enter their password when someone is looking over their shoulder. Unfortunately, this is not the case. Unlike the days of yore, when logins took place from hardwired terminals, and the only place to intercept a password was over the user's shoulder. Today's ubiquitous (present everywhere) interconnected networks make it possible for passwords to be grabbed (captured) as they traverse the Internet. Indeed, there have been well-publicized instances of password "sniffers" being used on major regional networks and the machines of Internet Service Providers, leading to thousands of passwords being compromised report. One way to prevent such compromises in the future is for authentication to take place over an encrypted connection. One can use a scheme, which makes passwords obtained through eavesdropping useless. This is the approach taken by S/KEY.

2. What is S/Key ?
S/KEY is a software package developed at Bellcore (Bell Communications Research laboratory). S/Key is a challenge/response one-time password scheme. A challenge/response system is any system where the 'response' can be computed from the 'challenge' and some secret information that only the user knows. In order to be 2

useful, the system must be designed such that knowledge of previous challenge/response pairs is not useful in computing future pairs. It is a one-time password system. Each password used in the system is usable only for one authentication. Passwords cannot be re-used, and thus, intercepted passwords are of no utility. Moreover, knowledge of already-used passwords in a user's S/KEY password sequence provide no information about future passwords. Thus, even all of one's S/KEY passwords are "sniffed" as they transit an insecure network, they will not benefit their interceptor.

3. Attributes of the S/KEY

The S/KEY authentication system is a simple scheme that protects user passwords against passive attacks. It can, however, be easily and quickly added to almost any UNIX system without requiring any additional hardware and without requiring the system to store information (such as plain text passwords) that would be more sensitive than the encrypted passwords already stored. 3

Some of the properties of the S/KEY system are: Eavesdropping protection Conceptually simple and easy to use Based on a memorized secret password No secret algorithms. No secrets stored on host.

4. How S/KEY works?

A user initializes S/KEY by selecting a secret password and n, a number of passwords to generate. A secure hash function (currently MD4) is applied to the secret password n times. A secure hash function is a function that is easy to compute in forward direction, but computationally infeasible to invert. If F is the secure hash function with input x and output y, then computing y given x, y = F (x), is fast and easy, but finding an x0 such that y = F (x0) for a given y is extremely difficult. The result obtained from the hash function is stored on the server. When the user attempts to log in, the server issues a challenge, which is the number n-1. Software on the user's client machine prompts for his/her secret password, and applies n-1 iterations of the hash function to it, and sends this response to the server. The server applies the hash function to this response. If the result it obtains is the same as 4

the value it stored earlier, the authentication worked. The user is allowed in, and the server replaces the stored value with the response obtained from the client, and decrements the password counter.

5. Operation of S/KEY
The S/KEY one-time password authentication system uses computation to generate a finite sequence of single-use passwords from a single secret. The security is entirely based on a single secret that is known only to the user.

S/KEY Initialization:
S/Key system needs to be initialized for each user who will use S/Key passwords.S/Key uses secret pass phrase to ensure the security of the entire scheme. The steps to be followed are: Log in to delta from another machine or terminal server. Type the command Keyinit Enter the S/KEY secret password of your choice when prompted. This password will not be stored anywhere, so the user must remember it. The password can be of any length, and may include punctuation and spaces, as well as letters and numerals. 5

Generally long sentences are used. Enter the secret password a second time when prompted for it. keyinit will determine the encrypted form of password, and will store it on delta. Here's an example. User Chris is initializing a sequence of 99 passwords on delta. delta:/homes/chris[55]% keyinit Adding chris: Reminder - Only use this method if you are directly connected. If you are using telnet or rlogin exit with no password and use keyinit -s. Enter secret password: (secret password not shown, and will not be echoed) Again secret password: (likewise) ID chris s/key is 99 pe61662 LOB PER RICK WINO HARK HAL At this point, Chris is ready to have his login authenticated via S/KEY. .

Login Authentication with S/KEY:

The steps to be followed are: Enter the username at the login: prompt. With keyInit the S/KEY challenge s/key 98 pe61662, and then the password: prompt . The number 98 is the S/KEY sequence number, and "pe61662" is the encryption salt. The sequence number is one less than the initial sequence number of 99 which is generated by the server as used when Chris ran keyinit last. Then key will prompt for your secret password. Respond appropriately. key will respond with six words, the one-time password. The host computer first saves a copy of the one-time password it receives, then it applies the one-way function to it. If the result does not match the copy stored in the system's password file, then the request fails. If they match, then the user's entry in the system password file is updated with the copy of the one-time password that

was saved before the final execution (by the server) of the one-way function. This updating advances the password sequence.

s/key authentication

S/KEY authentication After password generation, the user has a sheet of paper with n passwords on it. The first password is the same password that the server has stored. This first password will not be used for authentication (the user should scratch this password on the sheet of paper), the second one will be used instead: The user provides the server with the second password pwd on the list and scratches that password. The server attempts to compute H(pwd) where pwd is the password supplied. If H(pwd) produces the first password (the one the server has stored), then the authentication is successful. The server will then store pwd as the current reference. For subsequent authentications, the user will provide password i. (The last password on the printed list, password n, is the first password generated by the server, H(W), where W is the initial secret). The server will compute H(password i) and will compare the result to password i 1, which is stored as reference on the server.

Establishing a New Password Sequence:

7

Because the number of one-way function iterations executed by the user decreases by one each time, at some point the user must reinitialize the system or be unable to log in again. One may wish to increase this number in order to avoid having to run keyinit too frequently. This is done by executing a special version of the password command. Here's how it is done. Type the command keyinit s It will tell what the old salt is, then prompt for a new sequence count. Enter a desired number of passwords (eg., 1000). keyinit then prompts for a new key, and provides a default response. Accept this default. keyinit then provides a challenge. Run your local S/KEY encryption program (eg., key) just as if you were logging in. Your local invocation of key will prompt for your secret password. Enter it, and you will get an encrypted response. Enter the encrypted response obtained in the previous step at the waiting remote invocation of keyinit. A new sequence of passwords are generated successfully. Here is an example. delta:/homes/chris[52]% keyinit -s Updating chris: Old key: pe61662 Reminder you need the 6 english words from the skey command. Enter sequence count from 1 to 9999: 1000 Enter new key [default pe61663]: s/key pe61663 s/key access password: Then... cicero.spudly.com:/usr/chris[57]% key 1000 pe61663 Reminder - Do not use this program while logged in via telnet or rlogin. Enter secret password: 8

PEA TUB YALE BOWL GULF JUTE cicero.spudly.com:/usr/chris[58]% Back on delta... s/key access password: PEA TUB YALE BOWL GULF JUTE This completes the process. The next time Chris tries to log in to delta, he will be challenged for the 999th password in the new sequence.

Creating a List of Passwords:

Occasionally when travelling , one may not have a trusted local host upon which to run the key command or its equivalent. Under such circumstances, we can run key prior to the departure, and have it generate a list of passwords which can be referred during the absolutely necessary. To generate the list, you need to know the current key and sequence number for your S/KEY password sequence. This is the information presented to you as a login challenge. It is maintained in the file /etc/skeykeys. You can extract your information from this file using the keyinfo command. The first field is the sequence number, and the second is the key. These will be used in conjunction with your secret password to generate the list of one-time passwords. Here is an example which generates seven passwords: waldo:/homes/chris[57]% keyinfo 1000 pe61664 waldo:/homes/chris[58]% key -n 7 1000 pe61664 Reminder - Do not use this program while logged in via telnet or login. Enter secret password: (not shown) 994: REIN SAG WART NOVA GORE NE 995: OW OWE SARA OAT TUNA GREY 996: RAYS GALE DRY ROAD RISK VETO 997: RAY RUSS SIT HYDE LOGE LAP 998: WOK BLUM YOGA RUTH SING RUNG 999: BE RISK BOLT HEN COAL ROSS 1000: JOKE WINE HOVE AUNT TIER DRUG trip. This list should be treated with the utmost care. No identifying information should appear on it, and it should be only as long as is

These can be printed off, and used while traveling . When login presents its numbered S/KEY challenge, the password corresponding to it can be entered. If this process is unacceptably cumbersome, you can use the keyprint command, which will automatically produce a credit-card sized list of passwords. Dictionary for Converting Between S/KEY 6-Word and Binary Formats This dictionary is from the module put.c. The code for this module, and an implementation of the entire S/KEY One Time Password System is available by anonymous ftp from ftp.bellcore.com in the directory pub/nmh/skey.

"A",

"ABE", "ACE", "ACT", "AD",

"ADA", "ADD", "AMY", "ASH",

"AGO", "AID", "AIM", "AIR", "ALL", "ALP", "AM", "AN", "APT", "ARC", "ARE", "ARK", "ARM", "ART", "AS", "ASK", "AT", "AWL", "AWN", "AX",

"ANA", "AND", "ANN", "ANT", "ANY", "APE", "APS", "ATE", "AUG", "AUK", "AVE", "AWE", "AWK", "AYE", "BAD", "BAG", "BAH", "BAM", "BED", "BEE", "BEG",

"BAN", "BAR", "BAT", "BAY", "BE",

"BEN", "BET", "BEY", "BIB", "BID", "BIG", "BIN", "BIT", "BOB", "BOG", "BON", "BOO", "BOP", "BOW", "BOY", "BUB", "BUD", "BUG", "BUM", "BUN", "BUS", "BUT", "BUY", "BY", "BYE", "CAB", "CAL", "CAM", "CAN", "CAP", "CAR", "CAT", "CAW", "COD", "COG", "COL", "CON", "COO", "COP", "COT", "COW", "COY", "CRY", "CUB", "CUE", "CUP", "CUR", "CUT", "DAB", "DAD", "DAM", "DAN", "DAR", "DAY", "DEE", "DEL", "DEN", "DES", "DEW", "DID", "DIE", "DIG", "DIN", "DIP", "DO", "DOE", "DOG", "DON", "DOT", "DOW", "DRY", "DUB", "EEL", "END", "DUD", "DUE", "DUG", "DUN", "EAR", "EAT", "ED", "EGG", "EGO", "ELI", "ELK", "ELM", "ELY", "EM",

"EST", "ETC", "EVA", "EVE", "EWE", "EYE", "FAD", "FAN", "FAR", "FAT", "FAY", "FED", "FEE", "FEW", "FIB", "FIG", "FIN", "FIR", "FIT", "FLO", "FLY", "FOE", "FOG", "FOR", "FRY", "FUM", "FUN", "FUR", "GAB", "GAD", "GAG", "GAL", "GAM", "GAP", "GAS", "GAY", "GEE", "GEL", "GEM", "GET", 10

"GIG", "GIL", "GIN", "GO",

"GOT", "GUM", "GUN", "GUS", "HAD", "HAL", "HAM", "HEM", "HID", "HIM", "HIP",

"GUT", "GUY", "GYM", "GYP", "HA", "HEN", "HER", "HEW", "HEY", "HI", "HIS", "HIT", "HO", "I", "IO",

"HAN", "HAP", "HAS", "HAT", "HAW", "HAY", "HE",

"HOB", "HOC", "HOE", "HOG", "HOP", "IKE", "ILL", "INK", "INN", "IT",

"HOT", "HOW", "HUB", "HUE", "HUG", "HUH", "HUM", "HUT", "ICY", "IDA", "IF", "ION", "IQ", "IRA", "IRE", "IRK", "IS",

"ITS", "IVY", "JAB", "JAG", "JAM", "JAN", "JAR", "JAW", "JAY", "JET", "JIG", "JIM", "JO", "KID", "KIM", "KIN", "KIT", "LA", "JOB", "JOE", "JOG", "LAB", "LAC", "LAD", "JOT", "JOY", "JUG", "JUT", "KAY", "KEG", "KEN", "KEY", "LAG", "LAM", "LAP", "LAW", "LAY", "LEA", "LED", "LEE", "LEG", "LEN", "LEO", "LET", "LEW", "LID", "LIE", "LIN", "LIP", "LIT", "LO", "LOB", "LOG", "LOP", "LOS", "LOT", "MAC", "MAD", "LOU", "LOW", "LOY", "LUG", "LYE", "MA",

"MAE", "MAN", "MAO", "MAP", "MAT", "MAW", "MAY", "ME",

"MEG", "MEL", "MEN", "MET", "MEW", "MID", "MIN", "MIT", "MOB", "MOD", "MOE", "MOO", "MOP", "MOS", "MOT", "MOW", "MUD", "MUG", "MUM", "MY", "NAT", "NAY", "NE", "NIL", "NIP", "NIT", "NO", "NAB", "NAG", "NAN", "NAP", "NED", "NEE", "NET", "NEW", "NIB", "NOB", "NOD", "NON", "NOR", "NUN", "NUT", "O", "ONE", "OR", "OAF", "OFF", "OFT", "ORB",

"NOT", "NOV", "NOW", "NU", "OH", "OIL", "OK",

"OAK", "OAR", "OAT", "ODD", "ODE", "OF", "OLD", "ON", "ORE", "ORR", "OS",

"OTT", "OUR", "OUT", "OVA", "OW", "PA", "PAD", "PAL", "PAM", "PIE",

"OWE", "OWL", "OWN", "OX",

"PAN", "PAP", "PAR", "PAT", "PAW", "PAY", "PEA", "PEG", "PEN", "PEP", "PER", "PET", "PEW", "PHI", "PI", "PIN", "PIT", "PLY", "PO", "POD", "POE", "POP", "POT",

"POW", "PRO", "PRY", "PUB", "PUG", "PUN", "PUP", "PUT", 11

"QUO", "RAG", "RAM", "RAN", "RAP", "RAT", "RAW", "RAY", "REB", "RED", "REP", "RET", "RIB", "RID", "RIG", "RIM", "RIO", "RIP", "ROB", "ROD", "ROE", "RON", "ROT", "ROW", "ROY", "RUB", "RUE", "RUG", "RUM", "RUN", "RYE", "SAC", "SAD", "SAG", "SAL", "SAM", "SAN", "SAP", "SAT", "SAW", "SAY", "SEA", "SEC", "SEE", "SEN", "SET", "SEW", "SHE", "SHY", "SIN", "SIP", "SIR", "SIS", "SIT", "SKI", "SKY", "SLY", "SO", "SOB", "SOD", "SON", "SOP", "SOW", "SOY", "SPA", "SPY", "SUB", "SUD", "SUE", "SUM", "SUN", "SUP", "TAB", "TAD", "TAG", "TAN", "TAP", "TAR", "TEA", "TED", "TEE", "TEN", "THE", "THY", "TIC", "TIE", "TIM", "TIN", "TIP", "TO", "UN", "UP", "TOE", "TOG", "TOM", "TON", "TOO", "TOP", "US", "USE", "VAN", "VAT", "VET", "VIE", "WEB", "WED", "TOW", "TOY", "TRY", "TUB", "TUG", "TUM", "TUN", "TWO", "WAD", "WAG", "WAR", "WAS", "WAY", "WE", "WOO", "WOW", "WRY", "WU",

"WEE", "WET", "WHO", "WHY", "WIN", "WIT", "WOK", "WON", "YAM", "YAP", "YAW", "YE", "YEA", "YES", "YET", "YOU", "ABED", "ABEL", "ABET", "ABLE", "ABUT", "ACHE", "ACID", "ACME", "ACRE", "ACTA", "ACTS", "ADAM", "ADDS", "ADEN", "AFAR", "AFRO", "AGEE", "AHEM", "AHOY", "AIDA", "AIDE", "AIDS", "AIRY", "AJAR", "AKIN", "ALAN", "ALEC", "ALGA", "ALIA", "ALLY", "ALMA", "ALOE", "ALSO", "ALTO", "ALUM", "ALVA", "AMEN", "ANDY", "ANEW", "ANNA", "ANNE", "ANTE", "ANTI", "AQUA", "ARAB", "ARCH", "AREA", "ARGO", "ARID", "ARMY", "ARTS", "ARTY", "ASIA", "ASKS", "ATOM", "AUNT", "AURA", "AUTO", "AVER", "AVID", "AVIS", "AVON", "AVOW", "BADE", "BAIL", "BAIT", "BAKE", "BALD", "BALE", "BALI", "BALK", "BALL", "BALM", "BAND", "BANE", "BANG", "BANK", "BARB", "BARD", "BARE", "BARK", "BARN", "BARR", "BASE", "BASH", "BASK", "BASS", "BATE", "BATH", "BAWD", "BAWL", "BEAD", "BEAK", "BEAM", "BEAN", "BEAR", "BEAT", "BEAU", "BECK", "BEEF", "BEEN", "BEER", "BEET", "BELA", "BELL", "BELT", "BEND", "BENT", "BERG", "BERN", "BERT", "BESS", 12 "AWAY", "AWRY", "BABE", "BABY", "BACH", "BACK", "AMES", "AMID", "AMMO", "AMOK", "AMOS", "AMRA",

"BEST", "BETA", "BETH", "BHOY", "BIAS", "BIDE", "BIEN", "BILE",

6. Secure Hash Function

A secure hash function is a function that is easy to compute in theforward direction, but computationally infeasible to invert. TheS/KEY system is based on the MD4 Message Digest algorithm designed byRonald Rivest [2]. authentication system went into use, the MD5 Message Digest was released. We have chosen to continueto use MD4 due the large number of client programs that have beendistributed. Some sites have generated functionally similar systemsbased on MD5. Clearly clients and hosts must use the same securehash function to interoperate. The S/KEY system one-time passwords are 64 bits in length. This is believed to be long enough to be secure and short enough to be manually entered (see below, Form of Passwords) when necessary. The S/KEY system applies the secure hash function multiple times, producing a 64 bit final output. MD4 accepts an arbitrary number of bits as input and produces a 128 13 Since the S/KEY

bit output. The S/KEY secure hash function consists of applying MD4 to a 64 bit input and folding the output of MD4 with exclusive or to produce a 64 bit output. Generation of One-Time Passwords This section describes the computation of the S/KEY one-time passwords. It consists of a preparatory step in which all inputs are combined, a generation step where the secure hash function is applied multiple times, and an output function where the 64 bit one-time

RFC 1760

The S/KEY One-Time Password System

February 1995

password is displayed in readable form. The client's secret pass phrase may be of any length and should be more than eight characters. As the S/KEY secure hash function described above accepts a 64 bit input, a preparatory step is needed. In this step, the pass phrase is concatenated with a seed that is transmitted from the server in clear text. This non-secret see allows a client to use the same secret pass phrase on multiple machines (using different seeds) and to safely recycle secret passwords by changing the seed. (For ease in parsing, the seed may not contain any blanks, and should consist of strictly alphanumeric characters.) The result of the concatenation is passed through MD4,and then reduced to 64 bits by exclusive-OR of the two 8-byte halves. The following code fragment uses the MD4 implementation defined in RFC 1320 [2] and defines the preparatory step: strcpy(buf,seed); strcat(buf,passwd); MDbegin(&md) MDupdate(&md,(unsigned char *)buf,8*buflen);

14

/* Fold result to 64 bits */ md.buffer[0] ^= md.buffer[2]; md.buffer[1] ^= md.buffer[3]; A sequence of one-time passwords is produced by applying the secure hash function multiple times to the output of the preparatory step (called S). That is, the first onetime password is produced by passing S through the secure hash function a number of times (N) specified by the user. The next one-time password is generated by passing S though the secure hash function N-1 times. An eavesdropper who has monitored the transmission of a one-time password would not be able to generate any succeeding password because doing so would require inverting the hash function. Form of Passwords The one-time password generated by the above procedure is 64 bits in length. Entering a 64 bit number is a difficult and error prone process. Some S/KEY system one-time password calculator programs to insert this password into the input stream, others make it available for system cut and paste. Some arrangements require the one-time password to be entered manually. The S/KEY system is designed to facilitate this manual entry without impeding automatic methods. password is therefore converted to, and accepted as, a sequence of six short (1 to 4 letter) English words. Each word is chosen from a dictionary of 2048 words; at 11 bits per word RFC 1760 The S/KEY One-Time Password System February 1995 one-time The one-time

passwords may be encoded. Interoperability requires at all S/KEY system hosts and calculators use the same dictionary. The standard dictionary is attached to this RFC.

Verification of One-Time Passwords

A function on the host system that requires S/KEY authentication is expected to issue an S/KEY challenge. This challenge give the client the current S/KEY parameters - the sequence number and seed. It is important that the S/KEY challenge 15

be in a standard format so that automated clients (see below) can recognize the challenge and extract the parameters. The format of the challenge is: s/key sequence_integer seed The three tokens are separated by single space characters. terminated by a blank or a newline. Given the parameters and the secret pass phrase, the client can compute (or lookup) the one time password. It then passes it to the host system where it can be verified. The host system has a file (on the UNIX reference implementation it /etc/skeykeys) containing, for each user, the one-time password is The challenge is

from the last

successful login, or it may be initialized with the first one-time password of the sequence using the keyinit command (this command name may be implementation dependent). To verify an authentication attempt, it passes the transmitted one-time password through the secure hash function one time. If the result of this operation matches the stored previous one-time password, the authentication is successful and the accepted one-time password is stored for future use. Because the number of hash function applications executed by the client decreases by one each time, at some point the user must reinitialize the system of be unable to login again. This is done by using the keyinit command which allows the changing of the secret pass phrase, the iteration count, and the seed. A frequent technique is to increment a trailing digit(s) of the seed and to reset the iteration count (to something in range of 500-1000). Clients Several programs are available to calculate S/KEY one time passwords.Included in the reference implementation are command line interfaces for UNIX and PC systems (key), TSR interfaces for PCs (ctkey,termkey, and popkey), and GUI interfaces for Macintosh and Windows (keyapp and un-named Macintosh interface). RFC 1760 The S/KEY One-Time Password System 16

The most basic calculator is the key command whose format is: key [-n count] sequence seed The optional count is used to display more than a single one timepassword. This is useful to create a paper list of one time passwords. The most automated calculator is the termkey program that runs as aTerminate and Stay Resident (TSR) program on a PC. It scans the screen to find the S/KEY parameters, prompts for the secret pass phrase, and stuffs the one time password into the keyboard buffer.

GENERATION OF ONE-TIME PASSWORDS

This section describes the generation of the one-time passwords.This process consists of an initial step in which all inputs arecombined, a computation step where the secure hash function isapplied a specified number of times, and an output function where the64 bit one-time password is converted to a human readable form. Appendix C contains examples of the outputs given a collection ofinputs. It provides implementors with a means of verification the use of these algorithms. RFC 2289 A One-Time Password System February 1998

Initial Step In principle, the user's secret pass-phrase may be of any length. To reduce the risk from techniques such as exhaustive search or dictionary attacks, character string passphrases MUST contain atleast 10 characters (see Form of Inputs below). All implementations MUST support a pass-phrases of at least 63 characters. The secret

17

pass-phrase is frequently, but is not required to be, textual information provided by a user. In this step, the pass phrase is concatenated with a seed that is transmitted from the server in clear text. This non-secret seed allows clients to use the same secret passphrase on multiple machines (using different seeds) and to safely recycle their secret pass-phrases by changing the seed. The result of the concatenation is passed through the secure hash function and then is reduced to 64 bits using one of the function dependent algorithms shown in Appendix A. Computation Step A sequence of one-time passwords is produced by applying the secure hash function multiple times to the output of the initial step (called S). That is, the first one-time password to be used is produced by passing S through the secure hash function a number of times (N) specified by the user. The next one-time password to be used is generated by passing S though the secure hash function N-1 times. An eavesdropper who has monitored the transmission of a one-time password would not be able to generate the next required password because doing so would mean inverting the hash function. Form of Inputs The secret pass-phrase is seen only by the OTP generator. To allow interchangeability of generators, all generators MUST support a secret pass-phrase of 10 to 63 characters. Implementations MAY support a longer pass-phrase, but such implementations risk the loss of interchangeability with implementations supporting only the minimum. The seed MUST consist of purely alphanumeric characters and MUST be of one to 16 characters in length. The seed is a string of characters that MUST not contain any blanks and SHOULD consist of strictly alphanumeric characters from the ISO-646

18

Invariant Code Set. The seed MUST be case insensitive and MUST be internally converted to lower case before it is processed RFC 2289 A One-Time Password System February 1998

The sequence number and seed together constitute a larger unit of data called the challenge. The challenge gives the generator the parameters it needs to calculate the correct one-time password from the secret pass-phrase. The challenge MUST be in a standard syntax so that automated generators can recognize the challenge in context and extract these parameters. The syntax of the challenge is: otp-<algorithm identifier> <sequence integer> <seed> The three tokens MUST be separated by a white space (defined as any number of spaces and/or tabs) and the entire challenge string MUST be terminated with either a space or a new line. The string "otp-" MUST be in lower case. The algorithm identifier is case sensitive (the existing identifiers are all lower case), and the seed is case insensitive and converted before use to lower case. If additional algorithms are defined, appropriate identifiers (short, but not limited to three or four characters) must be defined. The currently defined algorithm identifiers are: md4 md5 sha1 MD4 Message Digest MD5 Message Digest NIST Secure Hash Algorithm Revision 1

An example of an OTP challenge is: otp-md5 487 dog2 Form of Output The one-time password generated by the above procedure is 64 bits in length. Entering a 64 bit number is a difficult and error prone process. Some generators insert this password into the input stream and some others make it available for system "cut and paste." Still other arrangements require the one-time password to be entered manually. The OTP system is designed to facilitate this manual entry without impeding automatic methods. The one-time password therefore 19 may be

converted to, and all servers MUST be capable of accepting it as, a sequence of six short (1 to 4 letter) easily typed words that only use characters from ISO-646 IVCS. Each word is chosen from a dictionary of 2048 words; at 11 bits per word, all onetime passwords may be encoded. The two extra bits in this encoding are used to store a checksum. The 64 bits of key are broken down into pairs of bits, then these pairs are summed together. The two least significant bits of this sum sequence with the least significant bit of the sum as the last bit encoded. All OTP generators MUST calculate this checksum and all OTP servers must verify this checksum explicitly as part of the operation of decoding this representation of the one-time password. RFC 2289 A One-Time Password System February 1998 upper are encoded in the last two bits of the six word

Generators that produce the six-word format MUST present the words in

case with single spaces used as separators. All servers must accept six-word format without regard to case and white space used as a separator. The two lines below represent the same one-time password. The first is valid as output from a generator and as input a server, the second is valid only as human input to a server. OUST COAT FOAL MUG BEAK TOTE oust coat foal mug beak tote Interoperability requires that all OTP servers and generators use the same dictionary. The standard dictionary was originally specified in the "S/KEY One Time Password System" that is described in RFC 1760 [5]. This dictionary is included in this document as Appendix D. To facilitate the implementation of smaller generators, hexadecimal output is an acceptable alternative for the presentation of the one-time password. All implementations of the server software MUST accept case-insensitive hexadecimal as well as six-word format. The hexadecimal digits may be separated by white space so

20

servers are required to ignore all white space. If the representation is partitioned by white space, leading zeros must be retained. Examples of hexadecimal format are: Representation 3503785b369cda8b e5cc a1b8 7c13 096b C7 48 90 F4 27 7B A1 CF 47 9 A68 28 4C 9D 0 1BC Value 0x3503785b369cda8b 0xe5cca1b87c13096b 0xc74890f4277ba1cf 0x479a68284c9d01bc

In addition to accepting six-word and hexadecimal encodings of the 64 bit one-time password, servers should accept the alternate dictionary encoding described in Appendix B. The six words in this encoding MUST not overlap the set of words in the standard dictionary. To avoid ambiguity with the hexadecimal representation,words in the alternate dictionary MUST not be comprised solely of the letters A-F. Decoding words thus encoded does not require an knowledge of the alternative dictionary used so the acceptance of any alternate dictionary implies the acceptance of all alternate dictionaries. Words in the alternative dictionaries are case sensitive. Generators and servers MUST preserve the case in the processing of these words. In summary, all conforming servers MUST accept six-word input that uses the Standard Dictionary (RFC 1760 and Appendix D), must accept hexadecimal encoding, and SHOULD accept six-word input that uses the RFC 2289 A One-Time Password System February 1998

Alternative Dictionary technique (Appendix B). As there is a remote possibility that a hexadecimal encoding of a one-time password will look like a valid six-word standard dictionary encoding, all implementations MUST use the following scheme. If a six-word encoded one-time password is valid, it is accepted. Otherwise, if the one-time password can be interpreted as hexadecimal, and with that decoding it is valid, then it is accepted. 21

VERIFICATION OF ONE-TIME PASSWORDS An application on the server system that requires OTP authentication is expected to issue an OTP challenge as described above. Given the parameters from this challenge and the secret pass-phrase, the generator can compute (or lookup) the one-time password that is passed to the server to be verified. The server system has a database containing, for each user, theone-time password from the last successful authentication or the sequence. To authenticate the user, first OTP of a newly initialized the server decodes the one-time password

received from the generator into a 64-bit key and then runs this key through the secure hash function once. If the result of this operation matches the stored previous OTP, the authentication is successful and the accepted one-time password is stored for future use.

PASS-PHRASE CHANGES
Because the number of hash function applications executed by the unable to authenticate. Although some installations may not permit users to initialize remotely, implementations must provide a means to do so that does not reveal the user's secret pass-phrase. One way is to provide a means to reinitialize the sequence through explicit specification of the first one-time password. When the sequence of one-time passwords is reinitialized, implementations MUST verify that the seed or the pass-phrase is changed. Installations SHOULD discourage any operation that sends the secret pass-phrase over a network in clear-text as such practice defeats the concept of a one-time password. Implementations may use the following technique for [re]initialization generator decreases by one each time, at some point the user must reinitialize the system or be

RFC 2289

A One-Time Password System

February 1998

22

o The user picks a new seed and hash count (default values may be offered). The user provides these, along with the corresponding generated one-time password, to the host system. o The user may also provide the corresponding generated one time password for count-1 as an error check. o The user should provide the generated one-time password for the old seed and old hash count to protect an idle terminal or workstation (this implies that when the count is 1, the user can login but cannot then change the seed or count). In the future a specific protocol may be defined for reinitialization that will permit smooth and possibly automated interoperation of all hosts and generators.

PROTECTION AGAINST RACE ATTACK

All conforming server implementations MUST protect against the race condition described in this section. A defense against this attack is outlined; implementations MAY use this approach or MAY select an alternative defense. It is possible for an attacker to listen to most of a one-time password, guess the remainder, and then race the legitimate user to complete the authentication. Multiple guesses against the last word of the six-word format are likely to succeed. One possible defense is to prevent a user from starting multiple authentication sessions. This means that once the completed. In attack. simultaneous legitimate user has initiated

authentication, an attacker would be blocked until the first authentication process has this approach, a timeout is necessary to thwart a denial of service

SECURITY CONSIDERATIONS
This entire document discusses an authentication system that improves security by limiting the danger of eavesdropping/replay attacks that have been used against simple password systems . The use of the OTP system only provides protections against

passiveeavesdropping/replay attacks.

It does not provide for the privacy of

transmitted data, and it does not provide protection against active attacks such as 23

session hijacking that are known to be present in the current Internet [9]. The use of IP Security(IPsec), see [10], [11], and [12] is recommended to protect against TCP session hijacking. RFC 2289 A One-Time Password System February 1998

The success of the OTP system to protect host systems is dependent on the noninvertability of the secure hash functions used. To our knowledge, none of the hash algorithms have been broken, but it is generally believed [6] that MD4 is not as strong as MD5. If a server supports multiple hash algorithms, it is only as secure as the weakest algorithm

7. Conclusion

24

The S/KEY system has matured in to a viable(feasible=practical) mechanism for generating and authenticating a one- time password. The majority of applications which require entry of the users password are available with S/KEY support but other important ones still remain to be implemented.

8. References

[1] Leslie Lamport, "Password Authentication with Insecure Communication", Communications of the ACM 24.11 (November 1981), 770-772 25

[2] Rivest, R., "The MD4 Message-Digest Algorithm", RFC 1320 April 1992. [3] Neil Haller, "The S/KEY One-Time Password System", Proceedings of the ISOC Symposium on Network and Distributed System Security, February 1994, San Diego, CA [4] Haller, N., and R. Atkinson, "On Internet Authentication", RFC 1704, October 1994. [5] Haller, N., "The S/KEY One-Time Password System", RFC 1760, February 1995. [6] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [7] National Institute of Standards and Technology (NIST), "Announcing the Secure Hash Standard", FIPS 180-1, U.S. Department of Commerce, April 1995. [8] International Standard - Information Processing -- ISO 7-bit coded character set for information interchange (Invariant Code Set), ISO-646, International Standards Organization, Geneva,Switzerland, 1983

26