tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 4793

 
 
 

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

Part 3 of 3, p. 57 to 82
Prev RFC Part

 


prevText      Top      Up      ToC       Page 57 
5.  EAP Key Management Framework Considerations

   In line with recommendations made in [16], EAP-POTP defines the
   following identifiers to be associated with generated key material:

      Peer-ID: The combined contents of the User Identifier TLV and the
      Token Key Identifier TLV.

      Server-ID: The contents of the Server Identifier field of the
      Server-Info TLV.

      Method-ID: The identifier of the established session (i.e., the
      contents of the Session Identifier field of the Server-Info TLV
      that defined the session).

6.  Security Considerations

6.1.  Security Claims

   In conformance with RFC 3748 [1], the following security claims are
   made for the EAP-POTP method:

   Authentication mechanism:  Generic OTP
   Ciphersuite negotiation:   Yes (No in basic variant)
   Mutual authentication:     Yes (No in basic variant)
   Integrity protection:      Yes (No in basic variant)
   Replay protection:         Yes (see below)
   Confidentiality:           Only in the OTP protection variant, and
                              then only OTP values and any information
                              sent after exchange of the Confirm TLV
   Key derivation:            Yes (No in basic variant)
   Key strength:              Depends on size of OTP value, strength of
                              underlying shared secret, strength and
                              characteristics of OTP algorithm, pepper
                              length, iteration count, and whether the
                              method is used within a tunnel such as
                              PEAPv2.  For some illustrative examples,
                              and a further discussion of this, see
                              Appendix D.
   Dictionary attack prot.:   N/A (Human-selected passwords not used)
   Fast reconnect:            Yes
   Crypt. binding:            N/A (EAP-POTP is not a tunnel method)
   Session independence:      Yes
   Fragmentation:             N/A (Packets shall not exceed MTU of 1020)
   Channel binding:           Yes (No in basic variant)
   Acknowledged S/F:          Yes
   State Synchronization:     Yes (No in basic variant)

Top      Up      ToC       Page 58 
6.2.  Passive and Active Attacks

   The basic variant (i.e., when the protection of OTPs and mutual
   authentication is not used) of this EAP method does not provide
   session privacy, session integrity, server authentication, or
   protection from active attacks.  In particular, man-in-the-middle
   attacks, where an attacker acts as an authenticator in order to
   acquire a valid OTP, are possible.

   Similarly, the basic variant of this EAP method does not protect
   against session hijacking taking place after authentication.  Nor
   does it, in itself, protect against replay attacks, where the
   attacker gains access by replaying a previous valid request, but see
   also the next subsection.  When PIN codes are transmitted, they are
   sent without protection and are also subject to replay attacks.

   In order to protect against these attacks, the peer MUST only use the
   basic variant of this method over a server-authenticated and
   confidentiality-protected connection.  This can be achieved via use
   of, PEAPv2 [17], for example.

   When the OTP protection variant is used, however, the EAP method
   provides privacy for OTPs and new PINs, negotiation of cryptographic
   algorithms, mutual authentication, and protection against replay
   attacks and protocol version downgrades.  It also provides protection
   against man-in-the-middle attacks, not due to the infeasibility for a
   man-in-the-middle to solve for a valid OTP given an OTP TLV, but due
   to the computational expense of finding the OTP in the limited time
   period during which it is valid (this is mainly true for tokens,
   including the current time in their OTP calculations, or when a sent
   challenge has a certain lifetime).  It should be noted, however, that
   a retrieved OTP, even if "old" and invalid, still may divulge some
   information about the user's PIN.  Clearly, this is also true for the
   basic variant.  Implementations of this EAP method, where user PINs
   are sent with OTPs, are therefore RECOMMENDED to ensure regular user
   PIN changes, regardless of whether the protected variant or the basic
   variant is employed.

   It should also be noted that, while it is possible for a rogue access
   point, e.g., to clone MAC addresses, and hence mount a man-in-the-
   middle attack, such an access point will not be able to calculate the
   session keys MSK and EMSK.  This demonstrates the importance of using
   the derived key material properly to protect a subsequent session.

   Protected mode protects against version downgrade attacks due to the
   HMAC both parties transmit in this mode.  As described, each party
   calculates the HMAC on sent and received EAP-POTP handshake messages.
   If an attacker were to modify a Version TLV, this would be reflected

