Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4793

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

Pages: 82
Informational
Part 3 of 3 – Pages 57 to 82
First   Prev   None

Top   ToC   RFC4793 - Page 57   prevText

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