Network Working Group
`Request for Comments: 2289
`Obsoletes: 1938
`Category: Standards Track
`
`N. Haller
`Bellcore
`C. Metz
`Kaman Sciences Corporation
`P. Nesser
`Nesser & Nesser Consulting
`M. Straw
`Bellcore
`February 1998
`
`Status of this Memo
`
`A One-Time Password System
`
` This document specifies an Internet standards track protocol for the
` Internet community, and requests discussion and suggestions for
` improvements. Please refer to the current edition of the "Internet
` Official Protocol Standards" (STD 1) for the standardization state
` and status of this protocol. Distribution of this memo is unlimited.
`
`Copyright Notice
`
` Copyright (C) The Internet Society (1998). All Rights Reserved.
`
`1.0 ABSTRACT
`
` This document describes a one-time password authentication system
` (OTP). The system provides authentication for system access (login)
` and other applications requiring authentication that is secure
` against passive attacks based on replaying captured reusable
` passwords. OTP evolved from the S/KEY (S/KEY is a trademark of
` Bellcore) One-Time Password System that was released by Bellcore and
` is described in references [3] and [5].
`
`2.0 OVERVIEW
`
` One form of attack on networked computing systems is eavesdropping on
` network connections to obtain authentication information such as the
` login IDs and passwords of legitimate users. Once this 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].
`
` The authentication system described in this document uses a secret
` pass-phrase to generate a sequence of one-time (single use)
` passwords. With this system, the user’s secret pass-phrase never
` needs to cross the network at any time such as during authentication
`
`Haller
`
`Standards Track
`
`[Page 1]
`
`UNIFIED PATENTS EXHIBIT 1011
`Page 1 of 25
`
`JPMORGAN EXHIBIT 1011
`
`

`

`RFC 2289 A One-Time Password System February 1998
`
` or during pass-phrase changes. Thus, it is not vulnerable to replay
` attacks. Added security is provided by the property that no secret
` information need be stored on any system, including the server being
` protected.
`
` The OTP system protects against external passive attacks against the
` authentication subsystem. It does not prevent a network eavesdropper
` from gaining access to private information and does not provide
` protection against either "social engineering" or active attacks [9].
`
`3.0 INTRODUCTION
`
` There are two entities in the operation of the OTP one-time password
` system. The generator must produce the appropriate one-time password
` from the user’s secret pass-phrase and from information provided in
` the challenge from the server. The server must send a challenge that
` includes the appropriate generation parameters to the generator, must
` verify the one-time password received, must store the last valid
` one-time password it received, and must store the corresponding one-
` time password sequence number. The server must also facilitate the
` changing of the user’s secret pass-phrase in a secure manner.
`
` The OTP system generator passes the user’s secret pass-phrase, along
` with a seed received from the server as part of the challenge,
` through multiple iterations of a secure hash function to produce a
` one-time password. After each successful authentication, the number
` of secure hash function iterations is reduced by one. Thus, a unique
` sequence of passwords is generated. The server verifies the one-time
` password received from the generator by computing the secure hash
` function once and comparing the result with the previously accepted
` one-time password. This technique was first suggested by Leslie
` Lamport [1].
`
`4.0 REQUIREMENTS TERMINOLOGY
`
` In this document, the words that are used to define the significance
` of each particular requirement are usually capitalized. These words
` are:
`
` - MUST
`
` This word or the adjective "REQUIRED" means that the item is an
` absolute requirement of the specification.
`
`Haller Standards Track [Page 2]
`
`UNIFIED PATENTS EXHIBIT 1011
`Page 2 of 25
`
`JPMORGAN EXHIBIT 1011
`
`

