Summary

  • RFC 5422 says Server-Unauthenticated Provisioning SHOULD NOT end in network access; Server-Authenticated provisioning may grant it after policy review.
  • A PAC acknowledgement reports the peer’s processing and storage result for a Tunnel PAC; it is not a later-authentication or admission result.

A bootstrap has a different finish line

A device may arrive at a network without the pre-shared secret, trusted server root or Protected Access Credential that would let it establish ordinary EAP-FAST mutual authentication. RFC 5422 addresses that starting condition. Its dynamic provisioning procedure can deliver credential material in-band, so the device can return later with something the server can verify. The design question is not only whether the exchange succeeded. It is what kind of success the exchange is allowed to produce.

EAP-FAST has a TLS-based phase 1 and an inner EAP phase 2. RFC 5422 describes two ways to provision the peer. In Server-Authenticated Provisioning, the peer authenticates the server during the TLS handshake. That requires the peer to have the information needed to validate the server’s credentials, which is precisely what an unprepared device may lack. In Server-Unauthenticated Provisioning, an anonymous Diffie–Hellman TLS tunnel provides confidentiality and key agreement without first authenticating the server. That lowers the bootstrap hurdle and creates a different trust problem.

The anonymous tunnel is not a license to skip authentication. Because the server is not authenticated in phase 1, an active intermediary may insert itself. RFC 5422 therefore requires the peer and server to complete an inner EAP method that mutually authenticates and derives keys, then validate the Crypto-Binding TLV to check the tunnel’s integrity. In the 2009 version, implementations of this mode had to support EAP-FAST-MSCHAPv2 as an inner authentication method. The point is a bound exchange: the peer must establish who it is talking to within the tunnel and verify that the inner result is tied to the outer TLS channel.

(RFC 5422 §§2, 3.2–3.2.3, 6.1.2; RFC 4851)

Only after that sequence succeeds does the server provision new material. It can send a Tunnel PAC, including the secret PAC-Key and the server-protected PAC-Opaque, or provision trusted server roots. A Tunnel PAC supports later establishment of an EAP-FAST tunnel; it is not itself a grant to use network resources. RFC 5422’s sequence treats it as an input to a subsequent authentication.

The Tunnel PAC acknowledgement is useful evidence, but its scope is specific. The peer sends PAC-Acknowledgement to report the result of processing and storing a newly provisioned Tunnel PAC. The acknowledgement is not used for other PAC types. A server can therefore record that the peer reported storage; it cannot infer from that message alone that a later authentication succeeded, that an authorization policy admitted the peer, or that packets reached a service. Those are different systems and different observations. (RFC 5422 §§3.2, 4.1.4, 4.2.5)

RFC 5422 is unusually direct about the boundary: at the end of Server-Unauthenticated Provisioning, network access SHOULD NOT be granted because the conversation is intended for provisioning only. Peer policy may disconnect and start a new EAP-FAST exchange using the newly provisioned information. The document says a server MAY grant access after successful Server-Authenticated Provisioning; it does not erase the distinction between those modes. “Provisioning succeeded” is not a universal EAP authorization result. (RFC 5422 §3.5)

The risk trade-off is also explicit. Server-Authenticated Provisioning gives stronger protection against a man-in-the-middle but depends on server credentials already being available to the peer. Server-Unauthenticated Provisioning can enable zero-touch bootstrap, yet exposes password-based phase-2 exchanges to greater offline dictionary risk. RFC 5422 recommends controls against online guesses and encourages limiting where or when the unauthenticated mode can run. These are design statements from an Informational document published in 2009, not measurements of present-day products or deployments. (RFC 5422 §§6.1–6.3)

A useful operational ledger keeps at least four receipts apart: the bootstrap attempt and selected mode; inner mutual authentication and Crypto-Binding; credential issuance and the peer’s Tunnel PAC acknowledgement; and the later authentication plus network access decision. A missing fourth receipt is not repaired by a successful first three. The distinction is especially important when a provisioning server and an access-control system are operated by different teams: each needs a shared session correlation key, a defined timeout and an owner for the transition from newly issued credential to admitted session.

A successful inner result can still end in denial

Section 3.5 makes server policy decisive even after a provisioning exchange has completed. In Server-Authenticated Provisioning, a server that has authenticated the peer may grant access after issuing a Tunnel PAC. In Server-Unauthenticated Provisioning, access SHOULD NOT be granted at the end because that conversation exists only to provision credentials. The two cases share a credential-delivery mechanism but not an authorization result.

That distinction survives a successful inner method. A Result TLV can report successful completion while the server still concludes that its access policy has not been satisfied and ends with EAP Failure. When an exchange is not intended to provide network access, RFC 5422 says the server SHALL NOT grant access or distribute session keys to the Network Access Server. An operations screen that counts only successful inner termination can therefore mark a peer green while the network has correctly withheld admission.

The useful record follows the outcome through the final EAP result and key release, rather than treating the first success indicator as the whole transaction. (RFC 5422 §3.5; RFC 4851 §4.2.2)

The acknowledgement covers one event in a credential’s life

A Tunnel PAC is not one generic token. Its PAC-Key is a 32-octet secret used to establish the phase-1 tunnel; the PAC-Opaque is server-specific information presented back to the EAP server; PAC-Info can identify the issuer and may carry a lifetime. RFC 4851 requires secure handling of the PAC-Key, while RFC 5422 warns that the peer and server both have storage responsibilities. Provisioning is consequently a transfer of state that creates later custody obligations, not a complete lifecycle policy. Expiry, renewal, secure storage and removal still need owners.

The PAC-Acknowledgement is deliberately narrower. The peer sends it for a newly provisioned Tunnel PAC and reports the result of processing and storing it. Its result is either success or failure. A success value is evidence of what the peer reported at that point; it does not show that a later tunnel can be established, that the secret remained protected, or that a server will authorize network use. Only the later EAP-FAST exchange tests whether the provisioned material works in that authentication context. Even that result is distinct from application reachability. (RFC 5422 §§4.2.2–4.2.5, 6.8; RFC 4851 §3.2.2)

A denied bootstrap can still interrupt service

The boundary has an availability cost. RFC 5422 notes that an EAP Failure after provisioning denial can trigger a full 802.11 disassociation. A peer or server may instead attempt TLS renegotiation so the newly provisioned credentials can support a subsequent authenticated exchange without a complete restart, but either side may reject that request. Normal access policy applies only after the later authentication succeeds. A sound rollout therefore measures both the security decision and the transition: how many peers were provisioned, how many returned, which were denied, and whether a restart or renegotiation completed.

Otherwise operators can mistake a deliberate no-access result for a broken enrollment path—or hide an incomplete credential lifecycle inside a successful provisioning count. (RFC 5422 §3.5)

Sources