Paul Wouters writes: > > This "feature" of the protocol is really bad, and we should not copy > > anything like that to the IKEv2. > > It was solved in for instant the GSSAPI drafts, by sending the ID in > the first packet exchange, and mixing it into the SKEYSEED to avoid > MITM token/id passing. So it _can_ be done but it does reveal the > ID's in the clear unless this is done in an AUTH roundtrip to add > protection against passive attackers at the expense of one roundtrip.
Main mode of IKEv1 is supposed to protect identity. It is described in the section 4.5 Identity Protection Exchange in the RFC 2408. So anything which leaks out the identities in main mode is not really main mode, but some other exchange. Don't remember what GSSAPI draft did for the exchange type, i.e. did they have separate exchange type, or did they reuse the number 2 Identity Protection... IKEv2 the only exchange we have is something that will protect identities for passive attackers. > > I.e. in addition to the g^ir (new) and nonces, we can add the PPK > > there: > > > > KEYMAT = prf+(SK_d, PPK | Ni | Nr) > > > > KEYMAT = prf+(SK_d, PPK | g^ir (new) | Ni | Nr) > > So devil's advocate here. Haven't we just reduced all of IKE to a > convoluted one time pad scheme? Yes and no. If the method of getting the PPK based on the PPK_ID is an offset to the one time pad, then yes, we are using one time pad to generate keys, but it is not one time pad scheme, as we only use the PPK to generate the keys for the encryption and the encryption is not using one time pad. If the PPK is for example just static 256-bit random shared secret between peers, then there is no one time pad property there at all, but the IPsec SA traffic is still protected against enemies using quantum computer to break the Diffie-Hellman. Unless the enemy also gets the PPK he will not be able to decrypt the IPsec SA traffic. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
