Subject: Re: [IPsec] Fw: Preshared key authentication in IKEv2

From: Tero Kivinen <[email-masked]>
Date: Mon, 2 Nov 2009 16:13:36 +0200

Paul Hoffman writes:
> At 9:58 AM +0300 10/30/09, Valery Smyslov wrote:
> >Hi all,
> >
> >I'd like to reiterate my early message, which I haven't got answer to.
> >My concerns are:
> >
> >1. How padding pre-sahred key with string "Key Pad for IKEv2"
> >    could help to avoid storing pre-shared key in IKE implementation
> >    if prf is not known untill IKE_SA_INIT exchange is finished?
> 
> The PRF (or set of PRFs) is known by the receiving party. If the two
> parties always only use one PRF, it is known. The padding is not a
> universal solution for the reasons you give, but it works in the
> common case of peers who know each other's crypto choices.

As Paul said recipient knows which algorithms it support, and it can
store the pre-shared key using all of those algoritms to its database.
I.e. if it supports PRF_HMAC_SHA1, and PRF_AES128_XCBC then it needs
to calculate the PRF(Shared Secret, "Key Pad for IKEv2") using those
two PRFs and store both of the results to its authentication database.

This way if someone manages to get the authentication database it
cannot directly know the Shared Secret, it just knows the hash, and
cannot use the Shared Secret in any other protocols.

> >2. It is a bit unclear whether EAP generated key should also
> >    be padded before use in IKE, or used directly.
> 
> I'm pretty sure the key is used in its PRF form, not in its "as is"
> form, but I would want to hear from one or two implementers on that. 

As section 2.16 refers to the 2.15 and says the AUTH payloads in
messages 7 and 8 using the syntax for shared secrets specified in
section 2.15, and section 2.15 tells that this padding is used, so I
think it should be used always (and by quick look in our code seemed
to use the same format for both cases). 
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 2 Nov 2009 17:40:57 +0300

Hi Paul and Tero,

thank you for your answers.

> As Paul said recipient knows which algorithms it support, and it can

Sometimes it doesn't. I refer to implementations with pluggable
crypto, when crypto providers are separated from IKE implementation
and can be added/removed later.

> two PRFs and store both of the results to its authentication database.

With this approach in case of pluggable crypto user must re-enter shared
secret
after any change in crypto configuration. It's not a big deal, just a bit
inconvinient...

Regards,
Smyslov Valery.

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 2 Nov 2009 16:43:43 +0200

> and can be added/removed later.

Then you need to store the original shared key not the hashed version
of it.
-- 
[email-masked]