Re: [IPsec] IKE's DH groups 19-21, NIST, FIPS 140-2, etc.

At 6:27 PM -0700 7/9/09, Dan Harkins wrote: > RFC 5114 claims it defines new ECP groups 19, 20, and 21 for IKE but >so does RFC 4753. To be fair, I don't see where RFC 5114 claims that they are new. In fact, it says "Three of these groups were previously specified for use with IKE [RFC4753]".

Re: [IPsec] IKE's DH groups 19-21, NIST, FIPS 140-2, etc.

Hi Paul, RFC5114 doesn't say they're new, it just gives a definition for them. And the difference is in the curve equations. For group 19 RFC4753 says that the equation for the curve is y^2 = x^3 - 3x + b and RFC5114 say the equation for the curve is y^2 = x^3 + ax + b. The equation for th

Re: [IPsec] IKE's DH groups 19-21, NIST, FIPS 140-2, etc.

At 9:59 AM -0700 7/12/09, Dan Harkins wrote: > Of course, since p-3=a and the generator is the same it may not matter. Exactly. >But it still seems wrong to have two different documents defining the same >curve differently, even if they are uncorrelated Informational RFCs. Again: RFC 5114 does

[IPsec] Stockholm agenda

Greetings again. Yaron and I have posted the agenda for the Stockholm meeting on the official IETF site; see . We have only heard so far from two sets of document authors asking for presentation time for upcoming work, and that is reflec

Re: [IPsec] New version of labeled ipsec drafts

Hi Joy, Couldn't the security context information be expressed in the IKEv2 version as a new Traffic Selector type? It seems that the IKEv2 negotiation exchanges a parameter set that describes the upper-layer data to pass over the ESP or AH SA. This is what the Traffic Selectors in IKEv2 do.

Re: [IPsec] IKE's DH groups 19-21, NIST, FIPS 140-2, etc.

On Sun, July 12, 2009 1:33 pm, Paul Hoffman wrote: >>But it still seems wrong to have two different documents defining the >> same >>curve differently, even if they are uncorrelated Informational RFCs. > > Again: RFC 5114 does not "define" those three curves. The IANA registry, >