Thinking it over, you don’t really need AES at all, and in any case it doesn’t
matter. The initiator doesn’t know the key and doesn’t know the algorithm, so
it’s entirely a local matter.
For example, the responder could pick HMAC-SHA256 with a fixed key, and
calculate HMAC-SHA256(K,cookie). An
I can see two drawbacks with this approach.
First, to make it aligned with algorithm agility, we need to
negotiate not only PRF, but also the encryption algorithm.
And the selection criteria would become more complex.
And second - it significantly increases the size of IKE_SA_INIT
response messa
On Thu, 5 Feb 2015, Tero Kivinen wrote:
I.e. replace:
For that reason the INITIAL_CONTACT
notifications MUST be ignored for IKE SAs using NULL Authentication.
with
For that reason the INITIAL_CONTACT
notifications MUST NOT be used to delete any other IKE SA
Valery Smyslov writes:
> > The rest of the section is ok. On the other hand if someone creates
> > second IKE SA and because it is not only SA does not send
> > INITIAL_CONTACT notification, it would be quite useless to start dead
> > peer detection for the IKE SA sharing same IP-address, because t
Hi Tero,
thanks for your detailed review.
In section 2.3 I think the first MUST for INITIAL_CONTACT should be
rephrased so that it says that it MUST NOT do normal INITIAL_CONTACT
processing for unaithenticated INITIAL_CONTACT. I think using that
INITIAL_CONTACT as a hint to start dead peer dete
> I think this data proves the idea that the difference between
> computation power of different clients is significant and
> no single puzzle difficulty level would be reasonable for all.
> I think we should proceed with the proposal that
> client is allowed to return less zero bits than requeste
> On Feb 1, 2015, at 8:38 PM, Scott Fluhrer (sfluhrer)
> wrote:
>
> If you want to tighten up the time between worse case and average case time
> taken by the problem solver, might I suggest this:
>
> - When the verifier is asked to generate a problem, it pick a nonce N, and
> use it to comp
In section 2.3 I think the first MUST for INITIAL_CONTACT should be
rephrased so that it says that it MUST NOT do normal INITIAL_CONTACT
processing for unaithenticated INITIAL_CONTACT. I think using that
INITIAL_CONTACT as a hint to start dead peer detection is ok, but
current text says it MUST be
Before I respond, here’s one more data point: I’ve compiled OpenSSL 1.0.2 for
ARM and got ~60,500 SHA-256 hashes (it’s close enough to not matter to the
result for HMAC-SHA-256) per second.
That says that assuming 1 second as the “reasonable” time to solve a puzzle, we
can expect to do about 16
