1 / 10

OTP Methods for TLS

OTP Methods for TLS. TLS Working Group IETF, Montreal July 2006 WORKING DRAFT: 6 July 2006. Background. Original draft in One-Time Password Specification (OTPS) series, now draft-linn-otp-tls-00 Goal: Enable use of One-Time Passwords in TLS by layering on TLS-PSK

taryn
Download Presentation

OTP Methods for TLS

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. OTP Methods for TLS TLS Working Group IETF, Montreal July 2006 WORKING DRAFT: 6 July 2006

  2. Background • Original draft in One-Time Password Specification (OTPS) series, now draft-linn-otp-tls-00 • Goal: Enable use of One-Time Passwords in TLS by layering on TLS-PSK • Support multiple OTP methods, using OTP-derived PSKs • Methods must enable peers to generate matching OTP values independently (e.g., not RFC-2289 / S-KEY) • Approach applies ciphersuites defined in RFC 4279 and TLS extensions defined in RFC 3546

  3. Proposed Approach • TLS extensions not required if challenge is not needed and hardening is unnecessary or implicit • In ClientHello, client may use new TLS extensions to: • Request challenge data, if needed for OTP method • Suggest OTP hardening parameters • In ServerHello, server may use new TLS extensions to: • Provide challenge data (if asked for) • Determine hardening parameters (if suggested)

  4. From OTP to PSK (I) • PSK = PBKDF2 (OTP, RS || RC , iterationCount, keyLen) Where: • PBKDF2 defined in PKCS#5 (RFC 2898) • OTP is the current one-time password, • RS is the server_random value from the Server Hello • RC is the client_random value from the Client Hello • iterationCount is the iteration_count value from the otp_hardening extension • keyLen shall be set to 16 (128 bits).

  5. From OTP to PSK (II) • Three choices for key exchange scheme • Direct PSK: Likely requires OTP hardening • Ephemeral D-H: Likely requires OTP hardening too, if MITM is a concern • RSA: No need for OTP hardening, but requires PKI

  6. The Challenge_Data extension struct { ChallengeDataType challenge_data_type; select (ChallengeDataType) { case request: ChallengeRequestData; case response: ChallengeResponseData; } challenge_data; } ChallengeData; struct { opaque otp_algorithm<0..2^16-1>; opaque otp_user_id<0..2^16-1>; opaque otp_key_id<0..2^16-1>; } ChallengeRequestData; struct { opaque otp_challenge<1..2^16-1>; } ChallengeResponseData;

  7. The OTP_Hardening extension struct { uint16 iteration_count; } OTPHardeningData;

  8. Proposed Use of PSK_Identity • ClientKeyExchange psk_identity identifies user and/or key • Indicates use of OTP-based PSK, with method identified explicitly or implicitly • May also carry current counter value or time, depending on OTP method • Examples: • UI=J. R. User, T=20051222114204, OM= • KI=142857, C=285714, OM=OTP-Counter

  9. Proposed New Error Alerts • Unsupported_otp_algorithm • Otp_key_lost • Otp_key_expired • Otp_key_blocked • Otp_key_unknown • Pin_change_required

  10. Next Steps • Solicit continuing WG discussion on approach • Technical issues: • Layering as RFC-4279 profile vs. parallel TLS key exchange algorithm • PSK_Identity conventions, possible new extension to identify OTP usage and negotiate OTP algorithm • Use of alerts • Consider for Informational or standards-track RFC?

More Related