Top      Up      ToC       Page 59 
   in a difference between the calculated MACs (since the recipient of
   the Version TLV received a different value than the sender sent).
   Unless the attacker knows K_MAC, he cannot calculate the correct MAC,
   and hence the difference will be detected.

   The OTP protection variant also protects against session hijacking,
   if the derived key material is used (directly or indirectly) to
   protect a subsequent session.  For these reasons, use of the OTP
   protection variant is RECOMMENDED.

   However, it should be noted that not even the OTP protection variant
   provides privacy for user names and/or token key identifiers.  EAP-
   POTP MUST be used within a secure tunnel such as the one provided by
   PEAPv2 [17] if privacy for these parameters is required.

   When resuming sessions created in the basic variant (which MUST only
   take place within a protected tunnel), the peer is authenticated by
   demonstrating knowledge of not just a valid session identifier, but
   also the OTP used when the session was created.  Server nonces
   prevent replay attacks, but there still remains some likelihood of an
   attacker guessing the correct combination of session identifier and
   OTP value.  Assuming OTPs with entropy about 32 bits, this means that
   the likelihood of succeeding with such an attack is about 1/2^48 due
   to the birthday paradox.  Servers allowing session resumption for the
   basic variant MUST protect against such attacks, e.g., by keeping
   track of the rate of failed resumption attempts.

6.3.  Denial-of-Service Attacks

   An active attacker may replace the iteration count value in OTP TLVs
   sent by the peer to slow down an authentication server.
   Authentication servers SHOULD protect against this, e.g., by
   disregarding OTP TLVs with an iteration count value higher than some
   number that is preset or dynamically set (depending on load).

6.4.  The Use of Pepper

   As described in Section 4.8, the use of pepper will slow down an
   attacker's search for a matching OTP.  The ability to transfer a
   pepper value in encrypted form from the EAP server to the peer means
   that, even though there may be an initial computational cost for the
   EAP server to authenticate the peer, subsequent authentications will
   be efficient, while at the same time more secure, since a pre-shared,
   128-bit-long pepper value will not be easily found by an attacker.
   An attacker, observing an EAP-Request containing an OTP TLV
   calculated using a pepper chosen by the peer, may, however, depending
   on available resources, be able to successfully attack that
   particular EAP-POTP session, since it most likely will be based on a

Top      Up      ToC       Page 60 
   relatively short pepper value or only an iteration count.  Once the
   correct OTP has been found, eavesdropping on the EAP server's Confirm
   TLV will potentially give the attacker access to the longer, server-
   provided pepper for the remaining lifetime of that pepper value.  For
   this reason, initial exchanges with EAP servers SHOULD occur in a
   secure environment (e.g., in a PEAPv2 tunnel offering cryptographic
   binding with inner EAP methods).  If initial exchanges do not occur
   in a secure environment, the iteration count MUST be significantly
   higher than for messages where a pre-shared pepper is used.  The
   lifetime of the shared pepper must also be calculated with this in
   mind.  Finally, the peer and the EAP server MUST store the pepper
   value securely and associated with the user.

6.5.  The Race Attack

   In the case of fragmentation of EAP messages, it is possible (in the
   basic variant of this method) for an attacker to listen to most of an
   OTP, guess the remainder, and then race the legitimate user to
   complete the authentication.  Conforming backend authentication
   server implementations MUST protect against this race condition.  One
   defense against this attack is outlined below and borrowed from [14];
   implementations MAY use this approach or MAY select an alternative
   defense.  Note that the described defense relies on the user
   providing the identity in response to an initial Identity EAP-
   Request.

   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.

7.  IANA Considerations

7.1.  General

   This document is a description of a general EAP method for OTP
   tokens.  It also defines EAP method 32 as a profile of the general
   method.  Extending the set of EAP-POTP TLVs or the set of EAP-POTP
   cryptographic algorithms shall be seen as revisions of the protocol
   and hence shall require an RFC that updates or obsoletes this
   document.

Top      Up      ToC       Page 61 
7.2.  Cryptographic Algorithm Identifier Octets

   A new registry for EAP-POTP cryptographic algorithm identifier octets
   has been created.  The initial contents of this registry are as
   specified in Section 4.11.16.

   Assignment of new values for hash algorithms, encryption algorithms,
   and MAC algorithms in the Crypto Algorithm TLV MUST be done through
   IANA with "Specification Required" and "IESG Approval" (see [9] for
   the meaning of these terms).

8.  Intellectual Property Considerations

   RSA, RSA Security, and SecurID are either registered trademarks or
   trademarks of RSA Security Inc. in the United States and/or other
   countries.  The names of other products and services mentioned may be
   the trademarks of their respective owners.

9.  Acknowledgments

   This document was improved by comments from, and discussion with, a
   number of RSA Security employees.  Simon Josefsson drafted the
   initial versions of an RSA SecurID EAP method while working for RSA
   Laboratories.  The inspiration for the TLV-type of information
   exchange comes from [17].  Special thanks to Oliver Tavakoli of Funk
   Software who provided numerous useful comments and suggestions, Randy
   Chou of Aruba Networks for good suggestions in the session resumption
   area, and Jim Burns of Meetinghouse who provided inspiration for the
   Protected TLV.  Thanks also to the IESG reviewers, Pasi Eronen, David
   Black, and Uri Blumenthal, for insightful comments that helped to
   improve the document, and to Alfred Hoenes for a thorough editorial
   review.

Top      Up      ToC       Page 62 
10.  References

10.1.  Normative References

   [1]   Blunk, L., Vollbrecht, J., Aboba, B., Carlson, J., and H.
         Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC
         3748, June 2004.

   [2]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [3]   National Institute of Standards and Technology, "Secure Hash
         Standard", FIPS 180-2, February 2004.

   [4]   National Institute of Standards and Technology, "Specification
         for the Advanced Encryption Standard (AES)", FIPS 197, November
         2001.

   [5]   Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
         for Message Authentication", RFC 2104, February 1997.

   [6]  Kaliski, B., "PKCS #5: Password-Based Cryptography Specification
         Version 2.0", RFC 2898, September 2000.

   [7]   Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD
         63, RFC 3629, November 2003.

   [8]   Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
         December 2004.

   [9]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs", RFC 2434, October 1998.

10.2.  Informative References

   [10]  Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51,
         RFC 1661, July 1994.

   [11]  The Institute of Electrical and Electronics Engineers, Inc.,
         "IEEE Standard for Local and metropolitan area networks --
         Port-Based Network Access Control", IEEE 802.1X-2001, July
         2001.

   [12]  Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC
         4306, December 2005.

Top      Up      ToC       Page 63 
   [13]  Stanley, D., Walker, J., and B. Aboba, "Extensible
         Authentication Protocol (EAP) Method Requirements for Wireless
         LANs", RFC 4017, March 2005.

   [14]  Haller, N., Metz, C., Nesser, P., and M. Straw, "A One-Time
         Password System", STD 61, RFC 2289, February 1998.

   [15]  Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
         Authentication Dial In User Service (RADIUS)", RFC 2865, June
         2000.

   [16]  Aboba, B., Simon, D., Eronen, P., and H. Levkowetz, Ed.,
         "Extensible Authentication Protocol (EAP) Key Management
         Framework", Work in Progress, October 2006.

   [17]  Palekar, A., Simon, D., Zorn, G., Salowey, J., Zhou, H., and S.
         Josefsson, "Protected EAP Protocol (PEAP) Version 2", Work in
         Progress, October 2004.

   [18]  Internet Assigned Numbers Authority, "Private Enterprise
         Numbers", December 2006.

   [19]  Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC
         2548, March 1999.

