Summary

  • RFC 5421 documents EAP-FAST-GTC using Type 6, a code already assigned to EAP-GTC, for a different inner-method format carried in the tunnel.
  • Its inside/outside prohibitions and IESG compatibility warning make the enclosing EAP-FAST context part of the method’s identity; that is an implementation implication, not evidence of a measured outage.

One byte, two frames

EAP’s Type field is only one octet, but it does consequential work. RFC 3748 says the field identifies the method and describes EAP layers dispatching packets by Type, much as a transport layer uses a port number. An implementation that sees Type 6 therefore seems to have a simple answer: process Generic Token Card.

RFC 5421 complicates that answer by putting Type 6 inside EAP-FAST. The 2009 Informational memo documents EAP-FAST-GTC, an inner method for a basic password exchange. Its stated uses include legacy password databases, password changes and one-time-password flows. For historical reasons, it reuses the code originally assigned to EAP-GTC. The IANA registry still names Type 6 “Generic Token Card”; RFC 5421 did not create a second global assignment.

The distinction is in the frame and payload. EAP-FAST establishes a TLS tunnel; during its inner phase, EAP packets are carried in EAP Payload TLVs. RFC 5421 says EAP-FAST-GTC payload formatting is specific to the tunnel and is not necessarily compatible with ordinary EAP-GTC mechanisms outside it. It consequently sets two reciprocal rules: EAP-FAST-GTC MUST NOT run outside an EAP-FAST tunnel, and EAP-GTC MUST NOT run inside one.

Those rules do more than keep two packet formats tidy. They tell an implementation which method Type 6 means in each context. If a dispatcher retains only the one-byte code and discards whether the packet came from the outer exchange or the EAP-FAST inner phase, it has thrown away information the protocol uses to distinguish the methods. That is an implementation implication of the specification, not a claim that deployed systems have made this mistake.

The warning was explicit

RFC 5421’s IESG Note calls reuse of assigned EAP Type Codes incompatible with method negotiation as defined in RFC 3748. The note explains why EAP-FAST-GTC is implied inside the tunnel: EAP-GTC has no method-specific version negotiation that could otherwise distinguish the inner variant. The note warns that this can cause problems when an implementation also needs another vendor’s EAP-GTC, and that supporting the method both inside and outside a tunnel complicates implementations. It says unique Type codes would avoid the difficulty and directs that assigned method types not be reused with a different meaning inside future tunneled methods.

The language matters. This is not a finding that every exchange fails, that Type 6 was revoked, or that any present-day product is affected. It is the standards record naming a compatibility cost created by giving an assigned code contextual meaning. The IANA table shows the global label; the tunnel rules govern the inner use; the IESG Note explains the tension between them.

Running-code primacy offers a useful editorial lens here: a registry entry is not the whole system. Actual behavior depends on the code that receives a packet, identifies its layer, and selects a method. Heng Lu’s Note 65 informs that lens; it is not evidence about EAP requirements or vendor deployments.

Credential protection is a separate boundary

RFC 5421 also says EAP-FAST-GTC sends password information as cleartext strings within the encrypted TLS tunnel. The peer must authenticate the server before disclosing credentials, and the method MUST NOT be used in Server-Unauthenticated Provisioning Mode because that mode does not authenticate the server. These are important constraints on the inner exchange, but they are distinct from the Type-code question. A protected credential flow does not by itself solve method dispatch; a correct Type dispatch does not by itself establish the required server-authentication conditions.

For operators, the review point is the seam: where does the implementation decide whether Type 6 is ordinary EAP-GTC or EAP-FAST-GTC? The answer should be grounded in tunnel phase as well as Type, with the reciprocal inside/outside restrictions enforced. Tests can exercise GTC outside and FAST-GTC inside, then verify that each is rejected in the opposite context. Logs can record the selected method and phase without exposing password material. Such checks are proposed verification practice, not requirements added by this article.

RFC 5421 is Informational, and its compatibility warning should be read at that scope. It documents a real design trade-off and prescribes future caution; the public sources here do not establish present-day prevalence, vendor behavior, or incidents. Its lasting lesson is narrower and more useful: when a method code is reused under a tunnel, the frame carrying that code becomes operational context the dispatcher cannot safely forget.

Sources