1 / 8

EAP-POTP

Overview. EAP-POTPEnables programmatic use of a connected OTP tokenProvides mutual authenticationGenerates keying materialDoes not rely on tunnelling (provides privacy for OTP values)Enables fast session resumptionEAP-POTPComplements EAP-PEAP, EAP-TTLS, and EAP-FASTMay be used as a better alternative for an

ojal
Download Presentation

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. Principles of Operation

    5. Principles of Operation, Continued

    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