[JaredP94]

Description

Out-of-order pairing messages could crash either side or grant trust without the PIN:

• The inviter checked a Completion MAC against a still-empty key when the message arrived before the PIN was applied. An empty-key MAC over the public transcript needs no PIN, so it could reach Registered.
• A key-exchange message before negotiation dereferenced the unselected algorithm and panicked either role. On the joiner that panic held the session lock, so the slot was never reclaimed; repeating it could exhaust the 64 pending sessions.
• The joiner accepted EAP-Success in any state, storing an association without verifying the server's Completion MAC.

Completion now requires derived keys (Waiting, or OOBReceived in the peer-to-server direction this fork still supports); key exchange requires negotiation; EAP-Success is accepted only right after a verified Completion. A terminal protocol error releases the joiner's session.

Ported from NVIDIA#184 (6c8fa90, 4f8b050, and the Success guard from 6a752f6). That PR's wider API cleanup is not included.

Scope

services/eap-noob, services/nvpair-cluster-manager/httpserver.go. No wire change.

Validation

• go test ./... in eap-noob and nvpair-cluster-manager. The new inviter test reproduced the nil-pointer panic before the guard.
• services/tests: all cluster_manager_test.go and tls_test.go cases (pairing, wrong PIN both sides, cancel/decline/expiry, fan-out, leave) — 23 passed.

Risk

Low. Valid pairings follow the same path; only messages that were never valid in that state are refused. nvpair-cluster-manager 2.1.0 → 2.1.1.

Checklist

• I have read the Contributing Guidelines.
• Every commit is signed off (git commit -s), certifying the Developer Certificate of Origin.
• New or existing tests cover the change.
• Relevant documentation is updated.
• I checked the diff, changed filenames, and commit messages for credentials, private data, internal URLs, internal issue identifiers, and generated artifacts.
• I recorded the validation commands and results above.
• I bumped any affected component in services/versions.json, and described user-visible changes above so they reach the release notes.

Part of the upstream issue/PR review. Each branch is independent off main; they all bump services/versions.json, so the second one merged will need a trivial conflict resolution there.