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"), <msg octets>)
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]