rfc2289.txt

radius服务器

   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]

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]

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]

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]

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: [phone]
   Fax:   [phone]
   EMail: [e-mail]


   Craig Metz
   Kaman Sciences Corporation
   For NRL Code 5544
   4555 Overlook Avenue, S.W.
   Washington, DC, 20375-5337, USA

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]


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

   Phone: [phone]
   EMail: [e-mail]


   Mike Straw
   Bellcore
   RRC 1A-225
   445 Hoes Lane
   Piscataway, NJ 08854-4182

   Phone:  [phone]
   EMail:  [e-mail]









Haller                      Standards Track                    [Page 11]

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]

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 */