Top      Up      ToC       Page 64 
Appendix A.  Profile of EAP-POTP for RSA SecurID

   Note: The RSA SecurID product is a hardware token card (or software
   emulation thereof) produced by RSA Security Inc., which is used for
   end-user authentication.

   The EAP method type identifier for the RSA SecurID profile of EAP-
   POTP is 32.

   Peers and EAP servers implementing the SecurID profile of EAP-POTP
   SHALL conform to all EAP-POTP normative requirements in this
   Document.  In addition, the New PIN TLV and the Protected TLV MUST be
   supported by peers.

Top      Up      ToC       Page 65 
Appendix B.  Examples of EAP-POTP Exchanges

   This appendix is non-normative.  In the examples, "V1", "V2", "V3",
   etc., stand for arbitrary values of the correct type.

B.1.  Basic Mode, Unilateral Authentication

   This mode should only be used within a secured tunnel.  The peer
   identifies itself with a User Identifier TLV.

   Peer                                 EAP server

                                        <- EAP-Request
                                           Type=Identity

   EAP-Response ->
   Type=Identity

                                        <- EAP-Request
                                           Type=OTP-X

                                           Version TLV:
                                           Highest=0,Lowest=0

                                           OTP TLV:
                                           P=0,C=0,N=0,T=0,E=0,R=0

   EAP-Response ->
   Type=OTP-X

   Version TLV:
   Highest=0

   OTP TLV:
   P=0,C=0,N=0,T=0,E=0,R=0
   Authentication Data=V1

   User Identifier TLV:
   User Identifier=V2

                                        <- EAP-Success

Top      Up      ToC       Page 66 
B.2.  Basic Mode, Session Resumption

   This example illustrates successful resumption of a basic mode
   session.  It must be carried out only in a protected tunnel.

   Peer                                 EAP server

                                        <- EAP-Request
                                           Type=Identity

   EAP-Response ->
   Type=Identity

                                        <- EAP-Request
                                           Type=OTP-X

                                           Version TLV:
                                           Highest=0,Lowest=0

                                           OTP TLV:
                                           P=0,C=0,N=0,T=0,E=0,R=0

                                           Server-Info TLV:
                                           N=0
                                           Session Identifier=V1
                                           Server  Identifier=V2
                                           Nonce=V3
   EAP-Response ->
   Type=OTP-X

   Version TLV:
   Highest=0

   Resume TLV:
   Session Identifier=V4 (indicating earlier, basic mode, session)
   Authentication Data=V5

                                        <- EAP-Success

Top      Up      ToC       Page 67 
B.3.  Mutual Authentication without Session Resumption

   In this case, the peer uses the token key identifier, in addition to
   the user identifier.  The initial EAP-Identity exchange may also
   provide user information, or may be restricted to only general domain
   information.  Pepper is not used, but will be used in a subsequent
   session since the server provides the peer with an encrypted pepper
   in its Confirm TLV.  Absence of the Crypto Algorithm TLV indicates
   use of default cryptographic algorithms.

   Peer                                 EAP server

                                        <- EAP-Request
                                           Type=Identity

   EAP-Response ->
   Type=Identity

                                        <- EAP-Request
                                           Type=OTP-X

                                           Version TLV:
                                           Highest=0,Lowest=0

                                           Server-Info TLV:
                                           N=0
                                           Session Identifier=V1
                                           Server  Identifier=V2
                                           Nonce=V3

                                           OTP TLV:
                                           P=1,C=0,N=0,T=0,E=0,R=0
                                           Pepper Length=0
                                           Iteration Count=V4

   EAP-Response ->
   Type=OTP-X

   Version TLV:
   Highest=0

   OTP TLV:
   P=1,C=0,N=0,T=0,E=0,R=0
   Pepper Length=0
   Iteration Count=V4
   Authentication Data=V5

