Summary

  • RFC 1472 placed PPP authentication-protocol preferences and identity/secret pairs in management tables, with explicit link scope, direction, protocol and status.
  • A row marked valid was eligible configuration. Authentication still required a later PAP or CHAP exchange, an authenticator's result and a separately opened network layer.

The strange thing about the PPP Security MIB was not that it contained secrets. It was that the document refused to let their presence answer the wrong question.

Published in June 1993, RFC 1472 defined managed objects for the security protocols used with Point-to-Point Protocol links. It belonged to a family of companion MIBs. RFC 1471 dealt with Link Control Protocol management; RFC 1472 isolated authentication configuration in its own optional security group.

That separation exposed three different control surfaces: what a manager intended to configure, what an agent currently held, and what two PPP endpoints later did on a link. The MIB made the first two inspectable. It did not manufacture the third.

One table chose what to try

The configuration table indexed a row by link and preference. Its protocol field named an authentication protocol to attempt. Lower preference numbers were tried first. Link value zero acted as a default for links without explicit entries.

Each word was bounded. “Preference” described order, not success probability or security strength. “Protocol” named the mechanism to be attempted, not an exchange already observed. “Default” filled a configuration gap; it did not prove that every link inherited the row, that no link-specific row shadowed it, or that a peer supported the choice.

The status field sharpened the point. A row could be valid or invalid. Setting it to invalid stopped the row from being current configuration, but removing it was implementation-specific. A management station had to be prepared to receive rows that were still present and no longer in use, and had to examine status to interpret them.

Existence therefore was not currentness. The table itself said so.

The second table stored pairs, not people

The secrets table carried one or more ID/Secret pairs for a link. An index distinguished multiple pairs. RFC 1472 explicitly left the choice among them to the local implementation.

Direction mattered. local-to-remote meant that the local PPP entity could use the pair while authenticating itself to the remote entity. remote-to-local meant that the local entity expected the remote peer to use it. The same-looking row therefore changed operational meaning when its direction changed.

Protocol mattered too. For PAP, the identity field could hold a Peer-ID and the secret a password. For CHAP-MD5, the identity could hold the CHAP Name and the secret the material used in the response calculation. RFC 1472 deliberately described both fields as octet strings whose semantics depended on the selected protocol.

An identity string was not a person, an account entitlement or proof of who was on the wire. A secret value was not evidence of custody at a particular time. A valid status did not say which of several pairs the local implementation selected, whether the peer presented the expected value, or whether an authenticator accepted it.

This is the core historical boundary: the row was an input to a possible event.

The event lived in another protocol

The contemporary RFC 1334 defined the missing PAP and CHAP actions. PAP sent a Peer-ID/Password pair after link establishment and waited for an Authenticate-Ack or Authenticate-Nak. The later RFC 1994 specified CHAP as a challenge, a calculated response, the authenticator's comparison and an acknowledgement or failure, with possible later challenges.

Those messages created evidence that the MIB row could not contain. An audit needed to know which link existed, which authentication protocol had been negotiated, which request or challenge belonged to which response, what credential version the authenticator used, and what result it produced.

Even that result stopped at another boundary. RFC 1661 kept PPP phases in order: establish and test the data link, optionally authenticate the peer, then use Network Control Protocols to configure network-layer protocols. Only after an NCP opened could its network-layer datagrams flow.

A configured credential did not prove authentication. Authentication did not prove IP configuration. IP configuration did not prove a remote route, packet receipt or application result.

The management path was itself sensitive

RFC 1472 made the security group optional because its controls were dangerous. It exposed peer identities, secrets and the variables that selected authentication behavior. An intruder who could read the subtree could obtain sensitive material; one who could change it could disable or redirect security behavior.

The RFC strongly advised against implementing the group without SNMPv2 privacy. It suggested protected MIB views or making the subtree inaccessible. Making variables read-only reduced write power but still left the reading risk, which the text expressly called out.

That guidance did not turn a protected management session into a PPP authentication result. It protected the administrative path by which configuration was viewed or changed. The data-plane peer still had to perform its own exchange.

The architecture therefore contained a useful asymmetry. The more powerful the management abstraction became, the more tightly access to it had to be bounded. Centralising credentials simplified administration while concentrating the consequences of a mistaken default, a stale row, an exposed view or an unauthorized write.

A status word needed a ledger around it

An operator trying to reconstruct a link should not begin with “Was the secret valid?” The question compresses too many receipts.

The useful chain records the manager's requested change; the agent's committed row; link scope and any default inheritance; protocol preference; pair index, direction and status; protected readback; the LCP-negotiated authentication protocol; the PAP request or CHAP challenge/response; the authenticator's decision; the NCP state; and later traffic observations.

Each transition needs an actor and time. A retained invalid row is harmless history only if the runtime did not select it. A valid row that was never selected is configuration inventory, not failed authentication. A successful authentication tied to an unknown credential version is an attribution gap. A link that authenticates but never opens IPCP is not an authentication failure.

RFC 1472's enduring value lies in this refusal to let management vocabulary impersonate operational proof. The MIB could say what the system was prepared to try. The wire still had to answer what happened.

Sources