VIEWS: 12 PAGES: 9 POSTED ON: 3/13/2010
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 Radius-Access-Challenge EAP-Request/OTP Server Info TLV OTP TLV Calculate keys, Calculate MAC EAP-Response/OTP User Identifier TLV OTP TLV Radius-Access-Request Calculate keys, Verify MAC, Radius-Access-Challenge Calculate new MAC Principles of Operation, Continued EAP RADIUS EAP-Request/OTP Confirm TLV Verify MAC 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?
Pages to are hidden for
"eap-potp"Please download to view full document