RFC 4793
The EAP Protected One-Time Password Protocol (EAP-POTP)
Pages: 82
Informational
Informational
Part 3 of 3 – Pages 57 to 82
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)
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
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
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.
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.
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.
[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.
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.
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
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
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
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
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)
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
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
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
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
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
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
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
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)
<- 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
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
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.
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
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.