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 protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
