Summary

  • RFC 3157 required credential mobility to protect confidentiality and integrity, but it did not treat encrypted storage as the absence of trust. A credential server could remain unable to use a protected key while retaining power over its availability and lifecycle.
  • The requirements supported both server-based and direct device-to-device transfer. The first concentrated durable storage and policy; the second traded that concentration for device-pair, authentication and receipt complexity.
  • A successful upload, download or authenticated acknowledgement proves only the operation it names. It does not prove safe destination storage, erasure of other copies, authority for later actions, peer acceptance or application outcome.

One identity had begun to outlive one machine

The simple model was physically easy to understand. A user generated a key pair on one desktop, sent the public portion to a certification authority and kept the private portion on that machine. The key did not travel. The machine, local storage and identity appeared to share one fate.

By 2001 that model was under pressure. The same person might sign mail in an office from a desktop and on the road from a laptop. Another might need to decrypt mail from a phone or two-way pager. A router might be replaced while its peers continued to rely on the old public key. Reconfiguring every peer simply because the chassis changed imposed a coordination cost.

RFC 3157 called the broader problem credential mobility. Credentials included private keys, trusted roots, tickets and private parts of a Personal Security Environment. Their later use might support S/MIME, IPsec or TLS, but the requirements document did not redefine those systems. Its object was the safe movement of the material that let another device continue an established security identity.

The phrase “move the identity” was useful in the router story and dangerous if read literally. What moved was credential material and the ability to demonstrate continuity under the relying parties' existing rules. The old device, the new chassis, the administrator, the credential issuer, the peer configuration and the running traffic remained different objects. A copied key could preserve one cryptographic relationship without proving that every surrounding authority followed it.

The framework kept two architectures alive

RFC 3157 required the SACRED framework to support both a credential-server solution and a direct-transfer solution. This was not a cosmetic choice between two network diagrams. Each architecture assigned power and failure differently.

The credential server sat before a repository and participated actively in security enforcement. A device could upload protected credentials, leave them available for an arbitrary interval and later download them to another device. The model resembled familiar client-server protocols. It could offer durable storage and a place for an organization to enforce a uniform handling policy.

That convenience created a concentrated dependency. The server had to be operated, made reliable and defended. Users had to discover or configure it. Its repository became an object worth copying, damaging or denying. An organization could gain policy consistency, while a traveler could discover that the same central point was unavailable precisely when a new device needed the credential.

Direct transfer removed long-term storage at an intermediary. Network nodes could still forward packets, but they did not thereby become credential servers. The cost moved outward. Devices could differ in format, interface, authentication method, transport support and ability to be online together. Each side needed confidence about the other, and the sender needed a trustworthy receipt if delivery mattered.

The requirements did not announce one architecture as universally correct. They preserved the distinction so an implementation could not claim the benefits of one while silently inheriting the powers of the other.

Ciphertext did not make the server powerless

One of the general requirements was deliberately narrow: the protocol must not force credentials to appear in plaintext at any device other than the end user's. That was a confidentiality boundary. It prevented the transfer design from requiring a server to unwrap every private key merely to store or forward it.

It did not say the server had no power. A repository operator could still control whether an object existed, whether it could be found, which version was returned, whether an upload replaced it and whether a delete operation removed it. Someone with access might be unable to derive a usable private key and still be able to erase the server's copy.

Even “erase the credential” needs a bounded meaning. Deleting the repository record did not prove that every device copy, backup, cache or export vanished. Nor did it necessarily destroy the external identity: peers might retain the public key, and another private copy might survive. The proved event was a mutation in one repository under one operation.

Availability was likewise separate from disclosure. RFC 3157 described credential servers as major denial-of-service targets. Preventing the operator or attacker from reading the key did not ensure that a user could acquire it when needed. Confidential but unreachable material could still interrupt a signed-mail workflow, a router replacement or another dependency on identity continuity.

This is the document's most durable boundary. Cryptographic secrecy constrains who can learn or use protected material. It does not automatically constrain who can withhold, replace, roll back, delete or refuse to serve it.

The operation name defined the receipt

The server model needed more than a generic “sync” verb. RFC 3157 required operations for users to manage stored credentials: retrieve a list, add credentials, delete them and change authentication information. It also required self-enrollment support and allowed administrative bulk initialization.

Each operation had a different authority surface. Listing revealed inventory, not secret plaintext. Download released an object to a device. Upload created or replaced server state. Delete removed server-side state. Password change altered the future authentication boundary. Self-enrollment established an account relationship. One successful operation did not authorize the next.

User authentication before download answered a bounded question about who was requesting access under the protocol's account model. Server authentication helped prevent the client from surrendering secrets or accepting credentials from an impostor. Credential authentication could help detect substitution or corruption of the transferred object.

Those checks still did not prove that the destination machine was trustworthy. A correct user could authenticate from compromised software. A genuine server could deliver an old but valid protected object. A cryptographically authentic credential could later be used for an action the human did not authorize. Identity proof, object integrity, device assurance and action permission remained different decisions.

The later RFC 3767 protocol made another distinction explicit: an account password could authenticate access to the server, while a separate credential password could protect parts of the downloaded credential. Conflating them would give one successful check more authority than it owned.

Opaque formats narrowed coordination rather than evidence

