Summary

  • RFC 3526 gives IKE peers common MODP parameter sets, from the established 1536-bit group 5 through groups 14–18 at 2048 to 8192 bits. It deliberately does not promise that a group maps to a particular AES strength, and it separately requires the exponent not to become the weakest link.
  • A defensible security receipt must join parameter identity to local policy, private-exponent entropy, peer-public-value tests, authentication, the rest of the negotiated suite, key lifecycle and observed traffic. A Transform ID proves a selection, not the quality of every act performed with it.

The group number is unusually easy to preserve. It appears in a proposal, a response, a registry and a diagnostic trace. The private exponent is supposed to disappear. Its quality depends on a local generator at a particular moment, behind a boundary that the peer cannot inspect.

That asymmetry invites an evidentiary mistake. A large public number becomes a proxy for a complete exchange. RFC 3526 does not support that promotion.

Published in May 2003 on the Standards Track and now recorded at Proposed Standard level, the document defines public mathematical material. It is a catalogue and coordination artifact. It is not an attestation of the runtime that consumes it.

The RFC standardized choices, not outcomes

IKE needed groups stronger than the four then defined. RFC 3526 documented the already-used 1536-bit group 5 and added group 14 at 2048 bits, group 15 at 3072, group 16 at 4096, group 17 at 6144 and group 18 at 8192. Each uses generator 2 and a published prime construction.

Those identifiers solve a real interoperability problem. Two implementations can refer to the same parameters without transmitting or inventing a fresh modulus. A trace that records group 16 can be checked against a stable public definition.

But stable parameters are only inputs. They do not say which endpoint is on the other side, whether the proposal was locally authorized, how a secret was sampled, whether a received public value was legal, which PRF and encryption transforms completed the suite, or what happened to later traffic.

The receipt is therefore narrow: “these parameters were selected for this exchange.” Anything stronger needs another source of evidence.

The document refuses a simple bit-for-bit promise

RFC 3526 presents sharply different estimates for the finite-field size needed to match 128-, 192- or 256-bit symmetric ciphers. One cited estimate places a 128-bit comparison near 3200 bits and much larger sizes against 192 and 256 bits. Other cited estimates are substantially lower for the latter strengths.

The authors do not settle the disagreement with a marketing table. They publish several groups and explicitly decline to specify which one should accompany each AES key size. They also stop at 8192 bits because larger groups were considered impractical on contemporary hardware.

This restraint matters. A configuration report cannot legitimately convert “group 18” into “256-bit security guaranteed” merely by aligning two numbers. Security equivalence depends on assumptions, cryptanalytic estimates, time horizon, surrounding algorithms and implementation quality.

The parameter catalogue gives operators choices. It does not remove the need for a policy judgment or freeze that judgment in 2003.

The exponent can undercut the group

The most direct warning is in the introduction: the exponent size must match the rest of the system and must not be its weakest link. The RFC states that it should contain more than twice the randomness of the intended system strength; its example demands more than 256 bits of randomness for a group treated as 128-bit strength.

This is about entropy, not the width of a database field. Allocating a 512-bit buffer does not prove that a cryptographically secure source supplied 512 unpredictable bits. Reformatting repeated or biased output does not manufacture missing uncertainty.

Nor should an audit store the secret exponent as proof. That would turn evidence collection into key disclosure. A useful receipt identifies the approved generator and version, its health-test state, the requested entropy and exponent policy, the fact of fresh generation, and a protected event binding. It does not retain the secret material.

A large group paired with a weak, repeated or predictable private act can still make that private act the easiest path of attack. Public scale cannot compensate for absent local randomness.

A peer’s public value needs its own verdict

RFC 6989 later specifies tests for IKEv2 recipients. For the Sophie Germain-prime MODP family that includes the RFC 3526 groups, the receiver verifies that the peer’s public value r falls strictly inside 1 < r < p-1.

The test is not encoded in the group identifier. A peer can propose group 14 and still send a value that the implementation must reject. Negotiation tells the receiver which validation rule applies; it does not prove the rule ran.

RFC 6989 also distinguishes groups with small subgroups and the consequences of private-key reuse. Those are not interchangeable branches. For certain groups, an implementation must either perform the subgroup check required for reuse or generate a fresh private value and perform the prescribed range check.

An event record should keep a digest of the received public value, the exact validation profile, implementation version and pass or fail result. A log line that says only “DH group accepted” collapses parameter recognition, input validation and policy acceptance into one opaque state.

Local acceptance is not inherited from mandatory implementation

RFC 7296 separates interoperability capability from deployment policy. IKEv2 implementations expose management controls for acceptable suites, compare received Transform IDs with locally configured choices and reject proposals not authorized by those controls. A suite that must be implemented need not be enabled.

That distinction prevents the registry from becoming a remote policy engine. The fact that an identifier is standardized, registered or implemented does not force an operator to accept it for every purpose.

