Protected One-Time-Password (POTP) EAP Method

1. Protected One-Time-Password (POTP) EAP Method Magnus Nystrom, David Mitton RSA Security Inc. EAP WG, IETF 62, Minneapolis MN

2. Documents & Information • draft-nystrom-eap-potp-00.txt • Part of One-Time-Password Specifications http://www.rsasecurity.com/rsalabs/otps • OTP PKCS#11 Mechanisms • OTP CAPI – MS CryptoAPI Profile • OTP WSS Token: Web services Profile • OTP XML Validation Service • Mailing list: “subscribe otps” to majordomo@majordomo.rsasecurity.com EAP WG, IETF 62, Minneapolis MN

3. State of affairs • Current EAP support for OTP algorithms is poor • GTC User Prompts are text sent from server to client • Unilateral authentication • No generation of keying material • EAP OTP • Despite it’s name, a specialized method for a particular algorithm (S/Key). No generation of keying material, no session resume • EAP MS-Chap • Challenge-Response based • Requires MD4, DES. No features to slow down attacker • Lack of suitable support motivates us to develop a new EAP method oriented towards OTP Tokens • Protocol should be usable for handheld and machine readable devices EAP WG, IETF 62, Minneapolis MN

4. Goals • End-to-end protection of One-Time-Password authentication material • Mutual Authentication • Supports key derivation for 802.1x • Minimal initial configuration • No reliance on PKI • But complements PEAP, TTLS • Supports Token exception cases (New Pin, Next Token, others) • Meets current security requirements for EAP and Wireless authentication • Fast session resumption EAP WG, IETF 62, Minneapolis MN

5. IPR Statement • RSA technologists' goal: offer reciprocal Royalty Free licensing of any RSA IPR necessary to implement EAP-POTP • Formal IPR declaration targeted in advance of next IETF meeting EAP WG, IETF 62, Minneapolis MN

6. EAP Method 32 • Generates End-to-End credential confirmation • Generates strong session key material • Requests and Responses consist of multiple Type-Length-Value (TLV) fields • Allows flexible construction of messages • Minimizes round trips • 11 TLVs • Vendor Specific TLV format provided • Same format as corresponding PEAPv2 TLV EAP WG, IETF 62, Minneapolis MN

7. Defined TLV Types • Version - Protocol version negotiation • Server-Info - Identification and session resume info • One-Time-Password – Request and Response • NAK – Expanded NAK format • Pin – New Pin options and response • Confirm – Mutual Authentication handshake • Vendor Specific – Vendor additions • Resume – Resumes a prior authentication session • User Identifier – Username string • Token Serial Number – Allow identification/selection • Time Stamp – Time sync information • Keep-Alive – Avoid network timeouts EAP WG, IETF 62, Minneapolis MN

8. Header & TLV format M = Mandatory TLV, R = reserved Multiple TLVs form single EAP32 message EAP WG, IETF 62, Minneapolis MN

9. Sample Flow EAP WG, IETF 62, Minneapolis MN

10. Protected OTP ComputationClient Side OTP Salt* | Pepper | AuthData* Iteration Count* EAP Request Message Key Len=160 PBKDF2-SHA256 SHA256 PKCS #5 V2.0 K_Mac | K_Enc | MSK | EMSK 16 | 16 | 64 | 64 msg_hash1 HMAC-SHA256 • All * values sent in response • OTP and Pepper values not sent, Pepper bit length sent AuthMac[16]* EAP WG, IETF 62, Minneapolis MN

11. POTP ComputationServer Side OTP *Salt | Pepper | *AuthData *Iteration Count EAP Request Message’ KL=160 PBKDF2-SHA256 SHA256 msg_hash1’ K_Mac’ | K_Enc’ | MSK’ | EMSK’ HMAC-SHA256 *Received *AuthMac AuthMac’ equal? EAP WG, IETF 62, Minneapolis MN

12. POTP Confirm EAP Response Message’ EAP Response Message Kmac Kmac’ SHA256 SHA256 msg_hash2’ msg_hash2 HMAC-SHA256 HMAC-SHA256 mac_a’ mac_a Confirm Request equal? Confirm Response, EAP Success EAP WG, IETF 62, Minneapolis MN

13. Slowing Down Attackers • Iteration count - overhead • Pepper makes pre-calculation harder • Client selects random value, undisclosed • Bit length sent • Problem with server overhead • To prevent future server load, server can send back 32 bit value, encrypted with K_Enc EAP WG, IETF 62, Minneapolis MN

14. Other Features • Flags in OTP request provide passcode options • New Pin mode uses AES CBC mode with Kenc as Key to protect Pin values • Server can return a 32 bit saved Pepper value in Confirm TLV (AES CBC encrypted) • Would like to use as framework for other OTPs EAP WG, IETF 62, Minneapolis MN

15. Security Claims EAP WG, IETF 62, Minneapolis MN

16. Documents & Information • draft-nystrom-eap-potp-00.txt • Part of One-Time-Password Specifications http://www.rsasecurity.com/rsalabs/otps • OTP PKCS#11 Mechanisms • OTP CAPI – MS CryptoAPI Profile • OTP WSS Token: Web services Profile • OTP XML Validation Service • Mailing list: “subscribe otps” to majordomo@majordomo.rsasecurity.com EAP WG, IETF 62, Minneapolis MN