`

`RFC 2289 A One-Time Password System February 1998
`
` - SHOULD
`
` This word or the adjective "RECOMMENDED" means that there might
` exist valid reasons in particular circumstances to ignore this
` item, but the full implications should be understood and the case
` carefully weighed before taking a different course.
`
` - MAY
`
` This word or the adjective "OPTIONAL" means that this item is
` truly optional. One vendor might choose to include the item
` because a particular marketplace requires it or because it
` enhances the product, for example; another vendor may omit the
` same item.
`
`5.0 SECURE HASH FUNCTION
`
` The security of the OTP system is based on the non-invertability of a
` secure hash function. Such a function must be tractable to compute in
` the forward direction, but computationally infeasible to invert.
`
` The interfaces are currently defined for three such hash algorithms,
` MD4 [2] and MD5 [6] by Ronald Rivest, and SHA [7] by NIST. All
` conforming implementations of both server and generators MUST support
` MD5. They SHOULD support SHA and MAY also support MD4. Clearly, the
` generator and server must use the same algorithm in order to
` interoperate. Other hash algorithms may be specified for use with
` this system by publishing the appropriate interfaces.
`
` The secure hash algorithms listed above have the property that they
` accept an input that is arbitrarily long and produce a fixed size
` output. The OTP system folds this output to 64 bits using the
` algorithms in the Appendix A. 64 bits is also the length of the one-
` time passwords. This is believed to be long enough to be secure and
` short enough to be entered manually (see below, Form of Output) when
` necessary.
`
`6.0 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 are
` combined, a computation step where the secure hash function is
` applied a specified number of times, and an output function where the
` 64 bit one-time password is converted to a human readable form.
`
` Appendix C contains examples of the outputs given a collection of
` inputs. It provides implementors with a means of verification the
` use of these algorithms.
`
`Haller Standards Track [Page 3]
`
`UNIFIED PATENTS EXHIBIT 1011
`Page 3 of 25
`
`JPMORGAN EXHIBIT 1011
`
`

`

`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 pass-phrases MUST contain at
` least 10 characters (see Form of Inputs below). All implementations
` MUST support a pass-phrases of at least 63 characters. The secret
` 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 pass-phrase 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 Invariant Code Set. The
` seed MUST be case insensitive and MUST be internally converted to
` lower case before it is processed.
`
`Haller Standards Track [Page 4]
`
`UNIFIED PATENTS EXHIBIT 1011
`Page 4 of 25
`
`JPMORGAN EXHIBIT 1011
`
`

`

`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 MD4 Message Digest
` md5 MD5 Message Digest
` sha1 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
` 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 one-time 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
` 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 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.
`
`Haller Standards Track [Page 5]
`
`UNIFIED PATENTS EXHIBIT 1011
`Page 5 of 25
`
`JPMORGAN EXHIBIT 1011
`
`

`

`RFC 2289 A One-Time Password System February 1998
`
` Generators that produce the six-word format MUST present the words in
` upper 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 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 Value
`
` 3503785b369cda8b 0x3503785b369cda8b
` e5cc a1b8 7c13 096b 0xe5cca1b87c13096b
` C7 48 90 F4 27 7B A1 CF 0xc74890f4277ba1cf
` 47 9 A68 28 4C 9D 0 1BC 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 any
` 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
`
`Haller Standards Track [Page 6]
`
`UNIFIED PATENTS EXHIBIT 1011
`Page 6 of 25
`
`JPMORGAN EXHIBIT 1011
`
`

`

`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.
`
`7.0 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, the
` one-time password from the last successful authentication or the
` first OTP of a newly initialized sequence. To authenticate the user,
` 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.
`
`8.0 PASS-PHRASE CHANGES
`
` Because the number of hash function applications executed by the
` generator decreases by one each time, at some point the user must
` reinitialize the system or be 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:
`
`Haller Standards Track [Page 7]
`
`UNIFIED PATENTS EXHIBIT 1011
`Page 7 of 25
`
`JPMORGAN EXHIBIT 1011
`
`

`

`RFC 2289 A One-Time Password System February 1998
`
` 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.
`
`9.0 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
` simultaneous authentication sessions. This means that once the
` legitimate user has initiated authentication, an attacker would be
` blocked until the first authentication process has completed. In
` this approach, a timeout is necessary to thwart a denial of service
` attack.
`
`10.0 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 [4].
`
` The use of the OTP system only provides protections against passive
` eavesdropping/replay attacks. It does not provide for the privacy
` of transmitted data, and it does not provide protection against
` active attacks such as 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.
`
`Haller Standards Track [Page 8]
`
`UNIFIED PATENTS EXHIBIT 1011
`Page 8 of 25
`
`JPMORGAN EXHIBIT 1011
`
`

`