Top      Up      ToC       Page 68 
   User Identifier TLV:
   User Identifier=V6

   Token Key Identifier TLV:
   Token Key Identifier=V7

                                        <- EAP-Request
                                           Type=OTP-X

                                           Confirm TLV:
                                           C=0
                                           Authentication Data=V8
                                           Pepper Identifier=V9
                                           Encrypted Pepper=V10

   EAP-Response ->
   Type=OTP-X

   Confirm TLV:
   (no data)

                                        <- EAP-Success

Top      Up      ToC       Page 69 
B.4.  Mutual Authentication with Transfer of Pepper

   The difference between this example and the previous one is that the
   peer makes use of an existing pepper in the PBKDF2 computation.  The
   EAP server provides a new pepper to the peer in the Confirm TLV.
   Note that the peer had not been able to use a pepper in the response
   calculation unless it had found the existing pepper, since the server
   specified a maximum (new) pepper length of zero.

   Peer                                 EAP server

                                        <- EAP-Request
                                           Type=Identity

   EAP-Response ->
   Type=Identity

                                        <- EAP-Request
                                           Type=OTP-X

                                           Version TLV:
                                           Highest=0,Lowest=0

                                           Server-Info TLV:
                                           N=0
                                           Session Identifier=V1
                                           Server  Identifier=V2
                                           Nonce=V3

                                           OTP TLV:
                                           P=1,C=0,N=0,T=0,E=0,R=0
                                           Pepper Length=0
                                           Iteration Count=V4

   EAP-Response ->
   Type=OTP-X

   Version TLV:
   Highest=0

   OTP TLV:
   P=1,C=0,N=0,T=0,E=0,R=0
   Pepper Length=V5
   Iteration Count=V6
   Authentication Data=V7
   (includes a pepper identifier)

Top      Up      ToC       Page 70 
   User Identifier TLV:
   User Identifier=V8

   Token Key Identifier TLV:
   Token Key Identifier=V9

                                        <- EAP-Request
                                           Type=OTP-X

                                           Confirm TLV:
                                           C=0
                                           Authentication Data=V10
                                           Pepper Identifier=V11
                                           Encrypted Pepper=V12

   EAP-Response ->
   Type=OTP-X

   Confirm TLV:
   (no data)

                                        <- EAP-Success
B.5.  Failed Mutual Authentication

   This example differs from the previous one in that the peer is not
   able to authenticate the server.  Therefore, it sends an empty EAP-
   Response of type POTP-X, which the EAP server acknowledges by
   responding with an EAP-Failure.  Pepper is not used.

   Peer                                 EAP server

                                        <- EAP-Request
                                           Type=Identity

   EAP-Response ->
   Type=Identity

                                        <- EAP-Request
                                           Type=OTP-X

                                           Version TLV:
                                           Highest=0,Lowest=0

                                           OTP TLV:
                                           P=1,C=0,N=0,T=0,E=0,R=0
                                           Pepper Length=V1
                                           Iteration Count=V2

Top      Up      ToC       Page 71 
                                           Server-Info TLV:
                                           N=0
                                           Session Identifier=V3
                                           Server  Identifier=V4
                                           Nonce=V5

   EAP-Response ->
   Type=OTP-X

   Version TLV:
   Highest=0

   OTP TLV:
   P=1,C=0,N=0,T=0,E=0,R=0
   Pepper Length=V1
   Iteration Count=V2
   Authentication Data=V6

   User Identifier TLV:
   User Identifier=V7

   Token Key Identifier TLV:
   Token Key Identifier=V8

                                        <- EAP-Request
                                           Type=OTP-X

                                           Confirm TLV:
                                           C=0
                                           Authentication Data=V9

   EAP-Response ->
   Type=OTP-X

   (no data)

                                        <- EAP-Failure

B.6.  Session Resumption

   This example illustrates successful session resumption.

   Peer                                 EAP server

                                        <- EAP-Request
                                           Type=Identity

