Sunil Kumar SafeNet Infotech Pvt. Ltd. Abhishek Singh SafeNet Infotech Pvt. Ltd. One time Password in Internet Key Exchange Protocol version 2 draft-sunabhi-otp-ikev2-00.txt By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79." Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations (SAs). This document presents the changes in Internet Key Exchange Version 2 for one time password. [page 1] Table of Content 1.0 Introduction .........................................2 2.0 IKEv2 using OTP.......................................2 3.0 Keying Material Using OTP.............................4 4.0 CREATE_CHILD_SA exchange..............................4 5.0 References ...........................................5 Authors Address ..........................................6 Full Copyright Statement .................................6 1.0 Introduction IKEv2 discussed in RFC 4306 is build upon Oakley protocol, and uses a Diffie-Hellman key exchange to set up a shared session secret, from which cryptographic keys are derived.Public key techniques/ PSK in IKEv2 are used to mutually authenticate the communicating parties. The draft only presents the changes in IKEv2 for using One Time Passwords for mutual authentication. One-time password (OTP) increases the complexity to gain unauthorized access to restricted resources. For the further details for IKEv2 refer to RFC 4306. One time passwords [RFC 1760] [RFC 2289]for IKEv2 can either be generated by event synchronous algorithms or by using the time synchronous algorithms. 2. IKEv2 using OTP Initiator Responder ----------- ----------- HDR, SAi1, KEi, IDi, OTPi --> HDR contains the Security Parameter Indexes (SPIs), version numbers, and flags of various sorts. The SAi1 payload states the cryptographic algorithms the initiator supports for the IKE_SA. The KE payload sends the initiator's Diffie-Hellman value. Instead of Ni in the as in the IKEv2, the initiator send its identity IDi along with the One time password OTPi. The One time password can be generated by event synchronous algorithm or by the time synchronous algorithm. The detailed description of the algorithms to generate OTP are beyond the scope of this document <-- HDR, SAr1, KEr, IDr, OTPr [page 2] The responder chooses a cryptographic suite from the initiator's offered choices and expresses that choice in the SAr1 payload, completes the Diffie-Hellman exchange with the KEr payload. The Responder since has the same event or time synchronous algorithm for OTP, verifies the IDi and OTPi. The responder sends IDr, OTPr. OTPr = f(OTPi) For example, one of the function can be if OTPi is the value at time instance t, then the OTPr can be the value generated at instance t+1. Each party can now can generate SKEYSEED, from which all keys are derived for that IKE_SA. HDR, SK {IDi, AUTH, SAi2, TSi, TSr} --> The initiator asserts its identity with the IDi payload, proves knowledge of the secret corresponding to IDi and integrity protects the contents of the first message using the AUTH payload. For further details of AUTH refer to RFC 4306. The initiator begins negotiation of a CHILD_SA using the SAi2 payload. The final fields (starting with SAi2) are described in the description of the CHILD_SA exchange. <-- HDR, SK {IDr, AUTH, SAr2, TSi, TSr} The responder asserts its identity with the IDr payload, authenticates its identity and protects the integrity of the second message with the AUTH payload, and completes negotiation of a CHILD_SA with the additional fields described [section 4.0] in CREATE_CHILD_SA exchange. The recipients of messages 3 and 4 MUST verify that all signatures and MACs are computed correctly and that the names in the ID payloads correspond to the keys used to generate the AUTH payload. [page 3] 3.0 Keying Material using OTP The shared keys are computed similar to IKEv2 [RFC 4306] with the exception being IDi, OTPi is used instead of Ni and IDr, OTPr is used instead of Nr. SKEYSEED is calculated from the nonces exchanged during the IKE_SA_INIT exchange and the Diffie-Hellman shared secret established during that exchange. SKEYSEED is used to calculate seven other secrets: SK_d used for deriving new keys for the CHILD_SAs established with this IKE_SA; SK_ai and SK_ar used as a key to the integrity protection algorithm for authenticating the component messages of subsequent exchanges; SK_ei and SK_er used for encrypting (and of course decrypting) all subsequent exchanges; and SK_pi and SK_pr, which are used when generating an AUTH payload. SKEYSEED and its derivatives are computed as follows: SKEYSEED = prf(IDi,OTPi |IDr,OTPr , g^ir) {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } = prf+ (SKEYSEED, IDi,OTPi | IDr,OTPr | SPIi | SPIr ) (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, and SK_pr are taken in order from the generated bits of the prf+). If the negotiated prf takes a fixed-length key and the lengths of IDi, OTPi and IDr, OTPr do not add up to that length, half the bits must come from OTPi and half from OTPr, taking the first bits of each. 4.0 CREATE_CHILD_SA exchange The CREATE_CHILD_SA request contains: Initiator Responder ----------- ----------- HDR, SK {[N], SA, IDi, OTPi, [KEi], [TSi, TSr]} --> The initiator sends SA offer(s) in the SA payload, ID of the initiator and the One time password OTPi optionally a Diffie-Hellman value in the KEi payload, and the proposed traffic selectors in the TSi and TSr payloads. [page 4] The CREATE_CHILD_SA response contains: <-- HDR, SK {SA, IDr, OTPr, [KEr],[TSi, TSr]} One-time password (OTP) increases the complexity to gain unauthorized access to restricted resources. OTPr = f(OTPi) The responder replies (using the same Message ID to respond) with the accepted offer in an SA payload, and a Diffie-Hellman value in the KEr payload if KEi was included in the request and the selected cryptographic suite includes that group. The traffic selectors for traffic to be sent on that SA are specified in the TS payloads, which may be a subset of what the initiator of the CHILD_SA proposed. Traffic selectors are omitted if this CREATE_CHILD_SA request is being used to change the key of the IKE_SA. 5.0 References [RFC 4306] C. Kaufman, "Internet key Exchange Protocol (Ikev2 protocol)" [RFC 1760] N.Hallwer, "The S/KEY One-Time Password System" http://tools.ietf.org/html/rfc1760 [RFC 2289] N. Haller,C. Metz,P. Nesser, M. Straw,"One-Time Password System", http://tools.ietf.org/html/rfc2289 [page 5] Author's Address ---------------- Sunil Kumar Email: sunil.kumar@in.safenet-inc.com contactsunilkumar@gmail.com Phone : 9818107930 Abhishek Singh Email: asingh3@in.safenet-inc.com abhicc285@gmail.com Phone : 9899835649 SafeNet InfoTech Pvt. Ltd. Logix TechnoPark 5th & 6th Floor, Plot No.5 Sector - 127 Taj Express Way Noida - 201301. U.P. Email: sunil.kumar@in.safenet-inc.com Phone : 9818107930 Copyright (C) The IETF Trust (2008) ------------------------------------- This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights." "This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." [page 6]