< draft-ietf-otp-00.txt   draft-ietf-otp-01.txt >
INTERNET DRAFT Neil Haller INTERNET DRAFT Neil Haller
draft-ietf-otp-00.txt Bellcore draft-ietf-otp-01.txt Bellcore
February 1, 1997 Craig Metz March 24, 1997 Craig Metz
Kaman Sciences Corporation Kaman Sciences Corporation
Philip Nesser Philip Nesser
Nesser & Nesser Consulting Nesser & Nesser Consulting
Mike Straw
Bellcore
A One-Time Password System A One-Time Password System
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet Draft. Internet Drafts are working This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas documents of the Internet Engineering Task Force (IETF), its Areas
and Working Groups. Note that other groups may also distribute and Working Groups. Note that other groups may also distribute
working documents as Internet Drafts. working documents as Internet Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 33
as reference material or to cite them other than as a "working as reference material or to cite them other than as a "working
draft" or "work in progress." draft" or "work in progress."
To learn the current status of any Internet Draft, please check the To learn the current status of any Internet Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow 1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ds.internic.net (US East Directories on ftp.is.co.za (Africa), ds.internic.net (US East
Coast), nic.nordu.net (Europe), ftp.isi.com (US West Coast), or Coast), nic.nordu.net (Europe), ftp.isi.com (US West Coast), or
munnari.oz.au (Pacific Rim). munnari.oz.au (Pacific Rim).
The distribution of this Internet Draft is unlimited. It is filed as The distribution of this Internet Draft is unlimited. It is filed as
<draft-ietf-otp-00.txt> and it expires on August 1, 1997. <draft-ietf-otp-01.txt> and it expires on October 1, 1997.
1.0 ABSTRACT 1.0 ABSTRACT
This document describes a one-time password authentication system This document describes a one-time password authentication system
(OTP). The system provides authentication for system access (login) (OTP). The system provides authentication for system access (login)
and other applications requiring authentication that is secure and other applications requiring authentication that is secure
against passive attacks based on replaying captured reusable against passive attacks based on replaying captured reusable
passwords. OTP evolved from the S/KEY* One-Time Password System that passwords. OTP evolved from the S/KEY* One-Time Password System that
was released by Bellcore and is described in references [3] and [5]. was released by Bellcore and is described in references [3] and [5].
2.0 OVERVIEW 2.0 OVERVIEW
One form of attack on networked computing systems is eavesdropping One form of attack on networked computing systems is eavesdropping
on network connections to obtain authentication information such as on network connections to obtain authentication information such as
the login IDs and passwords of legitimate users. Once this the login IDs and passwords of legitimate users. Once this
information is captured, it can be used at a later time to gain information is captured, it can be used at a later time to gain
access to the system. One-time password systems are designed to
counter this type of attack, called a "replay attack" [4].
--------- ---------
* S/KEY is a trademark of Bellcore * S/KEY is a trademark of Bellcore
to the system. One-time password systems are designed to counter
this type of attack, called a "replay attack" [4].
The authentication system described in this document uses a secret The authentication system described in this document uses a secret
pass-phrase to generate a sequence of one-time (single use) pass-phrase to generate a sequence of one-time (single use)
passwords. With this system, the user's secret pass-phrase never passwords. With this system, the user's secret pass-phrase never
needs to cross the network at any time such as during authentication needs to cross the network at any time such as during authentication
or during pass-phrase changes. Thus, it is not vulnerable to replay or during pass-phrase changes. Thus, it is not vulnerable to replay
attacks. Added security is provided by the property that no secret attacks. Added security is provided by the property that no secret
information need be stored on any system, including the server being information need be stored on any system, including the server being
protected. protected.
The OTP system protects against external passive attacks against the The OTP system protects against external passive attacks against the
skipping to change at page 2, line 52 skipping to change at page 3, line 4
4.0 REQUIREMENTS TERMINOLOGY 4.0 REQUIREMENTS TERMINOLOGY
In this document, the words that are used to define the significance In this document, the words that are used to define the significance
of each particular requirement are usually capitalized. These words of each particular requirement are usually capitalized. These words
are: are:
- MUST - MUST
This word or the adjective "REQUIRED" means that the item is an This word or the adjective "REQUIRED" means that the item is an
absolute requirement of the specification. requirement of the specification.
- SHOULD - SHOULD
This word or the adjective "RECOMMENDED" means that there might This word or the adjective "RECOMMENDED" means that there might
exist valid reasons in particular circumstances to ignore this exist valid reasons in particular circumstances to ignore this
item, but the full implications should be understood and the item, but the full implications should be understood and the
case carefully weighed before taking a different course. case carefully weighed before taking a different course.
- MAY - MAY
skipping to change at page 3, line 52 skipping to change at page 4, line 4
6.0 GENERATION OF ONE-TIME PASSWORDS 6.0 GENERATION OF ONE-TIME PASSWORDS
This section describes the generation of the one-time passwords. This section describes the generation of the one-time passwords.
This process consists of an initial step in which all inputs are This process consists of an initial step in which all inputs are
combined, a computation step where the secure hash function is combined, a computation step where the secure hash function is
applied a specified number of times, and an output function where applied a specified number of times, and an output function where
the 64 bit one-time password is converted to a human readable form. the 64 bit one-time password is converted to a human readable form.
Appendix C contains examples of the outputs given a collection of Appendix C contains examples of the outputs given a collection of
inputs. It provides implementors with a means of verification the inputs. It provides implementors with a means of verification the
use of these algorithms. of these algorithms.
Initial Step Initial Step
In principle, the user's secret pass-phrase may be of any length. To In principle, the user's secret pass-phrase may be of any length. To
reduce the risk from techniques such as exhaustive search or reduce the risk from techniques such as exhaustive search or
dictionary attacks, character string pass-phrases MUST contain at dictionary attacks, character string pass-phrases MUST contain at
least 10 characters (see Form of Inputs below). All implementations least 10 characters (see Form of Inputs below). All implementations
MUST support a pass-phrases of at least 63 characters. The secret MUST support a pass-phrases of at least 63 characters. The secret
pass-phrase is frequently, but is not required to be, textual pass-phrase is frequently, but is not required to be, textual
information provided by a user. information provided by a user.
In this step, the pass phrase is concatenated with a seed that is In this step, the pass phrase is concatenated with a seed that is
transmitted from the server in clear text. This non-secret seed transmitted from the server in clear text. This non-secret seed
skipping to change at page 4, line 51 skipping to change at page 5, line 4
minimum. minimum.
The seed MUST consist of purely alphanumeric characters and MUST be The seed MUST consist of purely alphanumeric characters and MUST be
of one to 16 characters in length. The seed is a string of of one to 16 characters in length. The seed is a string of
characters that MUST not contain any blanks and SHOULD consist of characters that MUST not contain any blanks and SHOULD consist of
strictly alphanumeric characters from the ISO-646 Invariant Code strictly alphanumeric characters from the ISO-646 Invariant Code
Set. The seed MUST be case insensitive and MUST be internally Set. The seed MUST be case insensitive and MUST be internally
converted to lower case before it is processed. converted to lower case before it is processed.
The sequence number and seed together constitute a larger unit of The sequence number and seed together constitute a larger unit of
data called the challenge. The challenge gives the generator the called the challenge. The challenge gives the generator the
parameters it needs to calculate the correct one-time password from parameters it needs to calculate the correct one-time password from
the secret pass-phrase. The challenge MUST be in a standard syntax the secret pass-phrase. The challenge MUST be in a standard syntax
so that automated generators can recognize the challenge in context so that automated generators can recognize the challenge in context
and extract these parameters. The syntax of the challenge is: and extract these parameters. The syntax of the challenge is:
otp-<algorithm identifier> <sequence integer> <seed> otp-<algorithm identifier> <sequence integer> <seed>
The three tokens MUST be separated by a white space (defined as any 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 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-" be terminated with either a space or a new line. The string "otp-"
skipping to change at page 5, line 51 skipping to change at page 6, line 4
pairs are summed together. The two least significant bits of this pairs are summed together. The two least significant bits of this
sum are encoded in the last two bits of the six word sequence with sum are encoded in the last two bits of the six word sequence with
the least significant bit of the sum as the last bit encoded. All the least significant bit of the sum as the last bit encoded. All
OTP generators MUST calculate this checksum and all OTP servers OTP generators MUST calculate this checksum and all OTP servers
MUST verify this checksum explicitly as part of the operation of MUST verify this checksum explicitly as part of the operation of
decoding this representation of the one-time password. decoding this representation of the one-time password.
Generators that produce the six-word format MUST present the words Generators that produce the six-word format MUST present the words
in upper case with single spaces used as separators. All servers in upper case with single spaces used as separators. All servers
MUST accept six-word format without regard to case and white space MUST accept six-word format without regard to case and white space
used as a separator. The two lines below represent the same one- as a separator. The two lines below represent the same one-time
time password. The first is valid as output from a generator and password. The first is valid as output from a generator and as
as input a server, the second is valid only as human input to a input a server, the second is valid only as human input to a
server. server.
OUST COAT FOAL MUG BEAK TOTE OUST COAT FOAL MUG BEAK TOTE
oust coat foal mug beak tote oust coat foal mug beak tote
Interoperability requires that all OTP servers and generators use Interoperability requires that all OTP servers and generators use
the same dictionary. The standard dictionary was originally the same dictionary. The standard dictionary was originally
specified in the "S/KEY One Time Password System" that is specified in the "S/KEY One Time Password System" that is
described in RFC 1760 [5]. This dictionary is included in this described in RFC 1760 [5]. This dictionary is included in this
document as Appendix D. document as Appendix D.
skipping to change at page 6, line 51 skipping to change at page 7, line 4
processing of these words. processing of these words.
In summary, all conforming servers MUST accept six-word input that In summary, all conforming servers MUST accept six-word input that
uses the Standard Dictionary (RFC 1760 and Appendix D), MUST accept uses the Standard Dictionary (RFC 1760 and Appendix D), MUST accept
hexadecimal encoding, and SHOULD accept six-word input that uses the hexadecimal encoding, and SHOULD accept six-word input that uses the
Alternative Dictionary technique (Appendix B). As there is a remote Alternative Dictionary technique (Appendix B). As there is a remote
possibility that a hexadecimal encoding of a one-time password will possibility that a hexadecimal encoding of a one-time password will
look like a valid six-word standard dictionary encoding, all look like a valid six-word standard dictionary encoding, all
implementations MUST use the following scheme. If a six-word implementations MUST use the following scheme. If a six-word
encoded one-time password is valid, it is accepted. Otherwise, if encoded one-time password is valid, it is accepted. Otherwise, if
the one-time password can be interpreted as hexadecimal, and with one-time password can be interpreted as hexadecimal, and with that
that decoding it is valid, then it is accepted. decoding it is valid, then it is accepted.
7.0 VERIFICATION OF ONE-TIME PASSWORDS 7.0 VERIFICATION OF ONE-TIME PASSWORDS
An application on the server system that requires OTP authentication An application on the server system that requires OTP authentication
is expected to issue an OTP challenge as described above. Given the is expected to issue an OTP challenge as described above. Given the
parameters from this challenge and the secret pass-phrase, the parameters from this challenge and the secret pass-phrase, the
generator can compute (or lookup) the one-time password that is generator can compute (or lookup) the one-time password that is
passed to the server to be verified. passed to the server to be verified.
The server system has a database containing, for each user, the The server system has a database containing, for each user, the
one-time password from the last successful authentication or the one-time password from the last successful authentication or the
first OTP of a newly initialized sequence. To authenticate the user, first OTP of a newly initialized sequence. To authenticate the user,
the server decodes the one-time password received from the generator the server decodes the one-time password received from the generator
skipping to change at page 8, line 50 skipping to change at page 9, line 4
knowledge, none of the hash algorithms have been broken, but it is 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 generally believed [6] that MD4 is not as strong as MD5. If a
server supports multiple hash algorithms, it is only as secure as server supports multiple hash algorithms, it is only as secure as
the weakest algorithm. the weakest algorithm.
11.0 ACKNOWLEDGMENTS 11.0 ACKNOWLEDGMENTS
The idea behind OTP authentication was first proposed by Leslie The idea behind OTP authentication was first proposed by Leslie
Lamport [1]. Bellcore's S/KEY system, from which OTP is derived, was Lamport [1]. Bellcore's S/KEY system, from which OTP is derived, was
proposed by Phil Karn, who also wrote most of the Bellcore reference proposed by Phil Karn, who also wrote most of the Bellcore reference
implementation.
12.0 REFERENCES 12.0 REFERENCES
[1] Leslie Lamport, "Password Authentication with Insecure [1] Leslie Lamport, "Password Authentication with Insecure
Communication", Communications of the ACM 24.11 (November Communication", Communications of the ACM 24.11 (November
1981), 770-772 1981), 770-772
[2] R. L. Rivest, The MD4 Message-Digest Algorithm, "Request For [2] R. L. Rivest, The MD4 Message-Digest Algorithm, "Request For
Comments (RFC) 1320", MIT and RSA Data Security, Inc., April Comments (RFC) 1320", MIT and RSA Data Security, Inc., April
1992 1992
skipping to change at page 10, line 26 skipping to change at page 10, line 31
Washington, DC, 20375-5337, USA Washington, DC, 20375-5337, USA
Phone: +1 202 404-7122 Phone: +1 202 404-7122
Fax: +1 202 404-7942 Fax: +1 202 404-7942
Email: cmetz@cs.nrl.navy.mil Email: cmetz@cs.nrl.navy.mil
Philip J. Nesser II Philip J. Nesser II
Nesser & Nesser Consulting Nesser & Nesser Consulting
13501 100th Ave NE 13501 100th Ave NE
Suite 5202 Suite 5202
Kirkland, WA 98034 Kirkland, WA 98034, USA
Phone: +1 206 481 4303 Phone: +1 206 481 4303
Email: pjnesser@martigny.ai.mit.edu Email: pjnesser@martigny.ai.mit.edu
Appendix A - Interfaces to Secure Hash Algorithms
Mike Straw
Bellcore
RRC 1A-225
445 Hoes Lane
Piscataway, NJ 08854-4182
Phone: +1 908 699-5212
Email: mess@bellcore.com
Appendix A - Interfaces to Secure Hash Algorithms
Original interoperability tests provided valuable insights into the
subtle problems which occur when converting protocol specifications
into running code. In particular, the manipulation of bit ordered
data is dependent on the architecture of the hardware, specifically
the way in which a computer stores multi-byte data. The method is
typically called big or little "endian." A big endian machine stores
data with the most significant bit (msb) first, while a little endian
machine stores the least significant bit (lsb) first. Thus, on a big
endian machine data is stored left to right, while little endian
machines store data right to left.
For example, the four byte value 0x11AABBCC is stored in a big endian
machine as the following series of four bytes, "0x11", "0xAA", "0xBB",
and "0xCC", while on a little endian machine the value would be stored
as "0xCC", "0xBB", "0xAA", and "0x11".
For historical reasons, and to promote interoperability with existing
implementations, it was decided that ALL hashes incorporated into the
OTP protocol MUST store the output of their hash function in LITTLE
ENDIAN format BEFORE the bit folding to 64 bits occurs. This is done
in the implementations of MD4 and MD5 (see references [2] and [6]),
while it must be explicitly done for the implementation of SHA1 (see
reference [7]).
Any future hash functions implemented into the OTP protocol SHOULD
provide a similar reference fragment of code to allow independent
implementations to operate successfully.
MD4 Message Digest (see reference [2]) MD4 Message Digest (see reference [2])
strcpy(buf,seed); MD4_CTX md;
strcat(buf,passwd); unsigned char result[16];
MDbegin(&md)
MDupdate(&md,(unsigned char *)buf,8*buflen);
/* Fold result to 64 bits */ strcpy(buf, seed); /* seed must be in lower case */
md.buffer[0] ^= md.buffer[2]; strcat(buf, passwd);
md.buffer[1] ^= md.buffer[3]; MD4Init(&md);
MD4Update(&md, (unsigned char *)buf, strlen(buf));
MD4Final(result, &md);
/* Fold the 128 bit result to 64 bits */
for (i = 0; i < 8; i++)
result[i] ^= result[i+8];
MD5 Message Digest (see reference [6]) MD5 Message Digest (see reference [6])
MD5_CTX mdCxt; MD5_CTX md;
unsigned char result[16];
strcpy(buf, seed); /* seed must be in lower case */
strcat(buf, passwd);
MD5Init(&md);
MD5Update(&md, (unsigned char *)buf, strlen(buf));
MD5Final(result, &md);
strcpy(buf,seed); /* Fold the 128 bit result to 64 bits */
strcat(buf,passwd); for (i = 0; i < 8; i++)
result[i] ^= result[i+8];
/* Crunch the key through MD5 */ SHA Secure Hash Algorithm (see reference [7])
MD5Init(&mdCxt);
MD5Update(&mdCxt,(unsigned char *)buf,buflen);
MD5Final(&mdCxt);
/* Fold result to 64 bits */ SHA_INFO sha;
for( i = 0; i < 8; i++ ) unsigned char result[16];
result[i] = mdCxt.digest[i] ^ mdCxt.digest[i+8]; strcpy(buf, seed); /* seed must be in lower case */
strcat(buf, passwd);
sha_init(&sha);
sha_update(&sha, (unsigned char *)buf, strlen(buf));
sha_final(&sha); /* NOTE: no result buffer */
SHA Secure Hash Algorithm (see reference [7]) /* Fold the 160 bit result to 64 bits */
sha.digest[0] ^= sha.digest[2];
sha.digest[1] ^= sha.digest[3];
sha.digest[0] ^= sha.digest[4];
/* Fold 160 bit result to 64 bits */ /*
md.buffer[0] ^= md.buffer[2]; * copy the resulting 64 bits to the result buffer in little endian
md.buffer[1] ^= md.buffer[3]; * fashion (analogous to the way MD4Final() and MD5Final() do).
md.buffer[0] ^= md.buffer[4]; */
for (i = 0, j = 0; j < 8; i++, j += 4)
{
result[j] = (unsigned char)(sha.digest[i] & 0xff);
result[j+1] = (unsigned char)((sha.digest[i] >> 8) & 0xff);
result[j+2] = (unsigned char)((sha.digest[i] >> 16) & 0xff);
result[j+3] = (unsigned char)((sha.digest[i] >> 24) & 0xff);
}
Appendix B - Alternative Dictionary Algorithm Appendix B - Alternative Dictionary Algorithm
The purpose of alternative dictionary encoding of the OTP one-time The purpose of alternative dictionary encoding of the OTP one-time
password is to allow the use of language specific or friendly words. password is to allow the use of language specific or friendly words.
As case translation is not always well defined, the alternative As case translation is not always well defined, the alternative
dictionary encoding is case sensitive. Servers SHOULD accept this dictionary encoding is case sensitive. Servers SHOULD accept this
encoding in addition to the standard 6-word and hexadecimal encodings. encoding in addition to the standard 6-word and hexadecimal encodings.
GENERATOR ENCODING USING AN ALTERNATE DICTIONARY GENERATOR ENCODING USING AN ALTERNATE DICTIONARY
 End of changes. 24 change blocks. 
39 lines changed or deleted 101 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/