Top      Up      ToC       Page 72 
   EAP-Response ->
   Type=Identity

                                        <- EAP-Request
                                           Type=OTP-X

                                           Version TLV:
                                           Highest=0,Lowest=0

                                           OTP TLV:
                                           P=1,C=0,N=0,T=0,E=0,R=0
                                           Pepper Length=V1
                                           Iteration Count=V2

                                           Server-Info TLV:
                                           N=0
                                           Session Identifier=V3
                                           Server  Identifier=V4
                                           Nonce=V5

   EAP-Response ->
   Type=OTP-X

   Version TLV:
   Highest=0

   Resume TLV:
   Session Identifier=V6 (indicating earlier, protected mode, session)
   Authentication Data=V7

                                        <- EAP-Request
                                           Type=OTP-X

                                           Confirm TLV:
                                           C=0
                                           Authentication Data=V8

   EAP-Response ->
   Type=OTP-X
   Confirm TLV:
   (no data)

                                        <- EAP-Success

Top      Up      ToC       Page 73 
B.7.  Failed Session Resumption

   This example illustrates a failed session resumption, followed by a
   complete mutual authentication.  The user is identified through the
   User Identifier TLV.  The client is able to reuse an older pepper.
   The server sends a new pepper for subsequent use in its Confirm TLV.
   The server suggests some non-default cryptographic algorithms, but
   the client only supports the default ones.

   Peer                                 EAP server

                                        <- EAP-Request
                                           Type=Identity

   EAP-Response ->
   Type=Identity

                                        <- EAP-Request
                                           Type=OTP-X

                                           Version TLV:
                                           Highest=0,Lowest=0

                                           OTP TLV:
                                           P=1,C=0,N=0,T=0,E=0,R=0
                                           Pepper Length=V1
                                           Iteration Count=V2

                                           Server-Info TLV:
                                           N=0
                                           Session Identifier=V3
                                           Server  Identifier=V4
                                           Nonce=V5

                                           Crypto Algorithm TLV:
                                           Hash Alg. Length=V6
                                           Hash Algorithms=V7
                                           Encr. Alg. Length=V8
                                           Encr. Algorithms=V9
                                           MAC Alg. Length=V10
                                           MAC Algorithms=V11

   EAP-Response ->
   Type=OTP-X

   Version TLV:
   Highest=0

Top      Up      ToC       Page 74 
   Resume TLV:
   Session Identifier=V12 (indicating earlier session)
   Authentication Data=V13

                                        <- EAP-Request
                                           Type=OTP-X

                                           OTP TLV:
                                           P=1,C=0,N=0,T=0,E=0,R=0
                                           Pepper Length=V14
                                           Iteration Count=V15

                                           Server-Info TLV:
                                           N=1 (no resumption)
                                           Session Identifier=V3
                                           Server  Identifier=V4
                                           Nonce=V16

   EAP-Response ->
   Type=OTP-X

   OTP TLV:
   P=1,C=0,N=1,T=1,E=0,R=0
   Pepper Length=V17
   Iteration Count=V18
   Authentication Data=V19 (with pepper identifier)

   User Identifier TLV:
   User Identifier=V20

                                        <- EAP-Request
                                           Type=OTP-X

                                           Confirm TLV:
                                           C=0
                                           Authentication Data=V21
                                           Pepper Identifier=V22
                                           Encrypted Pepper=V23
   EAP-Response ->
   Type=OTP-X

   Confirm TLV:
   (no data)

                                        <- EAP-Success

Top      Up      ToC       Page 75 
B.8.  Mutual Authentication, and New PIN Requested.

   In this example, the user is also requested to select a new PIN.  The
   new PIN is allowed to be alphanumeric, and must be at least 6
   characters long.  The user selects another PIN than the one suggested
   by the server.  The token key is identified through a combination of
   the user identifier and the token key identifier.  While waiting for
   the user input, to avoid network timeouts, the peer sends an EAP-
   Response containing a Keep-Alive TLV to the EAP server.  The EAP
   server responds by sending an EAP-Request containing a Keep-Alive TLV
   back to the peer.  Note that all TLVs exchanged after the Confirm TLV
   exchange are wrapped in the Protected TLV.  Absence of the Crypto
   Algorithm TLV indicates use of default cryptographic algorithms.

   Peer                                 EAP server

                                        <- EAP-Request
                                           Type=Identity

   EAP-Response ->
   Type=Identity

                                        <- EAP-Request
                                           Type=OTP-X

                                           Version TLV:
                                           Highest=0,Lowest=0

                                           OTP TLV:
                                           P=1,C=0,N=0,T=0,E=0,R=0
                                           Pepper Length=V1
                                           Iteration Count=V2

                                           Server-Info TLV:
                                           N=0
                                           Session Identifier=V3
                                           Server  Identifier=V4
                                           Nonce=V5

   EAP-Response ->
   Type=OTP-X

   Version TLV:
   Highest=0

   OTP TLV:
   P=1,C=0,N=0,T=0,E=0,R=0
   Pepper Length=V6

