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

[Tero Kivinen <[e-mail]>]

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). 
-- 
[e-mail]