RFC 3157 required credential type and internal format to be opaque to the transfer peers. The protocol was not supposed to depend on understanding every private key, ticket or protected container. It also had to allow different user-authentication methods and transports.

This was a minimum common surface. It reduced the number of semantic agreements required before two systems could move a protected object. A constrained device did not have to adopt every other device's internal representation merely because both participated in the same framework.

Opacity was not validation. A server able to store an object without understanding it could not infer that the destination application would parse it, that the contained algorithms remained acceptable, that the certificate chain still validated or that the credential matched the intended account. The same abstraction that improved portability limited what intermediate success could prove.

Mandatory-to-support choices provided an interoperability floor. They were not evidence that every product supported every credential type, authenticator and transport, or that two claimed implementations shared a working combination. Only negotiation and running exchange could establish the path actually used.

Direct transfer needed an authenticated ending

Without a repository, the sender and receiver had to establish a different chain. RFC 3157 said the receiving device should be able to authenticate the sending device. After receipt, the receiver should be able to return an acknowledgement that the sender could authenticate.

That acknowledgement mattered because silence left several states indistinguishable. The object might still be in flight, rejected, corrupted, stored or lost after arrival. An authenticated receipt narrowed the uncertainty: a peer participating under the protocol had acknowledged receiving a credential.

It did not prove exclusivity. The sender might retain another copy. An intermediary might have captured ciphertext. The receiver might acknowledge before durable storage, or store the object in a weak environment. A later application might reject it. The user might never have intended the operation even though a device possessed valid authentication material.

Deleting the source only after a receipt would be a separate policy and a separate observable action. Calling the whole sequence “move” could hide the period in which two usable copies existed, or the failure mode in which neither side retained a good one.

Auditing could become a second disclosure path

RFC 3157 asked implementations, especially servers, to audit security-relevant events. Useful records could include time, account, operation and result. That evidence helped distinguish an attempted download from a completed one, a user deletion from repository failure and ordinary unavailability from an attack.

The document also warned the audit path not to collect the secret it was meant to protect. A user might accidentally type a password into a username field. If raw input were copied into logs, the system could preserve a credential in the least protected and most widely replicated part of the operation.

This tension is not solved by “logging everything.” A durable receipt needs enough identity and operation context for investigation while excluding passwords, private keys and other reusable secret material. Logs also require their own access, integrity, retention and clock evidence.

An audit entry saying “download succeeded” does not prove which protected object reached which storage surface. A complete investigation joins the entry to the identity of the protected payload, protocol transcript, destination device, local import, later use and the application result.

Hardware containment answered a different question

The appendix considered smart cards and other hardware tokens. If the credential stayed inside portable hardware, a user could carry the token among compatible devices without copying the private material between hosts. That offered a stronger containment model in some environments.

It was not a universal replacement. Devices did not all have the same reader. Tokens had cost, compatibility and failure modes. Organizations might reject them for operational reasons. SACRED-style protocols could also complement hardware by updating credentials on a token without returning it physically to an administrator.

RFC 3157 therefore limited its main requirements to software-based credentials and acknowledged their different security posture. The honest comparison was not “hardware secure, software insecure.” It was which material leaves which boundary, which devices can participate, how failure and recovery work, and which party can interrupt continuity.

The requirement document did not prove any smart card, phone, pager or workstation was safe. It described architectures that future protocols could use when the physical containment option was unavailable or insufficient.

The later protocol implemented only one path through the space

RFC 3760 later provided an abstract framework, and RFC 3767 defined a standards-track credential-server protocol with XML messages and a BEEP profile. It used TLS and/or DIGEST-MD5 support to meet transport and authentication requirements and distinguished runtime retrieval from optional account-management operations.

That lineage shows specification work moving from problem, to framework, to a concrete protocol. It does not show that every RFC 3157 requirement was deployed, that direct transfer became common, or that a particular product protected credentials correctly.

RFC 3767's concern about offline dictionary attacks also illustrates the receipt boundary. A protocol can avoid handing an eavesdropper useful password-verification material and still depend on password quality, endpoint software, server availability and correct credential encryption. Resistance to one attack does not confer universal account safety.

The historical value of RFC 3157 lies in what it refused to compress. Transfer confidentiality, repository authority, durable availability, device authentication, receipt, storage, identity continuity and later use were related, but none was a synonym for another.

A mobile credential widened the evidence surface

The old one-machine model concentrated risk in one place. Mobility improved recoverability and convenience but created more transitions. Every upload, repository mutation, download, direct handoff, import and use became a point at which identity could be copied, withheld, substituted or misunderstood.

A durable audit begins with the credential's issuer and protected-object fingerprint. It identifies whether the transfer was server-based or direct; records user and server authentication separately; names the requested operation; preserves version and integrity evidence; records repository state and availability; identifies the destination device and trusted-software assumptions; and follows the credential into the relying protocol and service outcome.

If a router accepted the old key and traffic resumed, that proved more than a successful download. If the new device stored the key but peers rejected it, transport success had not restored identity continuity. If peers accepted it but an unauthorized administrator initiated the migration, cryptographic continuity had not supplied administrative authority.

RFC 3157's lasting insight was not merely that keys could travel. It was that protecting the secret during travel did not eliminate the institutions and machines that controlled whether it arrived, survived and mattered. The server did not need the plaintext to remain powerful.

Sources