1 / 9

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

cleave
Télécharger la présentation

EAP-POTP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. 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

  5. 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

  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?

More Related