1 / 16

Protected One-Time-Password (POTP) EAP Method

Protected One-Time-Password (POTP) EAP Method. Magnus Nystrom, David Mitton RSA Security Inc. Documents & Information. draft-nystrom-eap-potp-00.txt Part of One-Time-Password Specifications http://www.rsasecurity.com/rsalabs/otps OTP PKCS#11 Mechanisms OTP CAPI – MS CryptoAPI Profile

takara
Télécharger la présentation

Protected One-Time-Password (POTP) EAP Method

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. Protected One-Time-Password (POTP) EAP Method Magnus Nystrom, David Mitton RSA Security Inc. EAP WG, IETF 62, Minneapolis MN

  2. Documents & Information • draft-nystrom-eap-potp-00.txt • Part of One-Time-Password Specifications http://www.rsasecurity.com/rsalabs/otps • OTP PKCS#11 Mechanisms • OTP CAPI – MS CryptoAPI Profile • OTP WSS Token: Web services Profile • OTP XML Validation Service • Mailing list: “subscribe otps” to majordomo@majordomo.rsasecurity.com EAP WG, IETF 62, Minneapolis MN

  3. State of affairs • Current EAP support for OTP algorithms is poor • GTC User Prompts are text sent from server to client • Unilateral authentication • No generation of keying material • EAP OTP • Despite it’s name, a specialized method for a particular algorithm (S/Key). No generation of keying material, no session resume • EAP MS-Chap • Challenge-Response based • Requires MD4, DES. No features to slow down attacker • Lack of suitable support motivates us to develop a new EAP method oriented towards OTP Tokens • Protocol should be usable for handheld and machine readable devices EAP WG, IETF 62, Minneapolis MN

  4. Goals • End-to-end protection of One-Time-Password authentication material • Mutual Authentication • Supports key derivation for 802.1x • Minimal initial configuration • No reliance on PKI • But complements PEAP, TTLS • Supports Token exception cases (New Pin, Next Token, others) • Meets current security requirements for EAP and Wireless authentication • Fast session resumption EAP WG, IETF 62, Minneapolis MN

  5. IPR Statement • RSA technologists' goal: offer reciprocal Royalty Free licensing of any RSA IPR necessary to implement EAP-POTP • Formal IPR declaration targeted in advance of next IETF meeting EAP WG, IETF 62, Minneapolis MN

  6. EAP Method 32 • Generates End-to-End credential confirmation • Generates strong session key material • Requests and Responses consist of multiple Type-Length-Value (TLV) fields • Allows flexible construction of messages • Minimizes round trips • 11 TLVs • Vendor Specific TLV format provided • Same format as corresponding PEAPv2 TLV EAP WG, IETF 62, Minneapolis MN

  7. Defined TLV Types • Version - Protocol version negotiation • Server-Info - Identification and session resume info • One-Time-Password – Request and Response • NAK – Expanded NAK format • Pin – New Pin options and response • Confirm – Mutual Authentication handshake • Vendor Specific – Vendor additions • Resume – Resumes a prior authentication session • User Identifier – Username string • Token Serial Number – Allow identification/selection • Time Stamp – Time sync information • Keep-Alive – Avoid network timeouts EAP WG, IETF 62, Minneapolis MN

  8. Header & TLV format M = Mandatory TLV, R = reserved Multiple TLVs form single EAP32 message EAP WG, IETF 62, Minneapolis MN

  9. Sample Flow EAP WG, IETF 62, Minneapolis MN

  10. Protected OTP ComputationClient Side OTP Salt* | Pepper | AuthData* Iteration Count* EAP Request Message Key Len=160 PBKDF2-SHA256 SHA256 PKCS #5 V2.0 K_Mac | K_Enc | MSK | EMSK 16 | 16 | 64 | 64 msg_hash1 HMAC-SHA256 • All * values sent in response • OTP and Pepper values not sent, Pepper bit length sent AuthMac[16]* EAP WG, IETF 62, Minneapolis MN

  11. POTP ComputationServer Side OTP *Salt | Pepper | *AuthData *Iteration Count EAP Request Message’ KL=160 PBKDF2-SHA256 SHA256 msg_hash1’ K_Mac’ | K_Enc’ | MSK’ | EMSK’ HMAC-SHA256 *Received *AuthMac AuthMac’ equal? EAP WG, IETF 62, Minneapolis MN

  12. POTP Confirm EAP Response Message’ EAP Response Message Kmac Kmac’ SHA256 SHA256 msg_hash2’ msg_hash2 HMAC-SHA256 HMAC-SHA256 mac_a’ mac_a Confirm Request equal? Confirm Response, EAP Success EAP WG, IETF 62, Minneapolis MN

  13. Slowing Down Attackers • Iteration count - overhead • Pepper makes pre-calculation harder • Client selects random value, undisclosed • Bit length sent • Problem with server overhead • To prevent future server load, server can send back 32 bit value, encrypted with K_Enc EAP WG, IETF 62, Minneapolis MN

  14. Other Features • Flags in OTP request provide passcode options • New Pin mode uses AES CBC mode with Kenc as Key to protect Pin values • Server can return a 32 bit saved Pepper value in Confirm TLV (AES CBC encrypted) • Would like to use as framework for other OTPs EAP WG, IETF 62, Minneapolis MN

  15. Security Claims EAP WG, IETF 62, Minneapolis MN

  16. Documents & Information • draft-nystrom-eap-potp-00.txt • Part of One-Time-Password Specifications http://www.rsasecurity.com/rsalabs/otps • OTP PKCS#11 Mechanisms • OTP CAPI – MS CryptoAPI Profile • OTP WSS Token: Web services Profile • OTP XML Validation Service • Mailing list: “subscribe otps” to majordomo@majordomo.rsasecurity.com EAP WG, IETF 62, Minneapolis MN

More Related