Introduction This document describes default Diffie-Hellman groups for use in IKE and IKEv2 in addition to the Oakley Groups included in [IKE] and the additional groups defined since [IANA-IKE]. This document assumes that the reader is familiar with the IKE protocol and the concept of Oakley Groups@ as defined in RFC 2409 [IKE]. RFC 2409 [IKE] defines five standard Oakley Groups: three modular exponentiation groups and two elliptic curve groups over GF[2^N]. One modular exponentiation group (768 bits - Oakley Group 1) is mandatory for all implementations to support@ while the other four are optional. Nineteen additional groups subsequently have been defined and assigned values by IANA. All of these additional groups are optional. The purpose of this document is to expand the options available to implementers of elliptic curve groups by adding three ECP groups (elliptic curve groups modulo a prime). The reasons for adding such groups include the following. - The groups proposed afford efficiency advantages in software applications since the underlying arithmetic is integer arithmetic modulo a prime rather than binary field arithmetic. (Additional computational advantages for these groups are presented in [GMN].) - The groups proposed encourage alignment with other elliptic curve standards. The proposed groups are among those standardized by NIST@ the Standards for Efficient Cryptography Group (SECG)@ ISO@ and ANSI. (See Section 5 for details.) - The groups proposed are capable of providing security consistent with the Advanced Encryption Standard [AES]. In summary@ due to the performance advantages of elliptic curve groups in IKE implementations and the need for further alignment with other standards@ this document defines three elliptic curve groups based on modular arithmetic. These groups were originally proposed in [RFC4753]. This document changes the format of the shared key produced by a Diffie-Hellman exchange using these groups. The shared key format used in this specification appeared earlier as an erratum to RFC 4753 [Err9]@ but some implementors of RFC 4753 were unaware of the erratum and did not implement the correction. Implementations of RFC 4753 that incorporate the correction are interoperable with implementations of this specification. However@ there is a potential for interoperability problems between implementations of this specification and implementations of RFC 4753 that did not implement the correction from the erratum. These problems could be difficult to detect and analyze since both use the same code point but the secret value (which is probably not available to the trouble desk) is computed differently. Where peers are not interoperable@ the initiator will never receive a response and eventually times out. Section 9 provides more details of the changes from [RFC4753]. This document obsoletes RFC 4753 and addresses the erratum.