draft-nesser-otp-sha-256-384-512

Network Working Group                                  P. J. Nesser II
draft-nesser-otp-sha-256-384-512-02.txt     Nesser & Nesser Consulting
Category: Standards Track                                     May 2003


		     Generating One-Time Passwords with 
			SHA-256, SHA-384, and SHA-512

Status of this Memo

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note that
other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/1id-abstracts.html

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.






1.0 ABSTRACT


This document describes the use of the new AES hash alogrithms,
SHA-256, SHA-384 and SHA-512, for use with the One Time Password
(OTP) system, as defined by RFC 2289.  RFC 2289 has definitions
for the MD4, MD5 and SHA1 hashes, while this document defines
techniques for using the AES hashes.

2.0 OVERVIEW

The OTP protocol defines a widely deployed method of creating
chains of one-time passwords.  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.

Each one-time password is a 64-bit value calculated from the
output of one of three defined hash functions.  RFC 2289
specifies that all OTP implementations MUST implement the MD5
hash, SHOULD implement the SHA1 hash, and MAY implement the MD4
hash.  MD4 and MD5 each produce 128-bit output and SHA1 produces
160-bit output.

RFC 2289 defines methods for reducing the output of those hashes
to 64-bits.  This documument defines methods for reducing the
output of SHA-256, SHA-384 and SHA-512 into 64-bit blocks for use
in OTP.

Although the SHA-256, SHA-384 and SHA-512 alogrithms are still in their
introductory state, the length of their outputs are set and will not
change.  


3.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.

     - 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.


4.0 Implementation Requirements

OTP systems MAY implement the SHA-256, SHA-384, or SHA-512 hashes.


5.0 Server Challenges

The syntax of the challenge issued by the OTP server to the
client is:

    otp-<algorithm identifier> <sequence integer> <seed>

The currently defined (RFC 2289) algorithm identifiers are:

       md4        MD4 Message Digest
       md5        MD5 Message Digest
       sha1       NIST Secure Hash Algorithm Revision 1

The following new algorithm identifiers are defined

	 sha256	NIST Secure Hash Algorithm 256-bit output
	 sha384	NIST Secure Hash Algorithm 384-bit output
	 sha512	NIST Secure Hash Algorithm 512-bit output


6.0  Interfaces to Secure Hash Algorithms


SHA-256 Secure Hash Algorithm

     SHA256_INFO sha;
     unsigned char result[16];
     strcpy(buf, seed);
     strcat(buf, passwd);
     sha_init(&sha);
     sha_update(&sha, (unsigned char *)buf, strlen(buf));
     sha_final(&sha);

     /* Fold the 256 bit result to 64 bits */
     for (i = 1; i < 4; i++) {
             sha.digest[0] ^= sha.digest[2 * i];
             sha.digest[1] ^= sha.digest[(2 * i) + 1];
     }

SHA-384 Secure Hash Algorithm

     SHA384_INFO sha;
     unsigned char result[16];
     strcpy(buf, seed);
     strcat(buf, passwd);
     sha_init(&sha);
     sha_update(&sha, (unsigned char *)buf, strlen(buf));
     sha_final(&sha);

     /* Fold the 384 bit result to 64 bits */
     for (i = 1; i < 6; i++) {
             sha.digest[0] ^= sha.digest[2 * i];
             sha.digest[1] ^= sha.digest[(2 * i) + 1];
     }


SHA-512 Secure Hash Algorithm

     SHA512_INFO sha;
     unsigned char result[16];
     strcpy(buf, seed);
     strcat(buf, passwd);
     sha_init(&sha);
     sha_update(&sha, (unsigned char *)buf, strlen(buf));
     sha_final(&sha);

     /* Fold the 512 bit result to 64 bits */
     for (i = 1; i < 8; i++) {
             sha.digest[0] ^= sha.digest[2 * i];
             sha.digest[1] ^= sha.digest[(2 * i) + 1];
     }


7.0  Bit Ordering

Any implementation of these extended hashes to the OTP protocol should take
note of Appendix A of RFC 2289.  A relevent fragment is presented here:

>From RFC 2289

   "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."

It is the implementors responsibility to check their hash function
implementation to ensure compatibility.

8.0  Neccessity of Implementation

As of this writing there is no apparent or pressing reason to upgrade the
hash algorithms used in current OTP implementations.  On the other hand,
there will be certain organizations who desire to move all of their
cryptographics software to conform to new US Government standards.


9.0 SECURITY CONSIDERATIONS

This document describes the additional use of three new hashes for use in
the OTP system.  The OTP system is widely utilized and trusted on the
Internet.  Use of a new hash system which might have some yet undiscovered
flaw could expose or compromise the security of these systems.


11.0 ACKNOWLEDGMENTS


12.0 REFERENCES

[FIPS 180-2]  Secure Hash Standard:  A Revision of FIPS 180-1, August 2002

13.0 AUTHORS' ADDRESSES

   Philip J. Nesser II
   Nesser & Nesser Consulting
   13501 100th Ave NE
   Suite 5202
   Kirkland, WA 98034, USA

   Phone: +1 425 481 4303
   EMail: phil@nesser.com