Re: [Ipsec-tools-devel] [IPsec] New method to resist replay attack in ikev2

[ramaswamy <ram...@gl...>]

Please see my comments inline.

Best Regards ,
Ram

-----Original Message-----
From: ips...@ie... [mailto:ips...@ie...] On Behalf Of
Tero Kivinen
Sent: Tuesday, September 20, 2011 6:16 AM
To: ramaswamy
Cc: ip...@ie...; ips...@li...;
ips...@li...; ike...@li...
Subject: Re: [IPsec] New method to resist replay attack in ikev2

ramaswamy writes:
> Thanks for the response, I agree with your comments, I think we can use
> certificates to avoid man in the middle attacks and error message flooding
> in the INIT phase only, as certificates are signed by trusted certificate
> authorities authenticity is ensured.
> 
> If certificates are used in INIT message exchanges [mutual
authentication],
> we can effectively avoid afore said attacks as it avoids huge computation
of
> IKE-keys before the client OR server is authenticated.

RSA operations are already huge computation. There is no big
difference whether you do RSA or Diffie-Hellman.

>>>>>>>>>>> [Ram] I agree with you, but we have certificate verification
done at AUTH phase, our suggestion is the same can be moved to initial phase
of ikev2 exchanges and this will ensure authenticity before IKEv2-KEYS[seven
keys] are generated.
As IKE users are already authenticated there is no need of CERT message
exchanges in AUTH phase and also which in turn will help to avoid man in the
middle attacks and error message flooding at IKEv2-INIT level only.
And also it will avoid unnecessary computation of ikev2-keys[seven keys:
which involves huge computation] at server end  due to INIT-REQESTS sent by
attackers. 
>>>>>>>>>>>>>>>>>>>>>>>>>>>

> To avoid Replay attacks:
> By using RSA private key of certificate to encrypt the nonce (Ni) in
> INIT_REQUEST message we can avoid replay attacks, at the receiving end,
> first certificate is verified using root CA and nonce is decrypted using
> public key of the received certificate which ensures that sender holds the
> valid private key of the certificate and not an attacker.  By using nonce
we
> can avoid Replay attacks[Packets can be rejected if the same nonce is
> received within a particular session].

So you plan to store that nonce forever, and always verify that the
nonce is not used before? That would be extremely expensive way to
solve the replay attack.	

>>>>>>>>>>> [Ram] I agree that storing nonce forever is not an best solution
to solve replay attacks, but our suggestion is to store the nonce from
particular client for particular session [time limit Eg: 2 minutes]. If it
receives same nonce with in the permissible time limit it should rejected.
If it more than permissible limit server will throw an error SKEW_ERROR,
handling of which is explained below.

To do it more effectively Ikev2 client should be clock synchronized with
server by negotiating client time by using encrypted nonce(Ni) --> timestamp
[Ni is encrypted by RSA private key of certificate of ikev2 client
certificate]  in INIT-REQUEST it self, and server can check the received
time [encrypted nonce(Ni):timestamp] and if it is more than permissible time
limit say Eg: 2 minutes it can throw an clock skew error[SKEW_ERROR], by
putting its server time using  encrypted server nonce (Nr) using RSA private
key of certificate of ikev2 server certificate.

Upon receipt of skew error ikev2 client must compute the difference (in
seconds) between the
two clocks based upon the client and server time contained in the SKEW_ERROR
message. The client should store this clock difference in non-volatile
memory and must use it to adjust ikev2 client timestamps[Ni] in subsequent
INIT-REQ request messages by adding the clock skew to its local clock value
each time.
If the encrypted nonce differs from server time by permissible limit it can
reject the INIT-REQ and avoid replay attacks. 
>>>>>>>>>>>>>>>>>> 


-- 
ki...@ik...
_______________________________________________
IPsec mailing list
IP...@ie...
https://www.ietf.org/mailman/listinfo/ipsec