draft-sunabhi-otp-ikev2-03 Sunil Kumar Internet Draft Abhishek Singh Intended Status: Proposed Standard Safenet Infotech Pvt Ltd Expiration Date: May 2009 Nov 2008 One time Password in IKE version 2 (non-EAP based) draft-sunabhi-otp-ikev2-03.txt Status of this Memo 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. The proposed method of using OTP in IKEv2 not only enhances the security but also has less number of exchange messages as compared to existing OTP-EAP based method. 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..............................5 5.0 References ...........................................6 Authors Address ..........................................6 Intellectual Property and Copyright Statements............7 Kumar & Singh OTP IKEv2 [Page 1] Internet Draft OTP IKEv2 Nov 2008 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. This draft aims to present the utilization of the resources through which (OTP) One time passwords can be generated for Ikev2. One-time password (OTP) increases the complexity to gain unauthorized access to restricted resources. There have been various EAP based methods using OTP in IKEv2 [EAP GTC or EAP-POTP]. The proposed draft provides the following inherent advantages over the existing EAP based methods * Existing OTP-EAP based authentication method in IKEv2 increases the number of messages to be exchanged. The proposed draft for using OTP uses only four (4) message exchanges as in the original IKEv2. * The proposed method enhances the security in a way, if in the first exchange the "Identity + OTP" is not true, then the responder could reject the exchange there itself. 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 sends its identity IDi along with the One time password OTPi. In the IKEv2 [RFC 4306], the identity is encrypted and is sent along with third exchange message (IKE_AUTH), where as in the proposed draft identity is sent unencrypted. However it has to be noted that sending the Identity in clear does not compromise the security, as Identity of initiator is combination of IDi and OTPi. And (IDi + OTPi) is distinct at each instance since the OTPi is changing at each instance. Kumar & Singh OTP IKEv2 [Page 2] Internet Draft OTP IKEv2 Nov 2008 Responder in the similar manner uses IDr+OTPr as its Identity. Hence the proposed method of sending the identity in the first two exchanges is equally secure as sending the identity in IKEv2. 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 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 functions can be if OTPi is the value at time instance t, then the OTPr can be the value generated at instance t-10. For the above proposed function the initiator and the responder will have to store a set of generated passwords. Detailed description of the function is not the scope of the current document. However it has to be noted that since, initiator and the responder are storing a set of generated OTP, when the responder recieves OTPi, from the value of OTPi, the time instant 't' can be calculated at responder end. The time "t" denotes the time at which the negotiation has started. This value of "t" which is mutually known by both ends can be used further for calculating AUTH payload. For each retransmission or replay of any messages having OTP, it MUST be ensured that the OTP is a subsequent or a new one. Each party now can generate SKEYSEED, from which all keys are derived for that IKE_SA. HDR, SK {IDi, AUTH, SAi2, TSi, TSr} --> In the case of a OTP, the AUTH value is computed as: AUTH = prf(prf( OTP(n),"Key Pad for IKEv2"), ) Since initiator and the responder knows the time "t" at which the negotiation started, for the computation of AUTH, OTP(n) = OTP(t) +/- r. Where r can be some prefixed value. The value r can also be a known value to both parties. Kumar & Singh OTP IKEv2 [Page 3] Internet Draft OTP IKEv2 Nov 2008 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. 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. Kumar & Singh OTP IKEv2 [Page 4] Internet Draft OTP IKEv2 Nov 2008 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. 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. Kumar & Singh OTP IKEv2 [Page 5] Internet Draft OTP IKEv2 Nov 2008 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 6.0 Acknowledgements We would like to thank Pasi Eronen for his helpful comments. Author's Address ---------------- Sunil Kumar Email: sunil.kumar@safenet-inc.com contactsunilkumar@gmail.com Phone : 91-9818107930 (m) Abhishek Singh Email: abhicc285@gmail.com Phone : 425 922 3162 (m) 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 : 91-9818107930 Kumar & Singh OTP IKEv2 [Page 6] Internet Draft OTP IKEv2 Nov 2008 Full Copyright Statement 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Kumar & Singh OTP IKEv2 [Page 7]