Hi All
I have some doubt about Security of IKEv2 protocol. In the process
Of generating Keys, every parameter is taken from IKE_SA_INIT Messages
Which is un-unencrypted.
If attacker using some tools capturing all the IKE Packets from network,
he can easily generates the Keys. Although attacker can not establish a
SA without proper configuration information, but still he can easily get
the Keys, and he will be able to decrypt all the IKE Encrypted and
IPSEC Encrypted packets.
Don't you think this is a big Security Risk? In IKEv1 Pre-shared key
auth, PSK was taken as part of key
Calculation with is a secret to generate Key and provides some level of
Security.
IKE Key generation process:
SKEYSEED = prf(Ni | Nr, g^ir)
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } = prf+
(SKEYSEED, Ni | Nr | SPIi | SPIr )
With Regards
Syed Ajim
****************************************************************************
This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!
****************************************************************************
________________________________
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
[email protected]
Sent: Monday, November 22, 2010 1:30 AM
To: [email protected]
Subject: IPsec Digest, Vol 79, Issue 11
If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription. To do so, go to
https://www.ietf.org/mailman/listinfo/ipsec
Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME. You can set this option
globally for all the list digests you receive at this point.
Send IPsec mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/ipsec
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of IPsec digest..."
Today's Topics:
1. Re: HA protocol replay protection (Yaron Sheffer)
----------------------------------------------------------------------
Message: 1
Date: Sun, 21 Nov 2010 00:01:47 +0200
From: Yaron Sheffer <[email protected]>
Subject: Re: [IPsec] HA protocol replay protection
To: Pekka Riikonen <[email protected]>
Cc: IPsecme WG <[email protected]>, Tero Kivinen <[email protected]>, Raj
Singh <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Hi Pekka,
the text you are quoting provides implementation guidance (probably good
one), but does not "recommend" (in the RFC 2119 sense of the word, i.e.
equivalent to a normative SHOULD) to do so. We should have stronger text
if we are to avoid accidental replay.
Thanks,
Yaron
On 11/20/2010 02:14 PM, Pekka Riikonen wrote:
>
> :
> : Let's take the extreme case where the cluster and the peer synchronize
> : the SA, then there is no IKE traffic, and then they synchronize the SA
> : again. If we don't do anything special, the second pair of synch
> : messages will be identical to the first, i.e. will look like a replay.
> : So we have to prevent this case. One trivial solution is to mandate one
> : liveness test (initiated by the peer) immediately after the synch.
> :
> Note that draft recommends that the sync is done only when the IKE SA is
> actually needed. If there is not IKE traffic then the sync would have
> never been done in the first place.
>
> ...
> Since there can be a large number of sessions at the standby member,
> and sending synchronization exchanges for all of them may result in
> overload, the standby member can choose to initiate the exchange in a
> "lazy" fashion: only when it has to send or receive the request. In
> general, the standby member is free to initiate this exchange at its
> discretion.
> ...
>
> I've implemented the lazy sync, it's seems the best way to do it.
>
> Pekka
------------------------------
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
End of IPsec Digest, Vol 79, Issue 11
*************************************
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