`RFC 2289 A One-Time Password System February 1998
`
` The success of the OTP system to protect host systems is dependent
` on the non-invertability 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.
`
`11.0 ACKNOWLEDGMENTS
`
` The idea behind OTP authentication was first proposed by Leslie
` 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
` implementation.
`
`12.0 REFERENCES
`
` [1] Leslie Lamport, "Password Authentication with Insecure
` Communication", Communications of the ACM 24.11 (November
` 1981), 770-772
`
` [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
`
`Haller Standards Track [Page 9]
`
`UNIFIED PATENTS EXHIBIT 1011
`Page 9 of 25
`
`JPMORGAN EXHIBIT 1011
`
`

`

`RFC 2289 A One-Time Password System February 1998
`
` [9] Computer Emergency Response Team (CERT), "IP Spoofing and
` Hijacked Terminal Connections", CA-95:01, January 1995.
` Available via anonymous ftp from info.cert.org in
` /pub/cert_advisories.
`
` [10] Atkinson, R., "Security Architecture for the Internet Protocol",
` RFC 1825, August 1995.
`
` [11] Atkinson, R., "IP Authentication Header", RFC 1826, August
` 1995.
`
` [12] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC
` 1827, August 1995.
`
`Haller Standards Track [Page 10]
`
`UNIFIED PATENTS EXHIBIT 1011
`Page 10 of 25
`
`JPMORGAN EXHIBIT 1011
`
`

`

`RFC 2289 A One-Time Password System February 1998
`
`13.0 AUTHORS’ ADDRESSES
`
` Neil Haller
` Bellcore
` MCC 1C-265B
` 445 South Street
` Morristown, NJ, 07960-6438, USA
`
` Phone: +1 201 829-4478
` Fax: +1 201 829-2504
` EMail: nmh@bellcore.com
`
` Craig Metz
` Kaman Sciences Corporation
` For NRL Code 5544
` 4555 Overlook Avenue, S.W.
` Washington, DC, 20375-5337, USA
`
` Phone: +1 202 404-7122
` Fax: +1 202 404-7942
` EMail: cmetz@cs.nrl.navy.mil
`
` Philip J. Nesser II
` Nesser & Nesser Consulting
` 13501 100th Ave NE
` Suite 5202
` Kirkland, WA 98034, USA
`
` Phone: +1 206 481 4303
` EMail: pjnesser@martigny.ai.mit.edu
`
` Mike Straw
` Bellcore
` RRC 1A-225
` 445 Hoes Lane
` Piscataway, NJ 08854-4182
`
` Phone: +1 908 699-5212
` EMail: mess@bellcore.com
`
`Haller Standards Track [Page 11]
`
`UNIFIED PATENTS EXHIBIT 1011
`Page 11 of 25
`
`JPMORGAN EXHIBIT 1011
`
`

`

`RFC 2289 A One-Time Password System February 1998
`
`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 byte first, while a little endian
` machine stores the least significant byte 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_CTX md;
` unsigned char result[16];
`
` strcpy(buf, seed); /* seed must be in lower case */
` strcat(buf, passwd);
` 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];
`
`Haller Standards Track [Page 12]
`
`UNIFIED PATENTS EXHIBIT 1011
`Page 12 of 25
`
`JPMORGAN EXHIBIT 1011
`
`

`

`RFC 2289 A One-Time Password System February 1998
`
`MD5 Message Digest (see reference [6])
`
` 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);
`
` /* Fold the 128 bit result to 64 bits */
` for (i = 0; i < 8; i++)
` result[i] ^= result[i+8];
`
`SHA Secure Hash Algorithm (see reference [7])
`
` SHA_INFO sha;
` unsigned char result[16];
` 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 */
`
` /* 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];
`
` /*
` * copy the resulting 64 bits to the result buffer in little endian
` * fashion (analogous to the way MD4Final() and MD5Final() do).
` */
` 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);
` }
`
`Haller Standards Track [Page 13]
`
`UNIFIED PATENTS EXHIBIT 1011
`Page 13 of 25
`
`JPMORGAN EXHIBIT 1011
`
`

`

