Mutual OATH HOTP Variants 65th IETF - Dallas, TX March 2006

Agenda  What is OATH  What is Mutual OATH  HOTP Variants  Algorithm Identifier  Scenarios  Improvements

What is OATH  OATH is a group of companies working together to help drive the adoption of open strong authentication technology across all networks  Established in 2004  Large base of technology and industry leaders members  Neutral stance enables coordination with multiple standard bodies such as IETF, OASIS, W3C etc.  OATH goals  Get rid of static passwords! Expand secure and safe on-line transactions for consumers and business users with strong, 2-factor authentication  Ubiquitous - encourage device innovation and embedding  Reduce cost and complexity of deploying strong authentication solutions  Open and royalty-free specifications

Where OATH Fits In Application HTTP, POP3, IMAP, …. Identity Frameworks SAML, WS-*, (DIX) Authentication Protocols Authentication (EAP-*, Kerberos), Provisioning, (Validation) Algorithms HOTP, Mutual OATH Hardware Device Token, Cell Phone, Flash ROM… OATH Proposals OATH Platforms

Benefits of Open Standards  Several algorithms exist but all private  Proprietary tokens are expensive  Standardization drives down costs for end users  Open standards foster innovation (e.g., HTTP, TCP/IP)  Easy way for people to  Analyze the security algorithm  Integrate and lower deployment costs  Get a free, easily available description  Get a reference implementation

Mutual OATH  First version in December  New updated version submitted last week  Based on HOTP (RFC 4226)  Support for additional use cases  Asynchronous Authentication  Based on Challenge-Response  One-way and Two-way Authentication  Transaction Authentication/Signing  Configurable  Support for different cryptographic building blocks  Support for additional inputs during computation

Algorithm Identifier  Helps identify the various HOTP variants  AI = {  Type {HMAC-SHA-1 | HMAC-SHA-256 | …}  Truncation { 1, 2, …, N}  Input { Pb, Qb, Cb, Tb}  Mode { PLAIN | CHAINED }  Key { SINGLE | DUAL-COMPUTED | DUAL-STORED } }

Algorithm Identifier  Type defined the function used  0000 – HMAC-SHA-1  0001 – HMAC-SHA-256  0010 – HMAC-SHA-512  Truncation is to only use N digits  Standard value is 6 (0110)  Input is a 4-bit structure with  Pb (x000) – PIN or Password value P  Qb (0x00) – Random question Q  Cb (00x0) – Counter value C  Tb (000x) – Transaction value T

Algorithm Identifier – Two way values  Mode is a structure with  00 Plain – Simple mode  01 Chained – Dependent of the previous computation  Key is a structure with  00 SINGLE – One key  01 DUAL-COMPUTED – K1 = K, K2 = F(K)  10 DUAL-STORED – Two keys are stored

Standard – HOTP (RFC 4226) Client - tokenServer Session information: Token_ID, AI = {0000, 0110, 0010, 0000} 2. OTP 5. Accept / Deny 1.Start the “token”, an OTP value is displayed 3.Validate the response 4.Accept or deny the user

Mutual Challenge-Response Server Session information: Token_ID, AI = {0000, 0110, 1100, 0010} 5. Response_srv, Challenge_srv 13. Accept / Deny 2. Challenge_usr X 10. Response_usr 1.Start the “token”, a value X is displayed 6.Visual verification of the response 7.Enter PIN 8.Enter challenge 9.The “User” response is shown 3.Calculate the response 4.Send response and new challenge 11.Validate the response 12.Accept or deny the user Client - token PIN

Mutual Challenge-Response (Theory)  Response: HOTP (K, Q, … ) = Truncate (HMAC-SHA-1(K, Q, …))  Mutual Challenge-Response between parties A and B:  AI = {0000, 0110, 0100, 0001}  A sends a random question Q_A to B  B computes Response_B = HOTP (K1, Q_A) and sends it to A with its own random question Q_B  A checks Response_B and if correct, computes Response_A = HOTP (K2, Q_B)  B checks Response_A and if correct, acknowledges party A

Improvements  Additional input parameters  Time stamp  Adding truncation with check sum  Security proof  Independent from the hash function  Others?

Q & A  Questions?