Top      Up      ToC       Page 76 
   Iteration Count=V7
   Authentication Data=V8 (with pepper identifier)

   User Identifier TLV:
   User Identifier=V9

   Token Key Identifier TLV:
   Token Key Identifier=V10

                                        <- EAP-Request
                                           Type=OTP-X

                                           Confirm TLV:
                                           C=1
                                           Authentication Data=V11

   EAP-Response ->
   Type=OTP-X

   Confirm TLV:
   (no data)

                                        <- EAP-Request
                                           Type=OTP-X

                                           Protected TLV:
                                           MAC=V12
                                           IV=V13
                                           Encrypted TLVs=V14
                                           (Contains:
                                           New PIN TLV:
                                           Q=0,A=1
                                           PIN=V15
                                           Min. PIN Length=6)

   EAP-Response ->
   Type=OTP-X

   Protected TLV:
   MAC=V16
   IV=V17
   Encrypted TLVs=V18
   (Contains:
   Keep-Alive TLV:
   (no data))

                                        <- EAP-Request
                                           Type=OTP-X

Top      Up      ToC       Page 77 
                                           Protected TLV:
                                           MAC=V19
                                           IV=V20
                                           Encrypted TLVs=V21
                                           (Contains:
                                           Keep-Alive TLV:
                                           (no data))

   EAP-Response ->
   Type=OTP-X

   Protected TLV:
   MAC=V22
   IV=V23
   Encrypted TLVs=V24
   (Contains:
   New PIN TLV:
   Q=0,A=0
   PIN=V25)

                                        <- EAP-Request
                                           Type=OTP-X

                                           Protected TLV:
                                           MAC=V26
                                           IV=V27
                                           Encrypted TLVs=V28
                                           (Contains:
                                           OTP TLV:
                                           P=1,C=0,N=0,T=0,E=0,R=0
                                           Pepper Length=V1
                                           Iteration Count=V2)

   EAP-Response ->
   Type=OTP-X

   Protected TLV
   MAC=V29
   IV=V30
   Encrypted TLVs=V31
   (Contains:
   OTP TLV:
   P=1,C=0,N=0,T=0,E=0,R=0
   Pepper Length=V6
   Iteration Count=V7
   Authentication Data=V31)

Top      Up      ToC       Page 78 
                                        <- EAP-Request
                                           Type=OTP-X

                                           Protected TLV
                                           MAC=V32
                                           IV=V33
                                           Encrypted TLVs=V34
                                           (Contains:
                                           Confirm TLV:
                                           C=0
                                           Authentication Data=V35)

   EAP-Response ->
   Type=OTP-X

   Protected TLV
   MAC=V36
   IV=V37
   Encrypted TLVs=V38
   (Contains:
   Confirm TLV:
   (no data))

                                        <- EAP-Success

B.9.  Use of Next OTP Mode

   In this example, the peer is requested to provide a second OTP to the
   EAP server.

   Peer                                 EAP server

                                        <- EAP-Request
                                           Type=Identity

   EAP-Response ->
   Type=Identity

                                        <- EAP-Request
                                           Type=OTP-X

                                           Version TLV:
                                           Highest=0,Lowest=0

                                           OTP TLV:
                                           P=1,C=0,N=0,T=0,E=0,R=0
                                           Pepper Length=V1
                                           Iteration Count=V2

