Using Wildcard A and AAAA Resource Records in the DNS for Per-User Host-Based Services

Often users need to run services (often on multi-user systems) that need host-based service principal names. We describe a method for arranging this without having to share sensitive cryptographic host credentials with users: Publish in the DNS a wildcard A and/or AAAA RRset for every hostname on which self-service per-user services will be permitted. This means that for any host named, say, “foo.bar.example”, one would publish “*.foo.bar.example.”, with the same A and/or AAAA RRset as “foo.bar.example.”. Provision users with credentials for host-based service names on hostnames of the form: <username>.<hostname.fqdn>. This allows users to publish “<username>.<hostname-FQDN>” as their services' hostname. For the rest of this document we shorten “per-user host-based service principal” to “PUHBSP”. And that's it. The difficult part, of course, is (2), but it is possible to adjust existing provisioning systems and/or build new ones to address this. See

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

Existing standard and non-standard Kerberos administration and PKIX online certification authority (CA) protocols may be used for self-service key management of PUHBSP credentials with minimal changes. The main change that is needed is an authorization change on the server-side. Example protocols whose services may be modified to suit this purpose: The “Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols” and its non-standard predecessors. The various other non-standard Kerberos administration protocols that provide interfaces for creating principals and setting their credentials. [XXX Add references to various such protocols? There are at least five such protocols known to the editor.] kx509 (a kerberized online CA). Any protocol using PKCS#10 . The principle is general, applying to any authentication mechanism that can authenticate host-based services, not just Kerberos or PKIX.

Three different sorts of authorization decisions are involved: DNS zone administrators decide which hosts get wildcard A/AAAA RRsets. DNS zone administrators MAY safely publish wildcard A and AAAA RRsets for all hostnames in their zones, but they may also keep a white-list of such hostnames. The PUHBSP's credential issuer MUST decide whether to issue credentials for any given sub-domain of a given hostname. This decision MUST be based on and constrained by the requestor's credentials. For example, the issuer might require that a client authenticate with a user and a host-based service credential or that a user have opted-in any given host whose credentials will be used to acquire the PUHBSP's credentials, it might require that the username label of the PUHBSP correspond to an existing user, and so on. Credential issuers SHOULD NOT issue PUHBSP credentials for hostnames with more than one sub-domain label of the actual host's hostname. The credential issuer SHOULD require that hosts themselves SHOULD authorize local requests by local users/processes for credentials for any given sub-domain of the host's hostname. For example, a host might authenticate local users using traditional operating system facilities (e.g., processes' credentials), then decide whether the local user gets to have a requested sub-domain of the host's hostname.

In our deployment it is trivial for users to run their own web services: pick an available port number, locally request credentials (server certificates and/or Kerberos keys) for running a web service on “<local-username>.<hostname-fqdn>:<port>” (for example, https://jdoe.someserver.foo.example:3000/), configure the web service to start on the chosen port number and with the given credentials, then start the service. In this use case no credential acquisition protocols were modified. Instead their services were modified to permit clients with host-based service credentials to acquire credentials for PUHBSPs whose hostname component is a sub-domain of the actual host's.

Some hostnames may be meaningful (e.g., “irc.foo.bar.example” might be taken to mean that an IRC server is located at that hostname). Users may need to be educated as to how to determine that a fully-qualified hostname is a per-user one. Credential issuers SHOULD keep white-lists of users and hostnames that are permitted to have PUHBSPs, though not necessarily white-lists of {username, hostname} that are permitted to have PUHBSPs. Self-service key management services for PKIX SHOULD use an intermediate, online certification authority (CA), rather than a top-level CA, so as to make it possible to revoke the online CA's certificate. (This is good advice for any CA anyways.) Note that this scheme does not support users from more than one realm having PUHBSPs on the same host.

Note that a large number of port numbers for running services are available to all users on most operating systems. This means that a local user could start a proxy on one port and forward to another port on the same host, where the second port is a service run by a different user. Mutual authentication generally protects against this attack.

Hypertext Transfer Protocol (HTTP) used with the SPNEGO-based HTTP authentication method is quite common in some environments. Negotiate does not make use of session keys to protect HTTP data and metadata. To safeguard against this, per-user HTTP services MUST use Transport Layer Security (TLS) , not just SPNEGO.

There are no IANA considerations in this document.