1. EAP-POTP Magnus Nyström, RSA Security 23 May 2005

2. Overview EAP-POTP —Enables programmatic use of a connected OTP token —Provides mutual authentication —Generates keying material —Does not rely on tunnelling (provides privacy for OTP values) —Enables fast session resumption EAP-POTP —Complements EAP-PEAP, EAP-TTLS, and EAP-FAST —May be used as a better alternative for an “inner” EAP method than EAP-GTC, PAP, CHAP, etc

3. Characteristics Built on the principle of TLVs —13 TLVs defined: Version, Server-Info, Resume, OTP, Confirm, Vendor-Specific, Counter, Time Stamp, Keep Alive, Token Serial, User Identifier, NAK, New PIN —Keep-Alive added in draft 2, needed to protect against time-outs (sent e.g. by peer when waiting for user input) The method is profiled for RSA SecurID – EAP-POTP RSA SecurID —Profiles for other OTP algorithms expected and desired —May be used as a framework within a framework EAP is framework for many authentication mechanisms POTP is framework for OTP-based mechanisms within EAP

4. Principles of Operation RADIUS Radius-Access-Request EAP EAP-Request/OTP Server Info TLV OTP TLV EAP-Response/OTP User Identifier TLV OTP TLV Radius-Access-Request Radius-Access-Challenge EAP-Request/Identity EAP-Response/Identity Radius-Access-Challenge Calculate keys, Calculate MAC Calculate keys, Verify MAC, Calculate new MAC

5. Principles of Operation, Continued RADIUSEAP EAP-Request/OTP Confirm TLV EAP-Response/OTP Confirm TLV Radius-Access-Request Radius-Access-Accept EAP-Success Start of encrypted and mutually authenticated session Verify MAC

6. Key derivation Both sides calculate: KMAC | KENC | MSK | EMSK = PBKDF2-SHA256 (otp, salt | pepper | auth_addr, iteration_count, kLen) —KMAC is used to authenticate (MAC) the parties – MACs on PDUs —KENC is used to protect sensitive data —MSK is delivered to the EAP method caller (“Master Session Key”) —EMSK is saved for future use —PBKDF2 is defined in PKCS #5 v2.0 (Password-based KDF) —otp is the OTP value —salt and pepper are random nonces (only salt is sent in protocol) —auth_addr is the NAS address as seen by the peer —iteration_count slows down an attacker (as does pepper), and —kLen = | KMAC | + | KENC | + | MSK | + | EMSK |

7. Authentication Use KMAC to calculate MACs: —Peer calculates MAC on all received and sent EAP messages —EAP Server verifies client MAC and then calculates MAC on peer’s message Change since draft 2: EAP headers (EAP Code, Identifier, and Length) not included in MAC —This is due to implementation experience, Identifier values not always known by sender

8. For discussion Need to identify accepted New PIN —New flag in OTP TLV suggested (informs peer that PIN was accepted and shall be used in new OTP calculations) Calculation of keys also in unprotected mode? Profiles for other OTPs?

9. Next steps Agreement and stabilization of document content Publication of draft 3 (IETF I-D -02) —Ask for IETF last-call subsequent to that?