RE: [Ipsec] FW: Remaining issues for IKEv2

[Pasi.Eronen@nokia.com]

Hi,

This is not a new change; it is part of the change originally
proposed by Hugo in January (that was already approved). Hugo's 
proposal was the following (from e-mail sent on January 13th):
  
   Specifically add the pair SK_pi, SK_pr to the key derivation
   formula in 2.14. Change prf(SK_ar,IDr') to prf(SK_pr,IDr')
   and prf(SK_ai,IDr') to prf(SK_pi,IDr') in section
   2.15. Change "SK_ai and SK_ar" in the next to last paragraph
   of section 2.16 with "SK_pi and SK_pr"

Only the first and third changes were made in ikev2-13; the
second sentence was accidentally missed.

Best regards,
Pasi

> -----Original Message-----
> From: ipsec-admin@ietf.org On Behalf Of ext Charlie Kaufman
> Sent: Wednesday, May 12, 2004 12:13 AM
> To: Theodore Ts'o
> Cc: ipsec@ietf.org
> Subject: RE: [Ipsec] FW: Remaining issues for IKEv2
> 
> 
> Ted TS'o wrote:
> >On Mon, May 10, 2004 at 04:02:13PM -0700, Charlie Kaufman wrote:
> >> 
> >> Proposal by Pasi.Eronen supported by Hugo Krawczyk on 3/30/04 to 
> >> change the computation of the AUTH payload. This is yet another 
> >> "gilding the lily" crypto modification. I am confident it adds no 
> >> cryptographic strength to the protocol and it breaks compatibility 
> >> with anyone who has implemented this stuff already, but it 
> >> adds only trivial complexity to the protocol and a trivial 
> >> computational overhead. In the past, it's been easier to just 
> >> accept these proposals than to argue. One last time??
> >> 
> >
> > I've looked through both archives and the VPNC mailing list, and I
> > can't find this proposal.  Was it actually sent to the entire ipsec
> > mailing list?  In any case, I tend to agree with previously expressed
> > sentiments that absent a very strong, compelling need to make changes
> > in the crypto core of IKEv2, it is long past time to shoot the
> > engineers and ship the product.
> 
> Gak! My error. I didn't notice that the messages of 3/30 were
> sent only to me and not posted to the ipsec list. They are
> included below (without permission, but they don't appear to
> contain anything embarrassing).
> 
> The proposed change provides a certain consistency of usage of
> the various keys, which could simplify some security
> analysis. But unlike the previous related change supported by
> CFRG, this one changes the wire formats of all exchanges - not
> just ones using non-recommended EAP methods.
> 
> The current syntax was introduced in March 2003 in response to a
> different theoretical objection from Hugo.
> 
> 	--Charlie
> 

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec