Summary

  • RFC 3079 used master values only as inputs to further derivation. Separate role- and direction-labelled branches produced transient send and receive keys, which then initialized distinct RC4 contexts.
  • A correct calculation established one bounded fact: particular inputs produced particular bytes. It did not prove that both peers chose the same first authentication, mapped send to receive correctly, negotiated the same MPPE mode, transported secrets safely, synchronized cipher state or delivered application data.

A master value with no packets of its own

The most useful sentence in RFC 3079 is a negative one. The master session keys are never used to encrypt or decrypt data. They exist only to derive transient session keys.

That rule turns what sounds like a supreme credential into an intermediate object. Under MS-CHAP-2, the password lineage and NT-Response first produced a sixteen-octet master value. A second function selected a branch according to two facts: whether the desired key was for sending, and whether the local endpoint was the server. A third step produced the transient key. Only then did the implementation initialize an outbound or inbound RC4 table.

The distinction was operational, not semantic decoration. If a system logged only “master key derived,” it had not shown which branch it took, which direction received the result or whether the result entered a traffic context. A locally correct master could feed the wrong role label. Two equal-length transient values could belong to different sessions. A byte string could match a published test vector while the live call used the wrong authentication event.

RFC 3079 therefore documented a chain of custody inside the algorithm itself. The chain began with credential evidence, crossed a labelled derivation boundary, created per-direction transient material, and ended at a cipher context. Each link had a narrower meaning than the convenient word “key” suggested.

Three credential families did not erase their origins

Published in March 2001 as an Informational RFC, RFC 3079 aimed to give third-party implementers an open reference for interoperability with Microsoft products. It did not define MPPE negotiation, packet encryption or in-session rekeying; RFC 3078 owned those mechanisms. Nor did publication make the memo an Internet Standard or prove that a product implemented every branch correctly.

The document described three upstream families. MS-CHAP-1 derived 40- and 56-bit material from the LAN Manager password hash and the 128-bit branch from the Windows NT password hash plus the authenticator challenge. MS-CHAP-2 used the Windows NT password lineage and its NT-Response for all three strengths. EAP-TLS began from exported TLS keying material.

Those paths converged on MPPE traffic keys, but they did not become interchangeable evidence. A monitor needed to know which authentication family ran, which peer supplied the credentials, which challenge or response was used, and which credential event the session treated as first. “Eight bytes installed” could describe either 40- or 56-bit mode; “sixteen bytes installed” could describe 128-bit material from distinct credential histories.

RFC 2759 defined the peer challenge, authenticator challenge, username-dependent challenge hash, NT-Response and authenticator response for MS-CHAP-2. RFC 2433 supplied the earlier MS-CHAP procedures. RFC 2716 described EAP-TLS inside PPP. These documents could establish upstream inputs. None by itself showed that CCP later opened or that user data crossed the link under the intended MPPE state.

The first authentication became part of session identity

For MS-CHAP-derived keys, RFC 3079 chose a surprisingly specific lineage rule. The initial keys in both directions came from the credentials of the peer that initiated the call. If challenges were involved, the derivation used the challenge or challenges from the first authentication. This remained true for unilateral and bilateral authentication and for each link in a multilink bundle.

The phrase “first authentication” is easy to lose in an implementation assembled from independent subsystems. An authentication service might retain only the most recent successful exchange. A multilink controller might merge links without keeping the credential event that seeded each one. A failover node might know that a user authenticated but not which challenge/response pair belonged to the active derivation epoch.

RFC 3079 did not solve that distribution problem. In a multi-chassis multilink case, it explicitly made implementations responsible for ensuring that the correct keys were generated on all participating machines. The formula was deterministic only after the system supplied the right history. Replicating a username and a success flag was not enough.

This is where an apparently mathematical specification becomes an operations story. The real session identifier was not merely a PPP handle. It included the chosen credential event, endpoint roles, link membership and derivation generation. Without those coordinates, identical code could deterministically produce the wrong answer.

Direction was a relationship, not a local label

MS-CHAP-2's GetAsymmetricStartKey used fixed labels to split a master value into direction-specific branches. The selected label changed with IsSend and IsServer. On the server, the send branch used the label that the client used for receive; the other label paired server receive with client send.

RFC 3079 made the invariant explicit again in its EAP-TLS discussion: the send key on one side is the receive key on the other. “Send” had meaning only relative to an endpoint. A configuration export that copied send_key from one machine into a field also called send_key on its peer would preserve the word while reversing the relationship.

That is why two one-sided success records do not prove a working pair. Each endpoint can report that it derived and installed a key of the expected length. Both reports can be true while the traffic fails because one endpoint chose the client role twice, swapped inbound and outbound contexts or associated the result with another link in the bundle.

The proper receipt joins both perspectives: endpoint identity, client/server role, local direction, peer direction, credential-generation fingerprint and transient-key fingerprint. It should prove that outbound A equals inbound B and outbound B equals inbound A without exposing the secrets themselves.

Strength was transformed after derivation

The 40-, 56- and 128-bit branches were not simply the same buffer with three labels. The 40- and 56-bit modes used eight-octet transient values, while 128-bit mode used sixteen. For 40-bit mode, the first three octets were overwritten with fixed constants. For 56-bit mode, the first octet was overwritten. The effective strength was deliberately reduced after the earlier derivation steps.

EAP-TLS added another interface rule. An asymmetric master value shorter than the target length had to be padded on the left; one longer than the target had to be truncated. A normal-looking target length could therefore conceal a different original length and normalization path.

RFC 3079 supplied complete sample values so implementers could test the arithmetic. Those vectors were valuable running-code aids, but they proved only conformance to chosen inputs. They did not authenticate a live user's password, validate the transport of EAP-TLS material, show that both sides negotiated 128 rather than 40 bits, or demonstrate that the initialized tables ever processed a packet.

The security section exposed the cost of treating mode names as sufficient evidence. With MS-CHAP-1, the initial 40-bit key was identical across sessions under the same peer credentials. The RFC advised avoiding that branch when possible, citing both repetition and the weakness of 40-bit RC4. For password-derived modes generally, security inherited password quality. For EAP-TLS, it inherited TLS security and the handling of exported secrets.

Historical fidelity requires keeping those warnings in their period. This article does not recommend RC4, LAN Manager hashes or classic MS-CHAP. It explains how the specification itself bounded what its derivation could prove.

The derivation boundary ended before the encrypted service began

RFC 3078 required PPP to reach the Network-Layer Protocol phase and CCP to reach Opened before MPPE packets were sent. The parties still had to negotiate a strength and state mode, initialize matching contexts, advance them correctly and recover from loss. RFC 2548 addressed another adjacent problem: carrying already-produced send and receive keys through RADIUS, where proxies could become custodians by decrypting and re-encrypting protected attributes.

Those later and adjacent transitions cannot be collapsed into RFC 3079. Authentication success did not mean a master value reached the PPP authenticator. Receipt of key material did not mean it was assigned to the correct link. Correct direction mapping did not mean CCP chose MPPE. Opened CCP did not mean cipher state stayed synchronized. Decryption of a packet did not mean an application accepted it.

This is Lu Heng's reality-layer discipline applied to an old interoperability memo. Symbolic names—master, send, receive, authenticated, 128-bit—can hide the transformations between layers. Running code matters because only execution connects them, but running code also needs receipts precise enough to show which transition actually occurred.

The historical contribution of RFC 3079 was not just publishing formulas. It exposed that interoperability depends on provenance. The master key was not the traffic key. Direction was not a string local to one box. A successful derivation was a necessary receipt, not the whole service.

Sources