Transcript EAP-POTP
EAP-POTP Magnus Nyström, RSA Security 23 May 2005 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 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 Principles of Operation EAP RADIUS EAP-Request/Identity EAP-Response/Identity Radius-Access-Request EAP-Request/OTP Server Info TLV OTP TLV Calculate keys, Calculate MAC EAP-Response/OTP User Identifier TLV OTP TLV Radius-Access-Challenge Radius-Access-Request Calculate keys, Verify MAC, Radius-Access-Challenge Calculate new MAC Principles of Operation, Continued EAP Verify MAC RADIUS 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 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 | 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 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? Next steps • • Agreement and stabilization of document content Publication of draft 3 (IETF I-D -02) — Ask for IETF last-call subsequent to that?