Top      Up      ToC       Page 79 
                                           Server-Info TLV:
                                           N=0
                                           Session Identifier=V3
                                           Server  Identifier=V4
                                           Nonce=V5

   EAP-Response ->
   Type=OTP-X

   Version TLV:
   Highest=0

   OTP TLV:
   P=1,C=0,N=0,T=0,E=0,R=0
   Pepper Length=V6
   Iteration Count=V7
   Authentication Data=V8

   User Identifier TLV:
   User Identifier=V9

                                        <- EAP-Request
                                           Type=OTP-X

                                           OTP TLV:
                                           P=1,C=0,N=1,T=1,E=0,R=0
                                           Pepper Length=V1
                                           Iteration Count=V2

   EAP-Response ->
   Type=OTP-X

   OTP TLV:
   P=1,C=0,N=1,T=1,E=0,R=0
   Pepper Length=V6
   Iteration Count=V7
   Authentication Data=V10

                                        <- EAP-Request
                                           Type=OTP-X

                                           Confirm TLV:
                                           C=0
                                           Authentication Data=V11

   EAP-Response ->
   Type=OTP-X

Top      Up      ToC       Page 80 
   Confirm TLV:
   (no data)

                                        <- EAP-Success

Appendix C.  Use of the MPPE-Send/Receive-Key RADIUS Attributes

C.1.  Introduction

   This section describes how to populate the MPPE-Send-Key and the
   MPPE-Receive-Key RADIUS attributes defined in [19], using an MSK
   established in EAP-POTP.

C.2.  MPPE Key Attribute Population

   Once the EAP-POTP MSK has been generated, it is used as follows to
   populate the MPPE-Send-Key and the MPPE-Receive-Key attributes:

   Use the initial 32 octets of the MSK as the value for the "Key" sub-
   field in the plaintext "String" field of the MPPE-Send-Key attribute,
   and use the final 32 octets of the MSK as the "Key" sub-field in the
   plaintext "String" field of the MPPE-Receive-Key attribute (Note:
   "Send" and "Receive" here refer to the Authenticator; for the peer,
   they are reversed).

Appendix D.  Key Strength Considerations

D.1.  Introduction

   As described in Section 6, the strength of keys generated in EAP-POTP
   protected mode depends on a number of factors.  This appendix
   provides examples of actual key strengths achieved under various
   assumptions.

   It should be noted that, while some of the examples indicate that the
   strength of generated keys is relatively weak, the strength applies
   only to those EAP-POTP sessions between a peer and an EAP server that
   do not share a pepper.  Once a pepper, provided by an EAP server to a
   peer, has been established, future sessions using this pepper will
   provide full-strength keys.

Top      Up      ToC       Page 81 
D.2.  Example 1: 6-Digit One-Time Passwords

   In this example we assume the following:

      OTPs are six decimal digits long;

      4-digit PINs are added to generated OTPs; and

      OTP hardening (iteration count and pepper searching combined)
      effectively adds 10 bits of entropy.  One way of achieving this
      without use of pepper searching is to have the iteration count in
      PBKDF2 set to 1,000,000.

   The effective key strength then becomes roughly:

   log_2(10**6) + log_2(10**4) + log_2(2**10) = 43 bits

   The above assumes that the entropy of the underlying shared secret is
   >43 bits and that there are no other weaknesses in the OTP algorithm.

D.3.  Example 2: 8-Digit One-Time Passwords

   In this example we assume the following:

      OTPs are eight decimal digits long;

      4-character alphanumeric PINs are added to generated OTPs; and

      OTP hardening (iteration count and pepper searching combined)
      effectively adds 10 bits of entropy.

   The effective key strength then becomes roughly:

   log_2(10**8) + log_2(26**4) + log_2(2**10) = 55 bits

   The above assumes that the entropy of the underlying shared secret is
   >55 bits and that there are no other weaknesses in the OTP algorithm.

Author's Address

   Magnus Nystroem
   RSA Security

   EMail: magnus@rsa.com

Top      Up      ToC       Page 82 
Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.