Enhancing TLS Security with One-Time Passwords: IETF Working Draft Overview
This working draft outlines a method for integrating One-Time Passwords (OTPs) within the TLS protocol by layering them on top of TLS-PSK. It supports multiple OTP methods, enabling peers to independently generate matching OTP values. The proposal includes utilizing new TLS extensions for requesting challenge data and defining OTP hardening parameters. Additionally, it details the transition from OTP to Pre-Shared Keys (PSK), outlines different key exchange schemes, and proposes new error alerts. The draft aims to solicit further discussions and refine the technical approach toward standardization.
Enhancing TLS Security with One-Time Passwords: IETF Working Draft Overview
E N D
Presentation Transcript
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 • 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
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)
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).
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
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;
The OTP_Hardening extension struct { uint16 iteration_count; } OTPHardeningData;
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
Proposed New Error Alerts • Unsupported_otp_algorithm • Otp_key_lost • Otp_key_expired • Otp_key_blocked • Otp_key_unknown • Pin_change_required
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?
