90 likes | 235 Views
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
E N D
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
EAP-Request/Identity EAP-Response/Identity Radius-Access-Request Radius-Access-Challenge EAP-Request/OTP Server Info TLV OTP TLV EAP-Response/OTP User Identifier TLV OTP TLV Radius-Access-Request Radius-Access-Challenge Principles of Operation EAP RADIUS Calculate keys, Calculate MAC Calculate keys, Verify MAC, Calculate new MAC
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 Principles of Operation, Continued EAP RADIUS Verify MAC
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?