RFC 8247 illustrates why the policy moves. At publication it raised group 14 to MUST for implementation, while group 5 became SHOULD NOT because its margin was considered too narrow. It also warned that extremely large groups impose material load, especially on VPN gateways and constrained devices.

The correct record includes the offered suite, the selected transform, the local policy version, the decision and rejected alternatives. “Supports group 18” is an inventory statement. “Allowed group 18 here under policy X” is an authorization statement. Neither is yet a session outcome.

Group agreement does not authenticate the peer

Unauthenticated Diffie-Hellman establishes a shared value with whoever participated in the exchange. IKE adds authentication methods and binds negotiated material into a wider protocol. RFC 3526 does not replace those mechanisms.

The group receipt therefore cannot identify the counterparty. It cannot prove a certificate chain was valid, a pre-shared key belonged to the intended principal, an EAP method reached the intended trust decision, or the authenticated name matched the policy subject.

This is another place where a strong-looking number can acquire borrowed authority. A dashboard shows 4096 bits and a green handshake, then downstream systems label a user, device or organization as trusted. The identity claim came from another part of the exchange and must be audited there.

Keep the authentication method, credential path, validation policy, claimed and accepted identities and channel binding separate from the group identifier. Their relationship is correlation, not inheritance.

The rest of the suite still sets the ceiling

RFC 8247 states the broader rule: cryptographic security depends on algorithms and keys, plus protocol engineering that prevents non-cryptographic bypass. A large Diffie-Hellman group cannot rescue a weak PRF, a disallowed integrity transform, broken authentication, exposed key storage or a bypass outside the cryptographic path.

It can also carry a cost. Larger modular exponentiations consume more computation and may increase exposure to resource exhaustion if expensive work is performed before a peer is authenticated. The existence of that trade-off is not an argument for weak groups; it is an argument for recording the complete control decision.

The negotiated suite should be evaluated as a dependency graph. The effective promise is constrained by its weakest relevant primitive and by how the protocol composes them. A compliance export listing only the largest bit length is not a security analysis.

Later work such as RFC 7919 for TLS uses different named groups and a different negotiation context, in part to avoid cross-protocol parameter reuse. It is useful comparison evidence, not a retrofit of TLS rules onto IKE.

Registry state is current coordination, not runtime truth

The IANA IKEv2 registry currently lists groups 5 and 14 through 18 with RFC 3526 as their definition and RFC 6989 for recipient tests. That registry answers what an identifier names and where its rules are documented.

It does not report whether a particular device implements the group correctly, enables it under current policy, produces fresh private values, validates inputs, authenticates its peer, erases retired secrets or carries protected traffic.

RFC 9395 closed the IKEv1 registries and deprecated IKEv1 itself. It listed no additional Diffie-Hellman groups in that document’s algorithm-deprecation set. This is a precise historical fact, not a declaration that every remaining group is equally preferred or every old deployment is safe.

Registries, standards-track status, implementation requirements and deployment decisions answer different questions. Keeping their receipts separate prevents a current database row from becoming an invented warranty for running code.

Build a group-to-outcome receipt

Begin with exact protocol version, RFC identity, Transform ID, prime and generator hash. Record the full ordered proposal, selected suite, downgrade context, local-policy identifier and authorization result.

For the private operation, preserve non-secret evidence of the entropy source, health state, exponent policy and freshness. For the received value, keep a digest, validation profile and branch. Never place the exponent itself in ordinary telemetry.

Bind authentication evidence to the exchange: method, credential chain or PSK identity, validation policy and accepted principal. Then record key derivation inputs that are safe to retain, algorithm identifiers, SA creation, rekey, non-reuse assertions and secret-erasure events.

Close the chain outside the handshake. Measure whether protected packets passed, whether integrity failures occurred, whether the expected peer and traffic selectors held, and whether the application completed its promise. A successful negotiation is a prerequisite for some of those outcomes, not their receipt.

Evidence boundary

This Article identifies no implementation, vendor, operator, VPN, gateway, peer, user, deployment, flow, incident or compromise. It makes no measurement claim about adoption, entropy quality, public-value validation, key reuse, latency, capacity, security level or business impact in a current system.

RFC 3526 is treated as a May 2003 Standards Track document currently recorded at Proposed Standard level. Later RFCs retain their own dates and scopes. RFC 6989 supplies recipient-test guidance; RFC 7296 defines IKEv2 control behavior; RFC 8247 records time-bound algorithm requirements; RFC 9395 deprecates IKEv1. None proves a named runtime followed the rules.

Heng Lu’s notes on authority and running code are disclosed editorial lenses. They motivate the separation between a public coordination record and locally verified execution, but they do not establish IETF intent or cryptographic fact.

The conclusion is deliberately limited: a larger group can strengthen one mathematical component, while the actual exchange remains only as strong and attributable as the other receipts show.

Sources