`RFC 2289 A One-Time Password System February 1998
`
`Appendix B - Alternative Dictionary Algorithm
`
` The purpose of alternative dictionary encoding of the OTP one-time
` password is to allow the use of language specific or friendly words.
` As case translation is not always well defined, the alternative
` dictionary encoding is case sensitive. Servers SHOULD accept this
` encoding in addition to the standard 6-word and hexadecimal
` encodings.
`
` GENERATOR ENCODING USING AN ALTERNATE DICTIONARY
`
` The standard 6-word encoding uses the placement of a word in the
` dictionary to represent an 11-bit number. The 64-bit one-time
` password can then be represented by six words.
`
` An alternative dictionary of 2048 words may be created such that
` each word W and position of the word in the dictionary N obey the
` relationship:
`
` alg( W ) % 2048 == N
` where
` alg is the hash algorithm used (e.g. MD4, MD5, SHA1).
`
` In addition, no words in the standard dictionary may be chosen.
`
` The generator expands the 64-bit one-time password to 66 bits by
` computing parity as with the standard 6-word encoding. The six 11-
` bit numbers are then converted to words using the dictionary that
` was created such that the above relationship holds.
`
` SERVER DECODING OF ALTERNATE DICTIONARY ONE-TIME PASSWORDS
`
` The server accepting alternative dictionary encoding converts each
` word to an 11-bit number using the above encoding. These numbers
` are then used in the same way as the decoded standard dictionary
` words to form the 66-bit one-time password.
`
` The server does not need to have access to the alternate dictionary
` that was used to create the one-time password it is authenticating.
` This is because the decoding from word to 11-bit number does not
` make any use of the dictionary. As a result of the independence of
` the dictionary, a server accepting one alternate dictionary accept
` all alternate dictionaries.
`
`Haller Standards Track [Page 14]
`
`UNIFIED PATENTS EXHIBIT 1011
`Page 14 of 25
`
`JPMORGAN EXHIBIT 1011
`
`

`

`RFC 2289 A One-Time Password System February 1998
`
`Appendix C - OTP Verification Examples
`
` This appendix provides a series of inputs and correct outputs for all
` three of the defined OTP cryptographic hashes, specifically MD4, MD5,
` and SHA1. This document is intended to be used by developers for
` interoperability checks when creating generators or servers. Output
` is provided in both hexadecimal notation and the six word encoding
` documented in Appendix D.
`
` GENERAL CHECKS
`
` Note that the output given for these checks is not intended to be
` taken literally, but describes the type of action that should be
` taken.
`
` Pass Phrase Length
`
` Input:
` Pass Phrase: Too_short
` Seed: iamvalid
` Count: 99
` Hash: ANY
` Output:
` ERROR: Pass Phrase too short
`
` Input:
` Pass Phrase:
` 1234567890123456789012345678901234567890123456789012345678901234
` Seed: iamvalid
` Count: 99
` Hash: ANY
` Output:
` WARNING: Pass Phrase longer than the recommended maximum length of
`63
`
`Seed Values
`
` Input:
` Pass Phrase: A_Valid_Pass_Phrase
` Seed: Length_Okay
` Count: 99
` Hash: ANY
` Output:
` ERROR: Seed must be purely alphanumeric
`
` Input:
` Pass Phrase: A_Valid_Pass_Phrase
` Seed: LengthOfSeventeen
`
`Haller Standards Track [Page 15]
`
`UNIFIED PATENTS EXHIBIT 1011
`Page 15 of 25
`
`JPMORGAN EXHIBIT 1011
`
`

`

`RFC 2289 A One-Time Password System February 1998
`
` Count: 99
` Hash: ANY
`
` Output:
` ERROR: Seed must be between 1 and 16 characters in length
`
` Input:
` Pass Phrase: A_Valid_Pass_Phrase
` Seed: A Seed
` Count: 99
` Hash: ANY
` Output:
` ERROR: Seed must not contain any spaces
`
`Parity Calculations
`
` Input:
` Pass Phrase: A_Valid_Pass_Phrase
` Seed: AValidSeed
` Count: 99
` Hash: MD5
` Output:
` Hex: 85c43ee03857765b
` Six Word(CORRECT): FOWL KID MASH DEAD DUAL OAF
` Six Word(INCORRECT PARITY): FOWL KID MASH DEAD DUAL NUT
` Six Word(INCORRECT PARITY): FOWL KID MASH DEAD DUAL O
` Six Word(INCORRECT PARITY): FOWL KID MASH DEAD DUAL OAK
`
`Haller Standards Track [Page 16]
`
`UNIFIED PATENTS EXHIBIT 1011
`Page 16 of 25
`
`JPMORGAN EXHIBIT 1011
`
`

`

`RFC 2289 A One-Time Password System February 1998
`
`MD4 ENCODINGS
`
`Pass Phrase Seed Cnt Hex Six Word Format
`========================================================================
`This is a test. TeSt 0 D185 4218 EBBB 0B51
` ROME MUG FRED SCAN LIVE LACE
`This is a test. TeSt 1 6347 3EF0 1CD0 B444
` CARD SAD MINI RYE COL KIN
`This is a test. TeSt 99 C5E6 1277 6E6C 237A
` NOTE OUT IBIS SINK NAVE MODE
`AbCdEfGhIjK alpha1 0 5007 6F47 EB1A DE4E
`