Summary

  • RFC 1507 tried to replace a collection of machine-local accounts with a network-recognized principal whose identity could survive a user's choice of login host.
  • Its 1993 design tied public-key certificates to a distributed naming hierarchy. The same tree helped bound a certification authority's reach, but also became a dependency for certificate discovery and rapid revocation.
  • DASS was published as an Experimental Protocol, not an Internet Standard. The specification shows what its designers proposed; it does not establish implementation or adoption.

Ten machines, ten accounts

The opening problem in RFC 1507 is not a cipher. It is a list of accounts. If one person has an account on ten computers, a remote service may have to learn all ten names before it can grant that person access. A new account creates another update. Moving between machines changes which local account appears at the far end of the connection.

Charles Kaufman's September 1993 proposal, the Distributed Authentication Security Service (DASS), aimed to make that person legible as one principal across nodes. A global name would identify the user even when a request passed through a chosen login machine. A resource could still make a narrower access-control decision—allowing a user only through a particular node, for example—but the user's identity would not have to collapse into the account name on that node.

This was a design ambition, not an assertion that local accounts had already disappeared. DASS explicitly expected operating systems to continue mapping users to local accounts. Its bridge was familiar: extend .rhosts-style rules so a local account could trust a DASS global name without listing every intermediate machine from which that user might arrive. The proposal tried to move the identity that travelled across the network while leaving the final account and resource decision close to the receiving host.

A name needed a key behind it

A global name alone could not prove who was speaking. DASS therefore used public-key cryptography, chiefly RSA in the specification, to let a principal demonstrate possession of a private key without sending that secret across each network connection. A certificate joined a name to a public key and was signed by a certification authority (CA) trusted to make that introduction.

The design treated both people and machines as principals. In a common case, the user and the node from which the request originated could each contribute credentials. Both could sign the request, allowing a remote server to distinguish “this user” from “this machine carrying the user.” That distinction mattered when a resource wanted to trust the person only from a particular host, or when a machine's identity mattered independently of the person logged in there.

The certificate chain followed the directory. DASS used the X.500 hierarchy for principal names and linked CA responsibility to directories in that tree. A verifier could start from a known CA key, follow parent and child certificates, and use a cross-certificate when two parts of the namespace were distant. The point was not to find one universal CA that knew every user. A local CA could certify principals in its own directory, while cross-certification connected parts of the tree.

This arrangement narrowed some risks without removing trust. The RFC says a compromised CA could impersonate principals within its directory; the scope of a lower-level compromise followed the relevant part of the naming hierarchy. The tree therefore did two jobs. It provided a route for finding keys, and it described where a CA's power could reach. A directory branch was not just a filing convention. It became part of the system's security boundary.

The login host became a temporary delegate

DASS also addressed the hop after login. A user might start a process on one computer that asked another service for data, and that service might need to call a third. Requiring the user to re-enter a password at each hop would defeat the goal of a network login. DASS let credentials travel with a process so a service could act on the user's behalf.

The design tried to limit how much the user had to trust each machine. A login node could use the user's secret to create credentials, and the architecture expected those secrets to be discarded when the user logged out. A service received the ability to impersonate the user for a limited time. But the RFC is candid about the boundary of that protection: this version limited delegation by time, not by the specific rights required for one service. A future version might have offered narrower delegation. The 1993 specification did not.

The first link remained weaker than the later cryptographic exchange. Before smart cards were available, the initial password-based login could still be exposed to eavesdropping. The design aimed to keep the password off the network after that first node, and argued that a smart card could keep the user's private key while signing at login. That is a stated architecture and future direction, not evidence that smart cards or DASS deployment were widespread.

Time and directories were part of authentication

DASS chose timestamps rather than challenge-and-response for replay protection. A signed authentication message included the current time; a verifier rejected messages outside its allowed clock window and remembered messages already seen inside that interval. The choice reduced the number of exchanges and allowed authentication data to accompany connection setup, but it made clock quality operationally important.

The RFC separates two time needs. Certificate and ticket validation could tolerate time accurate within hours. Replay detection needed a monotonic source synchronized across machines within minutes, and the verifier had to retain recently seen authenticators. Excessive drift could reject legitimate requests. A clock turned backward could make an expired message acceptable again. These were not abstract cryptographic edge cases: time service and verifier state were dependencies of the authentication path.

Certificate revocation made the naming service an even clearer control point. DASS described two supported methods. The first was expiry and renewal. The RFC expected ordinary certificates to last about a year and said renewal periods could be measured in months to keep CA workload and user communication manageable. That reduced routine load, but it made revocation slow after a key compromise.

The second method was to publish only non-revoked certificates in the naming service and accept a certificate only while it remained there. The specification described this as nearly immediate, with delay from directory propagation and caching. It also stated the trade: authentication availability would depend on naming-service availability, while revocation security would depend on the service's security. The third method a reader might expect—periodic X.509 revocation lists—was not supported by DASS at that time.

The tree that made a user's name portable therefore also carried the state needed to decide whether that user's certificate could still be believed. A successful signature could show that a request used the private key corresponding to a certificate. It could not, on its own, show that the certificate was still present in the right naming service, that an update had propagated, or that the receiving resource authorized the requested operation.

An experimental design, not a deployment record

RFC 1507 is explicit about its status: Experimental, and not an Internet Standard. Its annex describes how DASS could support the Generic Security Service API. The neighboring RFC 1508 defined that API as a mechanism-independent interface, while RFC 1509 specified its C bindings. These documents show that DASS was designed to fit an application-facing security architecture. They do not show how many applications or operators used it.

The period also contained other approaches. RFC 1510 documented Kerberos V5, which used a trusted key-distribution service; RFC 1704 later surveyed several authentication mechanisms. Those documents help place DASS among contemporary proposals. They do not establish a contest with a measured winner, or explain DASS's subsequent fate.

What RFC 1507 makes visible is a particular answer to the mobility problem. Instead of treating a user as a set of separate accounts, it proposed a principal that could be authenticated across machines. It joined that identity to public keys, local CA responsibility, process credentials and a distributed naming service. The architecture made the chain inspectable—but only if the name, certificate path, time assumptions, delegation and revocation state remained distinct.

Sources