The EAP Protected One-Time Password Protocol (EAP-POTP)

Voir toute la rfc dans une seule page

Télécharger le PDF

RFC 4793                        EAP-POTP                   February 2007


   RADIUS [15] is a typical choice.  It is assumed that the EAP client
   and the peer are located on the same host, and hence only the term
   "peer" is used in the following for these entities.

   The EAP-POTP method assumes the use of a shared secret key, or
   "seed", which is known both by the user and the backend
   authentication server.  The secret seed is stored on an OTP token
   that the user possesses, as well as on the authentication server.

   In its most basic variant, the EAP-POTP method provides only one
   Service (namely, user authentication) where the user provides
   information to the authentication server so that the server can
   authenticate the user.  A more advanced variant provides mutual
   authentication, protection against eavesdropping, and establishment
   of authenticated keying material.

4.  Description of the EAP-POTP Method

4.1.  Overview

   Note: Since the EAP-POTP method is general in nature, the term
   "POTP-X" is used below as a placeholder for an EAP method type
   identifier, identifying the use of a particular OTP algorithm with
   EAP-POTP.  As an example, in the case of using RSA SecurID tokens
   within EAP-POTP, the EAP method type shall be 32 (see Appendix A).

   A typical EAP-POTP authentication is performed as follows (Appendix B
   provides more detailed examples):

   a.  The optional EAP Identity Request/Response is exchanged, as per
       RFC 3748 [1].  An identity provided here may alleviate the need
       for a "User Identifier" or a "Token Key Identifier" triplet
       (TLV), defined below, later in the exchange.

   b.  The EAP server sends an EAP-Request of type POTP-X with a Version
       TLV.  The Version TLV indicates the highest and lowest version of
       this method supported by the server.  The EAP server typically
       also includes an OTP TLV in the EAP-Request.  The OTP TLV
       instructs the peer to respond with the current OTP (possibly in
       protected form), and may contain a challenge and some other
       information, like server policies.  The EAP server should also
       include a Server-Info TLV in the request, and must do so if it
       supports session resumption.  The Server-Info TLV identifies the
       authentication server, contains an identifier for this (new)
       session, and may be used by the peer to find an already existing
       session with the EAP server.





Nystroem                     Informational                      [Page 6]