Internet RFC/STD/FYI/BCP Archives
Alternate Formats: rfc1507.txt | rfc1507.txt.pdf
Network Working Group C. Kaufman
Request for Comments: 1507 Digital Equipment Corporation
September 1993
DASS
Distributed Authentication Security Service
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard. Discussion and
suggestions for improvement are requested. Please refer to the
current edition of the "Internet Official Protocol Standards" for the
standardization state and status of this protocol. Distribution of
this memo is unlimited.
Table of Contents
1. Introduction ................................................ 2
1.1 What is DASS? .......................................... 2
1.2 Central Concepts ....................................... 4
1.3 What This Document Won't Tell You ..................... 11
1.4 The Relationship between DASS and ISO Standards ....... 17
1.5 An Authentication Walkthrough ......................... 20
2. Services Used .............................................. 25
2.1 Time Service .......................................... 25
2.2 Random Numbers ........................................ 26
2.3 Naming Service ........................................ 26
3. Services Provided .......................................... 37
3.1 Certificate Contents .................................. 38
3.2 Encrypted Private Key Structure ....................... 40
3.3 Authentication Tokens ................................. 40
3.4 Credentials ........................................... 43
3.5 CA State .............................................. 47
3.6 Data types used in the routines ....................... 47
3.7 Error conditions ...................................... 49
3.8 Certificate Maintenance Functions ..................... 49
3.9 Credential Maintenance Functions ...................... 55
3.10 Authentication Procedures ............................. 63
3.11 DASSlessness Determination Functions .................. 87
4. Certificate and message formats ............................ 89
4.1 ASN.1 encodings ....................................... 89
4.2 Encoding Rules ........................................ 96
4.3 Version numbers and forward compatibility ............. 96
4.4 Cryptographic Encodings ............................... 97
Annex A - Typical Usage ........................................ 101
A.1 Creating a CA ........................................ 101
A.2 Creating a User Principal ............................ 102
A.3 Creating a Server Principal .......................... 103
A.4 Booting a Server Principal ........................... 103
A.5 A user logs on to the network ........................ 103
A.6 An Rlogin (TCP/IP) connection is made ................ 104
A.7 A Transport-Independent Connection ................... 104
Annex B - Support of the GSSAPI ................................ 104
B.1 Summary of GSSAPI .................................... 105
B.2 Implementation of GSSAPI over DASS ................... 106
B.3 Syntax ............................................... 110
Annex C - Imported ASN.1 definitions ........................... 112
Glossary ....................................................... 114
Security Considerations ......................................... 119
Author's Address ................................................ 119
Figures
Figure 1 - Authentication Exchange Overview .................... 24
1. Introduction
1.1 What is DASS?
Authentication is a security service. The goal of authentication is
to reliably learn the name of the originator of a message or request.
The classic way by which people authenticate to computers (and by
which computers authenticate to one another) is by supplying a
password. There are a number of problems with existing password
based schemes which DASS attempts to solve. The goal of DASS is to
provide authentication services in a distributed environment which
are both more secure (more difficult for a bad guy to impersonate a
good guy) and easier to use than existing mechanisms.
In a distributed environment, authentication is particularly
challenging. Users do not simply log on to one machine and use
resources there. Users start processes on one machine which may
request services on another. In some cases, the second system must
request services from a third system on behalf of the user. Further,
given current network technology, it is fairly easy to eavesdrop on
conversations between computers and pick up any passwords that might
be going by.
DASS uses cryptographic mechanisms to provide "strong, mutual"
authentication. Mutual authentication means that the two parties
communicating each reliably learn the name of the other. Strong
authentication means that in the exchange neither obtains any
information that it could use to impersonate the other to a third
party. This can't be done with passwords alone. Mutual
authentication can be done with passwords by having a "sign" and a
"counter-sign" which the two parties must utter to assure one another
of their identities. But whichever party speaks first reveals
information which can be used by the second (unauthenticated) party
to impersonate it. Longer sequences (often seen in spy movies)
cannot solve the problem in general. Further, anyone who can
eavesdrop on the conversation can impersonate either party in a
subsequent conversation (unless passwords are only good once).
Cryptography provides a means whereby one can prove knowledge of a
secret without revealing it. People cannot execute cryptographic
algorithms in their heads, and thus cannot strongly authenticate to
computers directly. DASS lays the groundwork for "smart cards":
microcomputers sealed in credit cards which when activated by a PIN
will strongly authenticate to a computer. Until smart cards are
available, the first link from a user to a DASS node remains
vulnerable to eavesdropping. DASS mechanisms are constructed so that
after the initial authentication, smart card or password based
authentication looks the same.
Today, systems are constructed to think of user identities in terms
of accounts on individual computers. If I have accounts on ten
machines, there is no way a priori to see that those ten accounts all
belong to the same individual. If I want to be able to access a
resource through any of the ten machines, I must tell the resource
about all ten accounts. I must also tell the resource when I get an
eleventh account.
DASS supports the concept of global identity and network login. A
user is assigned a name from a global namespace and that name will be
recognized by any node in the network. (In some cases, a resource
may be configured as accessible only by a particular user acting
through a particular node. That is an access control decision, and
it is supported by DASS, but the user is still known by his global
identity). From a practical point of view, this means that a user
can have a single password (or smart card) which can be used on all
systems which allow him access and access control mechanisms can
conveniently give access to a user through any computer the user
happens to be logged into. Because a single user secret is good on
all systems, it should never be necessary for a user to enter a
password other than at initial login. Because cryptographic
mechanisms are used, the password should never appear on the network
beyond the initial login node.
DASS was designed as a component of the Distributed System Security
Architecture (DSSA) (see "The Digital Distributed System Security
Architecture" by M. Gasser, A. Goldstein, C. Kaufman, and B. Lampson,
1989 National Computer Security Conference). It is a goal of DSSA
that access control on all systems be based on users' global names
and the concept of "accounts" on computers eventually be replaced
with unnamed rights to execute processes on those computers. Until
this happens, computers will continue to support the concept of
"local accounts" and access controls on resources on those systems
will still be based on those accounts. There is today within the
Berkeley rtools running over the Internet Protocol suite the concept
of a ".rhosts database" which gives access to local accounts from
remote accounts. We envision that those databases will be extended
to support granting access to local accounts based on DASS global
names as a bridge between the past and the future. DASS should
greatly simplify the administration of those databases for the
(presumably common) case where a user should be granted access to an
account ignoring his choice of intermediate systems.
1.2 Central Concepts
1.2.1 Strong Authentication with Public Keys
DASS makes heavy use of the RSA Public Key cryptosystem. The
important properties of the RSA algorithms for purposes of this
discussion are:
- It supports the creation of a public/private key pair, where
operations with one key of the pair reverse the operations of
the other, but it is computationally infeasible to derive the
private key from the public key.
- It supports the "signing" of a message with the private key,
after which anyone knowing the public key can "verify" the
signature and know that it was constructed with knowledge of
the private key and that the message was not subsequently
altered.
- It supports the "enciphering" of a message by anyone knowing
the public key such that only someone with knowledge of the
private key can recover the message.
With access to the RSA algorithms, it is easy to see how one could
construct a "strong" authentication mechanism. Each "principal"
(user or computer) would construct a public/private key pair, publish
the public key, and keep secret the private key. To authenticate to
you, I would write a message, sign it with my private key, and send
it to you. You would verify the message using my public key and know
the message came from me. If mutual authentication were desired, you
could create an acknowledgment and sign it with your private key; I
could verify it with your public key and I would know you received my
message.
The authentication algorithms used by DASS are considerably more
complex than those described in the paragraph above in order to deal
with a large number of practical concerns including subtle security
threats. Some of these are discussed below.
1.2.2 Timestamps vs. Challenge/Response
Cryptosystems give you the ability to sign messages so that the
receiver has assurance that the signer of the message knew some
cryptographic secret. Free-standing public key based authentication
is sufficiently expensive that it is unlikely that anyone would want
to sign every message of an interactive communication, and even if
they did they would still face the threat of someone rearranging the
messages or playing them multiple times. Authentication generally
takes place in the context of establishing some sort of "connection,"
where a conversation will ensue under the auspices of the single
peer-entity authentication. This connection might be
cryptographically protected against modification or reordering of the
messages, but any such protection would be largely independent of the
authentication which occurred at the start of the connection. DASS
provides as a side effect of authentication the provision of a shared
key which may be used for this purpose.
If in our simple minded authentication above, I signed the message
"It's really me!" with my private key and sent it to you, you could
verify the signature and know the message came from me and give the
connection in which this message arrived access to my resources.
Anyone watching this message over the network, however, could replay
it to any server (just like a password!) and impersonate me. It is
important that the message I send you only be accepted by you and
only once. I can prevent the message from being useful at any other
server by including your name in the message. You will only accept
the message if you see your name in it. Keeping you from accepting
the message twice is harder.
There are two "standard" ways of providing this replay protection.
One is called challenge/response and the other is called timestamp-
based. In a challenge response type scheme, I tell you I want to
authenticate, you generate a "challenge" (generally a number), and I
include the challenge in the message I sign. You will only accept a
message if it contains the recently generated challenge and you will
make sure you never issue the same challenge to me twice (either by
using a sequence number, a timestamp, or a random number big enough
that the probability of a duplicate is negligible). In the
timestamp-based scheme, I include the current time in my message.
You have a rule that you will not accept messages more than - say -
five minutes old and you keep track of all messages you've seen in
the last five minutes. If someone replays the message within five
minutes, you will reject it because you will remember you've seen it
before; if someone replays it after five minutes, you will reject it
as timed out.
The disadvantage of the challenge/response based scheme is that it
requires extra messages. While one-way authentication could
otherwise be done with a single message and mutual authentication
with one message in each direction, the challenge/response scheme
always requires at least three messages.
The disadvantage of the timestamp-based scheme is that it requires
secure synchronized time. If our clocks drift apart by more than
five minutes, you will reject all of my attempts to authenticate. If
a network time service spoofer can convince you to turn back your
clock and then subsequently replays an expired message, you will
accept it again. The multicast nature of existing distributed time
services and the likelihood of detection make this an unlikely
threat, but it must be considered in any analysis of the security of
the scheme. The timestamp scheme also requires the server to keep
state about all messages seen in the clock skew interval. To be
secure, this must be kept on stable storage (unless rebooting takes
longer than the permitted clock skew interval).
DASS uses the timestamp-based scheme. The primary motivations behind
this decision were so that authentication messages could be
"piggybacked" on existing connection establishment messages and so
that DASS would fit within the same "form factor" (number and
direction of messages) as Kerberos.
1.2.3 Delegation
In a distributed environment, authentication alone is not enough.
When I log onto a computer, not only do I want to prove my identity
to that computer, I want to use that computer to access network
resources (e.g., file systems, database systems) on my behalf. My
files should (normally) be protected so that I can access them
through any node I log in through. DASS allows them to be so
protected without allowing all of the systems that I might ever use
to access those files in my absence. In the process of logging in,
my password gives my login node access to my RSA secret. It can use
that secret to "impersonate" me on any requests it makes on my
behalf. It should forget all secrets associated with me when I log
off. This limits the trust placed in computer systems. If someone
takes control of a computer, they can impersonate all people who use
that computer after it is taken over but no others.
Normally when I access a network service, I want to strongly
authenticate to it. That is, I want to prove my identity to that
service, but I don't want to allow that service to learn anything
that would allow it to impersonate me. This allows me to use a
service without trusting it for more than the service it is
delivering. When using some services, for example remote login
services, I may want that service to act on my behalf in calling
additional services. DASS provides a mechanism whereby I can pass
secrets to such services that allow them to impersonate me.
Future versions of this architecture may allow "limited delegation"
so that a user may delegate to a server only those rights the server
needs to carry out the user's wishes. This version can limit
delegation only in terms of time. The information a user gives a
server (other than the initial login node) can be used to impersonate
the user but only for a limited period of time. Smart cards will
permit that time limitation to apply to the initial login node as
well.
1.2.4 Certification Authorities
A flaw in the strong authentication mechanism described above is that
it assumes that every "principal" (user and node) knows the public
key of every other principal it wants to authenticate. If I can fool
a server into thinking my public key is actually your public key, I
can impersonate you by signing a message, saying it is from you, and
having the server verify the message with what it thinks is your
public key.
To avoid the need to securely install the public key of every
principal in the database of every other principal, the concept of a
"Certification Authority" was invented. A certification authority is
a principal trusted to act as an introduction service. Each
principal goes to the certification authority, presents its public
key, and proves it has a particular name (the exact mechanisms for
this vary with the type of principal and the level of security to be
provided). The CA then creates a "certificate" which is a message
containing the name and public key of the principal, an expiration
date, and bookkeeping information signed by the CA's private key.
All "subscribers" to a particular CA can then be authenticated to one
another by presenting their certificates and proving knowledge of the
corresponding secret. CAs need only act when new principals are
being named and new private keys created, so that can be maintained
under tight physical security.
The two problems with the scheme as described so far are "revocation"
and "scaleability".
1.2.4.1 Certificate Revocation
Revocation is the process of announcing that a key has (or may have)
fallen into the wrong hands and should no longer be accepted as proof
of some particular identity. With certificates as described above,
someone who learns your secret and your certificate can impersonate
you indefinitely - even after you have learned of the compromise. It
lacks the ability corresponding to changing your password. DASS
supports two independent mechanisms for revoking certificates. In the
future, a third may be added.
One method for revocation is using timeouts and renewals of
certificates. Part of the signed message which is a certificate may
be a time after which the certificate should not be believed.
Periodically, the CA would renew certificates by signing one with a
later timeout. If a key were compromised, a new key would be
generated and a new certificate signed. The old certificate would
only be valid until its timeout. Timeouts are not perfect revocation
mechanisms because they provide only slow revocation (timeouts are
typically measured in months for the load on the CA and communication
with users to be kept manageable) and they depend on servers having
an accurate source of the current time. Someone who can trick a
server into turning back its clock can use expired certificates.
The second method is by listing all non-revoked certificates in the
naming service and believing only certificates found there. The
advantage of this method is that it is almost immediate (the only
delay is for name service "skulking" and caching delays). The
disadvantages are: (1) the availability of authentication is only as
good as the availability of the naming service and (2) the security
of revocation is only as good as the security of the naming service.
A third method for revocation - not currently supported by DASS - is
for certification authorities to periodically issue "revocation
lists" which list certificates which should no longer be accepted.
1.2.4.2 Certification Authority Hierarchy
While using a certification authority as an introduction service
scales much better than having every principal learn the public key
of every other principal by some out of band means, it has the
problem that it creates a central point of trust. The certification
authority can impersonate any principal by inventing a new key and
creating a certificate stating that the new key represents the
principal. In a large organization, there may be no individual who
is sufficiently trusted to operate the CA. Even if there were, in a
large organization it would be impractical to have every individual
authenticate to that single person. Replicating the CA solves the
availability problem but makes the trust problem worse. When
authentication is to be used in a global context - between companies
- the concept of a single CA is untenable.
DASS addresses this problem by creating a hierarchy of CAs. The CA
hierarchy is tied to the naming hierarchy. For each directory in the
namespace, there is a single CA responsible for certifying the public
keys of its members. That CA will also certify the public keys of
the CAs of all child directories and of the CA of the parent
directory. With this cross-certification, it is possible knowing the
public key of any CA to verify the public keys of a series of
intermediate CAs and finally to verify the public key of any
principal.
Because the CA hierarchy is tied to the naming hierarchy, the trust
placed in any individual CA is limited. If a CA is compromised, it
can impersonate any of the principals listed in its directory, but it
cannot impersonate arbitrary principals.
DASS provides mechanisms for every principal to know the public key
of its "parent" CA - the CA controlling the directory in which it is
named. The result is the following rules for the implications of a
compromised CA:
a) A CA can impersonate any principal named in its directory.
b) A CA can impersonate any principal to a server named in its
directory.
c) A CA can impersonate any principal named in a subdirectory to
any server not named in the same subdirectory.
d) A CA can impersonate to any server in a subdirectory any
principal not named in the same subdirectory.
The implication is that a compromise low in the naming tree will
compromise all principals below that directory while a compromise
high in the naming tree will compromise only the authentication of
principals far apart in the naming hierarchy. In particular, when
multiple organizations share a namespace (as they do in the case of
X.500), the compromise of a CA in one organization can not result in
false authentication within another organization.
DASS uses the X.500 directory hierarchy for principal naming. At the
top of the hierarchy are names of countries. National authorities
are not expected to establish certification authorities (at least
initially), so an alternative mechanism must be used to authenticate
entities "distant" in the naming hierarchy. The mechanism for this
in DASS is the "cross-certificate" where a CA certifies the public
key for some CA or principal not its parent or child. By limiting
the chains of certificates they will use to parent certificates
followed by a single "cross certificate" followed by child
certificates, a DASS implementation can avoid the need to have CAs
near the root of the tree or can avoid the requirement to trust them
even if they do exist. A special case can also be supported whereby
a global authority whose name is not the root can certify the local
roots of independent "islands".
1.2.5 User vs. Node Authentication
In concept, DASS mechanisms support the mutual authentication of two
principals regardless of whether those principals are people,
computers, or applications. Those mechanisms have been extended,
however, to deal with a common case of a pair of principals acting
together (a user and a node) authenticating to a single principal (a
remote server). This is done by having optionally in each
credentials structure two sets of secrets - one for the user and one
for the node. When authentication is done using such credentials,
both secrets sign the request so the receiving party can verify that
both principals are present.
This setup has a number of advantages. It permits access controls to
be enforced based on both the identity of the user and the identity
of the originating node. It also makes it possible to define users
of systems who have no network wide identities who can access network
resources on the basis of node credentials alone. The security of
such a setup is less because a node can impersonate all of its users
even when they are not logged in, but it offers an easier transition
from existing global identities for all users.
1.2.6 Protection of User Keys
DASS mechanisms generally deal with authentication between principals
each knowing a private key. For principals who are people, special
mechanisms are provided for maintaining that private key. In
particular, it many cases it will be most convenient to keep
passwords as secrets rather than private keys. This architecture
specifies a means of storing private keys encrypted under passwords.
This would provide security as good as hiding a private key were it
not that people tend to choose passwords from a small space (like
words in a dictionary) such that a password can be more easily
guessed than a private key. To address this potential weakness, DASS
specifies a protocol between a login node and a login agent whereby
the login agent can audit and limit the rate of password guesses.
Use of these features is optional. A user with a smart card could
store a private key directly and bypass all of these mechanisms. If
users can be forced to choose "good" passwords, the login agent could
be eliminated and encrypted credentials could be stored directly in
the naming service.
Another way in which user keys are protected is that the architecture
does not require that they be available except briefly at login.
This reduces the threat of a user walking away from a logged on
workstation and having someone take over the workstation and extract
his key. It also makes the use of RSA based smart cards practical;
the card could keep the user's private key and execute one signature
operation at login time to authenticate an entire session.
1.3 What This Document Won't Tell You
Architecture documents are by their nature difficult to read. This
one is no exception. The reason is that an architecture document
contains the details sufficient to build interoperable
implementations, but it is not a design specification. It goes out of
its way to leave out any details which an implementation could choose
without affecting interoperability. It also does not specify all the
uses of the services provided because these services are properly
regarded as general purpose tools.
The remainder of this section includes information which is not
properly part of the authentication architecture, but which may be
useful in understanding why the architecture is the way it is.
1.3.1 How DASS is Embedded in an Operating System
While architecturally DASS does not require any operating system
support in order to be used by an application (other than the
services listed in Section 2), it is expected that actual
implementations of DASS will be closely tied to the operating systems
of host computers. This is done both for security and for
convenience.
In particular, it is expected that when a user logs into a node, a
set of credentials will be created for that user and then associated
by the operating system with all processes initiated by or on behalf
of the user. When a user delegates to a service, the remote
operating system is expected to accept the delegation and start up
the remote process with the delegated credentials. Most nodes are
expected to have credentials of their own and support the concept of
user accounts. When user credentials are created, the node is
expected to verify them in its own context, determine the appropriate
user account, and add node credentials to the created credentials
set.
1.3.2 Forms of Credentials
In the DASS architecture, there is a single data structure called
"Credentials" with a large number of optional parts. In an
implementation, it is possible that not all of the architecturally
allowed subsets will be supported and credentials structures with
different subsets of the data may be implemented quite differently.
The major categories of credentials likely to be supported in an
implementation are:
- Claimant credentials - these are the credentials which would
normally be associated with a user process in order that it be
able to create authentication tokens. It would contain the
user's name, login ticket, session private key, and (at least
logically) local node credentials and cached outgoing
contexts.
- Verifier credentials - these are the credentials which would
normally be associated with a server which must verify tokens
and produce mutual authentication response tokens. Since
servers may be started by a node on demand, some
representation of verifier credentials must exist independent
of a process. If an operating system wishes to authenticate a
request before starting a server process, the credentials must
exist in usable form. An implementation may choose to have
all services on a "node" share a verifier credentials
structure, or it may choose to have each service have its own.
- Combined credentials - architecturally, a server may have a
structure which is both claimant credentials and verifier
credentials combined so that the server may act in either role
using a single structure. There is some overlap in the
contents. There is no requirement, however, that an
implementation support such a structure.
- Stub credentials - In the architecture, a credentials
structure is created whenever a token is accepted. If delegation
took place, these are claimant credentials usable by their
possessor to create additional tokens. If no delegation took
place, this structure exists as an architectural place holder
against which an implementation may attempt to authenticate
user and node names. An implementation might choose to
implement stub credentials with a different mechanism than
claimant or verifier credentials. In particular, it might do
whatever user and node authentication is useful itself and not
support this structure at all.
1.3.3 Support for Alternative Certification Authority
Implementations
A motivating factor in much of the design of DASS is the need to
protect certification authorities from compromise. CAs are only used
to create certificates for new principals and to renew them on
expiration (expiration intervals are likely to be measured in
months). They therefore do not need to be highly available. For
maximum security, CAs could be implemented on standalone PCs where
the hardware, software, and keys can be locked in a safe when the CA
is not in use. The certificates the CA generates must be delivered to
the naming service to be registered, and a possible mechanism for
this is for the CA to have an RS232 line to an on-line component
which can pass certificates and related information but not login
sessions. The intent would be to make it implausible to mount a
network attack against the CA. Alternatively, certificates could be
carried to the network on a floppy disk.
For CAs to be secure, a whole host of design details must be done
right. The most important of these is the design of user and system
manager interfaces that make it difficult to "trick" a user or system
manager into doing the wrong thing and certifying an impostor or
revealing a key. Mechanisms for generating keys must also be
carefully protected to assure that the generated key cannot be
guessed (because of lack of randomness) and is not recorded where a
penetrator can get it. Because a certificate contains relatively
little human intelligible information (its most important components
are UIDs and public keys), it will be a challenge to design a user
interface that assures the human operator only authorizes the signing
of intented certificates. Such considerations are beyond the scope of
the architecture (since they do not affect interoperability), but
they did affect the design in subtle ways. In particular, it does
not assume uniform security throughout the CA hierarchy and is
designed to assure that the compromise of a CA in one part of the
hierarchy does not have global implications.
The architecture does not require that CAs be off-line. The CA could
be software that can run on any node when the proper secret is
installed. Administrative convenience can be gained by integrating
the CA with account registration utilities and naming service
maintenance. As such, the CA would have to be on-line when in use in
order to register certificates in the naming service. The CA key
could be unlocked with a password and the password could be entered
on each use both to authenticate the CA operator and to assure that
compromise of the host node while the CA is not in use will not
compromise the CA. This design would be subject to attacks based on
planting Trojan horses in the CA software, but is entirely
interoperable with a more secure implementation. Realistic tradeoffs
must be made between security, cost, and administrative convenience
bearing in mind that a system is only as secure as its weakest link
and that there is no benefit in making the CA substantially more
secure than the other components of the system.
1.3.4 Services Provided vs. Application Program Interface
Section 3 of this document specifies "abstract interfaces" to the
services provided by DASS. This means it tells what services are
provided, what parameters are supplied by the caller, and what data
is returned. It does not specify the calling interfaces. Calling
interfaces may be platform, operating system, and language dependent.
They do not affect interoperability; different implementations which
implement completely different calling interfaces can still
interoperate over a network. They do, however, affect portability. A
program which runs on one platform can only run on another which
implements an identical API.
In order to support portability of applications - not just between
implementations of DASS but between implementations of DASS and
implementations of Kerberos - a "Generic Security Service API" has
been designed and is outlined in Annex B. This API could be the only
"published" interface to DASS services. This interface does not,
however, give access to all the functions provided by DASS and it
provides some non-DASS services. It does not give access to the
"login" service, for example, so the login function cannot be
implemented in a portable way. Clearly an implementation must provide
some implementation of the login function, though perhaps only to one
system program and the implementation need not be portable.
Similarly, the Generic API provides no access to node authentication
information, so applications which use these services may not be
portable.
The Generic API provides services for encryption of user data for
integrity and possibly privacy. These services are not specified as a
part of the DASS architecture. This is because we envisioned that
such services would be provided by the communications network and not
in applications. These services are provided by the Generic API
because these services are provided by Kerberos, there exist
applications which use these services, and they are desired in the
context of the IETF-CAT work. The DASS architecture includes a Key
Distribution service so that the encryption functions of the Generic
API can be supported and integrated. Annex B specifies how those
services can be implemented using DASS services.
The Services Provided also differ from the GSSAPI because there are
important extensions envisioned to the API for future applications
and it was important to assure that architecturally those services
were available. In particular, DASS provides the ability for a
principal to have multiple aliases and for the receiver of an
authentication token to verify any one of them. We want DASS to
support the case where a server only learns the name it is trying to
validate in the course of evaluating an ACL. This may be long after
a connection is accepted. The Services Provided section therefore
separates the Accept_token function from the Verify Principal Name.
The other motivation behind a different interface is that DASS
provides node authentication - the ability to authenticate the node
from which a request originates as well as the user. Because
Kerberos provides no such mechanism, the capability is missing from
the GSSAPI, but we expect some applications will want to make use of
it.
1.3.5 Use of a Naming Service
With the exception of the syntactical representation of names, which
is tied to X.500, the DASS architecture is designed to be independent
of the particular underlying naming service. While the intention is
that certificates be stored in an X.500 naming service in the fields
architecturally reserved for this purpose in the standard, this
specification allows for the possibility of different forms of
certificate stores. The SPX implementation of DASS implements its
own certificate distribution service because we did not want to
introduce a dependency on an X.500 naming service.
1.3.6 Key Hiding - Credentials
The abstract interfaces described in section 3 specify that
"credentials" and "keys" are the inputs and outputs of various
routines. Credentials structures in particular contain secret
information which should not be made available to the calling
application. In most cases, keeping this information from
applications is simply a matter of prudence - a misbehaving
application can do nearly as much damage using the credentials as it
can by using the secrets directly. Having access to the keys
themselves may allow an application to bypass auditing or leak a key
to an accomplice who can use it on another node where a large amount
of activity is less likely to be noticed. In some cases, most
dramatically where a "node key" is present in user credentials, it is
vital that the contents of the credentials be kept out of the hands
of applications.
To accomplish this, a concrete interface is expected to create
"credentials handles" that are passed in and out of DASS routines.
The credentials themselves would be kept in some portion of memory
where unprivileged code can't get at them.
There is another aspect of the way credentials are used which is
important to the design of real implementations. In normal use, a
user will create a set of credentials in the process of logging on to
a system and then use them from many processes or jobs. When many
processes share a set of credentials, it is important for the sake of
performance that they share one set of credentials rather than having
a copy of the credentials made for each. This is because information
is cached in credentials as a side effect of some requests and for
good performance those caches should be shared.
As an example, consider a system executing a series of copy commands
moving files from one system to another. The credentials of the user
will have been established when the user logged on. The first time a
copy is requested, a new process will start up, open a connection to
the destination system, and create a token to authenticate itself.
Creating that token will be an expensive operation, but information
will be computed and "cached" in the credentials structure which will
allow any subsequent tokens on behalf of that user to that server to
be computed cheaply. After the copy completes, the connection is
closed and the process terminates. In response to a second copy
request, another new process will be created and a new token
computed. For this operation to get a performance benefit from the
caching, the information computed by the first process must somehow
make it to the second.
A model for how this caching might work can be seen in the way
Kerberos caches credentials. Kerberos keeps credentials in a file
whose name can be computed from the name of the local user. This
file is initialized as part of the login process and its protection
is set so that only processes running under the UID of the user may
read and write the file. Processes cache information there; all
processes running on behalf of the user share the file.
There are two problems with this scheme: first, on a diskless node
putting information in a file exposes it to eavesdroppers on the
network; second, it does not accomplish the "key hiding" function
described earlier in this section. In a more secure implementation,
the kernel or a privileged process would manage some "pool" of
credentials for all processes on a node and would grant access to
them only through the DASS calls. Credentials structures are complex
and varying length; DASS may organize them as a set of pools rather
than as contiguous blocks of data. All such design issues are
"beyond the scope of the architecture". Implementations must decide
how to control access to credentials. They could copy the Kerberos
scheme of having credentials available to processes with the UID of
the login session which created them and to privileged processes or
there may be a more elaborate mechanism for "passing" credentials
handles from process to process. This design should probably follow
the operating system mechanisms for passing around local privileges.
1.3.7 Key Hiding - Contexts
The "GSSAPI" has a concept of a security context which has some of
the same key hiding problems as a credentials structure. Security
contexts are used in calls to cryptographically protect user data
(from modification or from disclosure and modification) using keys
established during authentication. The "services provided"
specification says that create_ and accept_token return a "shared
key" and "instance identifier". The GSSAPI says that a context
handle is returned which is an integer. A secure implementation
would keep the key and instance identifier in protected memory and
only allow access to them through provided interfaces.
Unlike credentials, there is probably no need to provide mechanisms
for contexts to be shared between processes. Contexts will normally
be associated with some notion of a communications "connection" and
ends of a connection are not normally shared. If an implementation
chooses to provide additional services to applications like message
sequencing or duplicate detection, contexts will have to contain
additional fields. These can be created and maintained without any
additional authentication services.
1.4 The Relationship between DASS and ISO Standards
This section provides an introduction to DASS authentication in terms
of the ISO Authentication Framework (DP10181-2). The purpose of
this introduction is to give the reader an intuitive understanding of
the way DASS works and how its mechanisms and terminology relate to
standards. Important details have been omitted here but are spelled
out in section 3.
1.4.1 Concepts
The primary goal of authentication is to prevent impersonation, that
is, the pretense to a false identity. Authentication always involves
identification in some form. Without authentication, anyone could
claim to be whomever they wished and get away with it.
If it didn't matter with whom one was communicating, elaborate
procedures for authentication would be unnecessary. However, in most
systems, and in timesharing and distributed processing environments
in particular, the rights of individuals are often circumscribed by
security policy. In particular, authorization (identity based access
control) and accountability (audit) provisions could be circumvented
if masquerading attempts were impossible to prevent or detect.
Almost all practical authentication mechanisms suitable for use in
distributed environments rely on knowledge of some secret
information. Most differences lie in how one presents evidence that
they know the secret. Some schemes, in particular the familiar simple
use of passwords, are quite susceptible to attack. Generally, the
threats to authentication may be classified as:
- forgery, attempting to guess or otherwise fabricate evidence;
- replay, where one can eavesdrop upon another's authentication
exchange and learn enough to impersonate them; and
- interception, where one slips between the communicants and is
able to modify the communications channel unnoticed.
Most such attacks can be countered by using what is known as strong
authentication. Strong authentication refers to techniques that
permit one to provide evidence that they know a particular secret
without revealing even a hint about the secret. Thus neither the
entity to whom one is authenticating, nor an eavesdropper on the
conversation can further their ability to impersonate the
authenticating principal at some future time as the result of an
authentication exchange.
Strong authentication mechanisms, in particular those used here, rely
on cryptographic techniques. In particular, DASS uses public key
cryptography. Note that interception attacks cannot be countered by
strong authentication alone, but generally need additional security
mechanisms to secure the communication channel, such as data
encryption.
1.4.2 Principals and Their Roles
All authentication is on behalf of principals. In DASS the following
types of principals are recognized:
- user principals, normally people with accounts who are
responsible for performing particular tasks. Generally it is
users that are authorized to do things by virtue of having
been granted access rights, or who are to be held accountable
for specific actions subject to being audited.
- server principals, which are accessed by users.
- node principals, corresponding to locations where users and
servers, or more accurately, processes acting on behalf of
principals can reside.
Principals can act in one of two capacities:
- the claimant is the active entity seeking to authenticate
itself, and
- the verifier is the passive entity to whom the claimant is
authenticating.
Users normally are claimants, whereas servers are usually verifiers,
although sometimes servers can also be claimants.
There is another kind of principal:
- certification authorities (CA's) issue certificates which
attest to another principal's public key.
1.4.3 Representation, Delegation and Representation Transfer
Of course, although it is users that are responsible for what the
computer does, human beings are physically unable to directly do
anything within a computer system. In point of fact, it is a
process executing on behalf of a user that actually performs
useful work. From the point of view of performing security
controlled functions, the process is the agent, or
representative, of the user, and is authorized by that user to do
things on his behalf. In the terms used in the ISO Authentication
Framework, the user is said to have a representation in the
process.
The representation has to come into existence somehow. Delegation
refers to the act of creating a representation. A user is said to
create a representation for themselves by delegating to a process. If
the user creates another process, say by doing an rlogin on a
different computer, a representation may be needed there as well. This
may be accomplished automatically by a process known as representation
transfer. DASS uses the term delegation to also mean the act of
creating additional representations on a remote systems.
A representation is instantiated in DASS as credentials. Credentials
include the identity of the principal as well as the cryptographic
"state" needed to engage in strong authentication procedures. Claimant
information in credentials enable principals to authenticate
themselves to others, whereas verifier information in credentials
permit principals to verify the claims of others. Credentials
intended primarily for use by a claimant will be referred to as
claimant credentials in the text which follows. Credentials intended
primarily for use in verification will be referred to as verifier
credentials. A particular set of credentials may or may not contain
all of the data necessary to be used in both roles. That will depend
on the mechanisms by which the credentials were created.
In some contexts, but not here, the concept of representation
and/or delegation is sometimes referred to as proxy. This term is
used in ECMA TR/46. We avoid use of the term because of possible
confusion with an unrelated use of the term in the context of
DECnet.
1.4.4 Key Distribution, Replay, Mutual Authentication and Trust
Strong authentication uses cryptographic techniques. The
particular mechanisms used in DASS result in the distribution of
cryptographic keys as a side effect. These keys are suitable for
use for providing a data origin authentication service and/or a
data confidentiality service between a pair of authenticated
principals.
Replay detection is provided using timestamps on relevant
authentication messages, combined with remembering previously
accepted messages until they become "stale". This is in contrast
to other techniques, such as challenge and response exchanges.
Authentication can be one-way or mutual. One-way authentication is
when only one party, in DASS the claimant, authenticates to the other.
Mutual authentication provides, in addition, authentication of the
verifier back to the claimant. In certain communications schemes, for
example connectionless transfer, only one-way authentication is
meaningful. DASS supports mutual authentication as a simple extension
of one-way authentication for use in environments where it makes
sense.
DASS potentially can allow many different "trust relationships"
to exist. All principals trust one or more CA's to safeguard the
certification process. Principals use certificates as the basis
for authenticating identities, and trust that CA's which issue
certificates act responsibly. Users expect CA's to make sure that
certificates (and related secrets) are only made for principals
that the CA knows or has properly authenticated on its own.
1.5 An Authentication Walkthrough
The OSI Authentication Framework characterizes authentication as
occurring in six phases. This section attempts to describe DASS
in these terms.
1.5.1 Installation
In this phase, principal certificates are created, as is the
additional information needed to create claimant and verifier
credentials. OSI defines three sub-phases:
- Enrollment. In DASS, this is the definition of a principal in
terms of a key, name and UID.
- Validation, confirmation of identity to the satisfaction of
the CA, after which the CA generates a certificate.
- Confirmation. In DASS, this is the act of providing the user
with the certificate and with the CA's own name, key and UID,
followed up by the user creating a trusted authority for that
CA. A trusted authority is a certificate for the CA signed by
the user.
Included in this step in DASS is the posting of the certificate so as
to be available to principals wishing to verify the principal's
identity. In addition, the user principal saves the trusted authority
so as to be available when it creates credentials.
1.5.2 Distribution
DASS distributes certificates by placing them in the name service.
1.5.3 Acquisition
Whenever principals wish to authenticate to one another, they access
the Name Service to obtain whatever public key certificates they need
and create the necessary credentials. In DASS, acquisition means
obtaining credentials.
Claimant credentials implement the representation of a principal in a
process, or, more accurately, provide a representation of the
principal for use by a process. In making this representation, the
principal delegates to a temporary delegation key. In this fashion
the claimant's long term principal key need not remain in the system.
Claimant credentials are made by invoking the get credentials
primitive. Claimant credentials are a DASS specific data structure
containing:
- a name
- a ticket, a data structure containing
. a validity interval,
. UID, and
. (temporary) delegation public key, along with a
. digital signature on the above made with the principal
private key
- the delegation private key
Optionally in addition, there may be credential information relating
to the node on which the user is logged in and the account on that
node. A detailed description of all the information found in
credentials can be found in section 3. Verifier credentials are made
with initialize_server. Verifier credentials consist of a principal
(long term) private key. The rationale is that these credentials are
usually needed by servers that must be able to run indefinitely
without re-entry of any long term key.
In addition, claimants and verifiers have a trusted authority, which
consists of information about a trusted CA. That information is its:
- name (this will appear in the "issuer" field in principal
certificates),
- public key (to use in verifying certificates issued by that
CA), and
- UID.
Trusted authorities are used by principals to verify certificates for
other principals' public keys. CAs are arranged in a hierarchy
corresponding to the naming hierarchy, where each directory in the
naming hierarchy is controlled by a single CA. Each CA certifies the
CA of its parent directory, the CAs of each of its child directories,
and optionally CAs elsewhere in the naming hierarchy (mainly to deal
with the case where the directories up to a common ancestor lack
CAs). Even though a principal has only a single CA as a trusted
authority, it can securely obtain the public key of any principal in
the namespace by "walking the CA hierarchy".
1.5.4 Transfer
The DASS exchange of authentication information is illustrated in
Figure 1-1. During the transfer phase, the DASS claimant sends an
authentication token to the verifier. Authentication tokens are made
by invoking the create_token primitive. The authentication token is
cryptographically protected and specified as a DASS data structure in
ASN.1. The authentication token includes:
- a ticket,
- a DES authenticating key encrypted using the intended
verifier's public key
- one of the following:
. if delegation is not being performed, a digital signature on
the encrypted DES key using the delegation private key, or
. if delegation is being performed, sending the delegation
private key, DES encrypted using the DES authenticating key
- an authenticator, which is a cryptographic checksum made using
the DES authenticating key over a buffer containing
. a timestamp
. any application supplied "channel bindings". For example,
addresses or other context information. The purpose of this
field is to thwart substitution and replay attacks.
- additional optional information concerning node authentication
and context.
As a side effect, after init_authentication_context, the caller
receives a local authentication context, a data structure containing:
- the DES key, and
- if mutual authentication is being requested, the expected
response.
In order to construct an authentication token, the claimant needs to
access the verifier's public key certificate from the Name Service
(labeled CDC, for Certificate Distribution Center, in the figure).
Note that while an authenticator can only be used once, it is
permissible to re-establish the same local authentication context
multiple times. That is, the ticket and DES key establishment
components of the authentication token may have a relatively long
lifetime. This permits a performance improvement in that repeated
applications of public key operations can be alleviated if one caches
authentication contexts, along with other components from a
successfully used authentication token and the associated verified
principal public key value. It is a relatively inexpensive operation
to create (and verify) "fresh" authenticators based on cached
authentication context.
Claimant Actions | Communications | Verifier Actions
| |
verifier name | |
| | |
| | +---+|
\------------------->| ||
trusted | | ||
authorities | |CDC||
| +-----------+ |certificate| ||
| | Verify |<-------------| ||
\--->|Certificate| | +---+|
+-----------+ | |
Claimant | | |
credentials Verifier | | Verifier
| Public Key | | Credentials
| | | | |
| V | | V
| +-----------+ | Authentication | +-----------+
| | Make | | Token | | Check | Replay
\--->| Token |-------------------->| Token |<-->Cache
+-----------+ | | +-----------+
DES <---/ | | | | | \----->DES
key | | | /Claimant key
| | |/Public Key
| | / | trusted
| | Claimant /| V authorities
| |+---+ Name / | +-----------+ |
authentication || |<-------/ | | Verify |<----/
context || |certificate| |Certificate|
| ||CDC|------------>| |-->accept/
| || | | +-----------+ reject
| || | | | \
| |+---+ |authentication\
V | mutual | context V
+-----------+ | authentication | | claimant
/--| Accept | | response | +----------+credentials
V | Mutual |<--------------------| Make |(delegation)
accept/ +-----------+ | | | Response |
reject | | +----------+
| |
Figure 1 - Authentication Exchange Overview
1.5.5 Verification
Upon receipt of an authentication token, the verifier extracts the
DES key using its verifier credentials, accesses the Name Service
(labeled CDC for Certificate Distribution Center) to obtain the
certificates needed to perform cryptographic checks on the incoming
information, and verifies all of the signatures on the received
certificates and the authentication token. Verification can result
in creation of new claimant credentials if delegation is performed.
As part of this process, verified authenticators are retained for a
suitable timeout period.
1.5.6 Unenrolment
This is the removal of information from the Name Service. The only
other form of revocation supported by DASS is certificate timeout.
Every certificate contains an expiration time (expected in ordinary
use to be about a year from its signing date). DASS does not
currently support the revocation lists in X.509.
2. Services Used
Aside from operating system services needed to maintain its internal
state, DASS relies on a global distributed database in which to store
its certificates, a reliable source of time, and a source of random
numbers for creating cryptographic keys.
2.1 Time Service
DASS requires access to the current time in several of its
algorithms. Some of its uses of time are security critical. In
others, network synchronization of clocks is required. DASS does
not, however, depend on having a single source of time which is both
secure and tightly synchronized.
The requirements on system provided time are:
- For purposes of validating certificates and tickets, the
system needs access to know the date and time accurate to
within a few hours with no particular synchronization
requirements. If this time is inaccurate, then valid requests
may be rejected and expired messages may be accepted.
Certificate expiration is a backup revocation mechanism, so
this can only cause a security compromise in the event of
multiple failures. In theory, this could be provided by
having a local clock on every node accurate to within a few
hours over the life of the product to provide this function.
If an insecure network time service is used to provide this
time, there are theoretical security threats, but they are
expected to be logistically impractical to exploit.
- For purposes of detecting replay of authentication tokens, the
system needs access to a strictly monotonic time source which
is reasonably synchronized across the network (within a few
minutes) for the system to work, but inaccuracy does not
present a security threat except as noted below. It may
constitute an availability threat because valid requests may
be rejected. In order to get strict monotonicity in the
presence of a rapid series of requests, time must be returned
with high precision. There is no requirement for a high
degree of accuracy. Inaccurate time could present a security
threat in the following scenario: if a client's clock is made
sufficiently fast that its tokens are rejected, someone
harvesting those tokens from the wire could replay them later
and impersonate the client. In some environments, this might
be an easier threat than harvesting tokens and preventing
their delivery.
- For purposes of aging stale entries from caches, DASS requires
reasonably accurate timing of intervals. To the extent that
intervals are reported as shorter than the actually were,
revocation of certificates from the naming service may not be
as timely as it should be.
2.2 Random Numbers
In order to generate keys, DASS needs a source of "cryptographic
quality" random numbers. Cryptographic quality means that
knowing any of the "random numbers" returned from a series and
knowing all state information which is not protected, an attacker
cannot predict any of the other numbers in the series. Hardware
sources are ideal, but there are alternative techniques which may
also be acceptable. A 56 bit "truly random" seed (say from a
series of coin tosses) could be used as a DES key to encrypt an
infinite length known text block in CBC mode to produce a pseudo-rand
sequence provided the key and current point in the sequence were
adequately protected. There is considerable controversy
surrounding what constitutes cryptographic quality random
numbers, and it is not a goal of this document to resolve it.
2.3 Naming Service
DASS stores creates and uses "certificates" associated with every
principal in the system, and encrypted credentials associated
with most. This information is stored in an on-line service
associated with the principal being certified. The long term
vision is for DASS to use an X.500 naming service, and DASS will
from its inception authenticate X.500 names. To avoid a
dependence on having an X.500 naming service available (and to
gain the benefits of a "login agent" that controls password
guessing), an alternative certificate distribution center
protocol is also described.
The specific requirements DASS places on the naming service are:
- It must be highly available. A user's naming service entry
must be available to any node where the user is to obtain
services (or service will be denied). A server's naming
service entry must be available from any node from which the
service is to be invoked (or service will be denied).
- It must be timely. The presence of "stale" information in the
naming service may cause some problems. When a password
changes, the old password may remain valid (and the new
password invalid) to the extent the naming service provides
stale information. When a user or server is added to the
network, it will not be able to participate in authentication
until the information added to the naming service is available
at the node doing the authentication. In the unusual
circumstance that a key changes, the entity whose key has
changed will not be able to use the new key until the new
certificate is uniformly available.
- It must be secure with regard to certain specific properties.
In general, the security of DASS protected applications does
not depend on the security of the naming service. It is
expected that the availability needs of the naming service
will prevent it from being as secure as some applications need
to be. There are two aspects of DASS security which do depend
on the security of the naming service: timely revocation of
certificates and protection of user secrets against dictionary
based password guessing. DASS depends on the removal of
certificates from the naming service in order to revoke them
more quickly than waiting for them to time out. For this
mechanism to provide any actual security, it must not be
possible for a network entity to "impersonate" the naming
service and the naming service must be able to enforce access
controls which prevent a revoked certificate from being
reinstated by an unauthorized entity. In the long run, it is
expected that DASS itself will be used to secure the naming
service, which presents certain potential recursion problems
(to be addressed in the naming service design). If the naming
service is not authenticated (as is expected in early
versions) attacks where a revoked certificate is "reinstated"
through impersonation of the naming service are possible.
The specific functions DASS requests of the naming service are
simple:
- Given an X.500 name, store a set of certificates associated
with that name.
- Given an X.500 name, retrieve the set of certificates
associated with that name.
- Given an X.500 name, store a set of encrypted credentials
associated with that name.
- Given and X.500 name, retrieve a set of encrypted credentials
associated with that name.
Implementation over a particular naming service may implement more
specialized functions for reasons of efficiency. For example, the
certificates associated with a name may be separated into several
sets (child, parent, cross, self) so that only the relevant ones may
be retrieved. In order that access to the naming service itself be
secure, the protocols should be authenticated. Certificates should
generally be readable without authentication in order to avoid
recursion problems. Requests to read encrypted credentials should be
specialized and should include proof of knowledge of the password in
order that the naming service can audit and slow down false password
guesses.
The following sections describe the interfaces to specific naming
services:
2.3.1 Interface to X.500
Certificates associated with a particular name are stored as
attributes of the entry as specified in X.509. X.509 defines
attributes appropriate for parent and cross certificates
(CrossCertificatePair, CACertificate) for some principals; we will
have to define a DASSUserPrincipal object class including these
attributes in order to properly use them with ordinary users.
Retrieval is via normal X.500 protocols. Certificates should be
world readable and modifiable only by appropriate authorities.
Encrypted credentials are stored with the entry of the principal
under a yet to be defined attribute. The credentials should be
encoded as specified in section 4. In the absence of extensions to
the X.500 protocol to control password guessing, the encrypted
credentials should be world readable and updatable only by the named
principal and other appropriate authorities.
2.3.2 Interface to CDC
The CDC (Certificate Distribution Center) is a special purpose name
server created to service DASS until an X.500 service is available in
all of the environments where DASS needs to operate. The CDC uses a
special purpose protocol to communicate with DASS clients. The
protocol was designed for efficiency, simplicity, and security. CDCs
use DASS as an authentication mechanism and to protect encrypted
credentials from unaudited password guessing.
Each DASS client maintains a list of CDCs and the portion of the
namespace served by that CDC. Each directory has a master replica
which is the only one which will accept updates. The CDCs maintain
consistency with one another using protocols beyond the scope of this
document. When a DASS client wishes to make a request of a CDC, it
opens a TCP or DECnet connection to the CDC and sends an ASN.1 (BER)
encoded request and receives a corresponding ASN.1 (BER) encoded
response. Clients are expected to learn the IP or DECnet address and
port number of the CDC supporting a particular name from a local
configuration file. To maximize performance, the requests bundle
what would be several requests if made in terms of requests for
individual certificates. It is intended that all certificates needed
for an authentication operation be retrievable with at most two CDC
requests/responses (one to the CDC of the client and one to the CDC
of the server).
Documented here is the protocol a DASS client would use to retrieve
certificates and credentials from a CDC and update a user password.
This protocol does not provide for updates to the certificate and
credential databases. Such updates must be supported for a practical
system, but could be done either by extensions to this protocol or by
local security mechanisms implemented on nodes supporting the CDC.
Similarly, availability can be enhanced by replicating the CDC.
Automating the replication of updates could be implemented by
extensions to this protocol or by some other mechanism. This
specification assumes that updates and replication are local matters
solved by individual CA/CDC implementations.
Requests and responses are encoded as follows:
2.3.2.1 ReadPrinCertRequest
This request asks the CDC to return the child certificates and
selected incoming cross certificates for the specified object. The
format of the request is:
ReadPrinCertRequest ::= [4] IMPLICIT SEQUENCE {
flags [0] BIT STRING DEFAULT {},
index [1] IMPLICIT INTEGER DEFAULT 0,
resolveFrom [2] Name OPTIONAL,
principal Name,
crossCertIssuers ListOfIssuers OPTIONAL
}
ListOfIssuers ::= SEQUENCE OF Name
The first 24 bits of flags, if present, contain a protocol version
number. Clients following this spec should place the value 2.0.0 in
the three bytes. Servers following this spec should accept any value
of the form 1.x.x or 2.x.x. flags bits beyond the first 24 are
reserved for future use (should not be supplied by clients and should
be ignored by servers).
index is only used if the response exceeds the size of a single
message; in that case, the query is repeated with index set to the
value that was returned by ReadPrinCertResponse. resolveFrom and
principal imply a set of entities for which certificates should be
retrieved. resolveFrom (if present) must be an ancestor of principal
and child certificates will be retrieved for principal and all names
which are ancestors of principal but descendants of resolveFrom. The
encoding of names is per X.500 and is specified in more detail in
section 4. The CDC returns the certificates in order of the object
they came from, parents before children.
crossCertIssuers is a list of cross certifiers that would be believed
in the context of this authentication. If supplied, the CDC may
return a chain of certificates starting with one of the named
crossCertIssuers and ending with the named principal. One of
resolveFrom or crossCertIssuers must be present in any request; if
both are present, the CDC may return either chain.
2.3.2.2 ReadPrinCertResponse
This is the response a CDC sends to a ReadPrinCertRequest. Its
syntax is:
ReadPrinCertResponse ::= [5] IMPLICIT SEQUENCE {
status [0] IMPLICIT CDCstatus DEFAULT success,
index [1] INTEGER OPTIONAL,
resolveTo [2] Name OPTIONAL,
certSequence [3] IMPLICIT CertSequence,
indexInvalidator [4] OCTET STRING (SIZE(8)) OPTIONAL,
flags [5] BIT STRING OPTIONAL
}
CertSequence ::= SEQUENCE OF Certificate
status indicates success or the cause of the failure.
index if present indicates that the request could not be fully
satisfied in a single request because of size limitations. The
request should be repeated with this index supplied in the request to
get more.
resolveTo will be present if index is present and should be supplied
in the request for more certificates. certSequence contains
certificates found matching the search criteria.
indexInvalidator may be present and indicates the version of the
database being read. If a set of certificates is being read in
multiple requests (because there were too many to return in a single
message), the reader should check that the value for indexInvalidator
is the same on each request. If it is not, the server may have
skipped or duplicated some certificates. This field must not be
present if the version number in the request was missing or version
1.x.x.
The first 24 bits of flags, if present, indicate the protocol version
number. Implementers of this version of the spec should supply 2.0.0
and should accept any version number of the form 1.x.x or 2.x.x.
2.3.2.3 ReadOutgoingCertRequest
This requests from the CDC a list of all parent and outgoing cross
certificates for a specified object. A CDC is capable of storing
cross certificates either with the subject or the issuer of the cross
certificate. In response to this request, the CDC will return all
parent and cross certificates stored with the issuer for the named
principal and all of its ancestors. Its syntax is:
ReadOutgoingCertRequest ::= [6] IMPLICIT SEQUENCE {
flags [0] BIT STRING DEFAULT {},
index [1] IMPLICIT INTEGER DEFAULT 0,
principal Name
}
The first 24 bits of flags is a protocol version number and should
contain 2.0.0 for clients implementing this version of the spec.
Servers implementing this version of the spec should accept any
version number of the form 1.x.x or 2.x.x. The remaining bits are
reserved for future use (they should not be supplied by clients and
they should be ignored by servers).
index is used for continuation (see ReadPrinCertRequest).
principal is the name for which certificates are requested.
2.3.2.4 ReadOutgoingCertResponse
This is the response to a ReadOutgoingCertRequest. Its syntax is:
ReadOutgoingCertResponse::= [7] IMPLICIT SEQUENCE {
status [0] IMPLICIT CDCStatus DEFAULT success,
index [1] INTEGER OPTIONAL,
certSequence [2] IMPLICIT CertSequence,
indexInvalidator [3] OCTET STRING (SIZE(8))
OPTIONAL,
flags [4] BIT STRING OPTIONAL
}
CertSequence ::= SEQUENCE OF Certificate
status indicates success of the cause of failure of the operation.
index is used for continuation; see ReadPrinCertRequest.
certSequence is the list of parent and outgoing cross certificates.
indexInvalidator is used for continuation; see ReadPrinCertResponse
(the same rules apply with respect to version numbers).
The first 24 bits of flags, if present, contain the protocol version
number. Clients implementing this version of the spec should supply
the value 2.0.0. Servers should accept any values of the form 1.x.x
or 2.x.x. The remaining bits are reserved for future use (they
should not be supplied by clients and should be ignored by servers).
2.3.2.5 ReadCredentialRequest
This request is made to retrieve an principal's encrypted
credentials. To prevent unaudited password guessing, this structure
includes an encrypted value that proves that the requester knows the
password that will decrypt the structure. The syntax of the request
is:
ReadCredentialRequest ::= [2] IMPLICIT SEQUENCE {
flags [0] BIT STRING DEFAULT {}
principal Name,
logindata [2] BIT STRING DEFAULT {},
token [3] BIT STRING OPTIONAL
}
The first 24 bits of flags contains the version number of the
protocol. The value 2.0.0 should be supplied. Any value of the form
1.x.x or 2.x.x should be accepted. Any additional bits are reserved
for future use (should not be supplied by clients and should be
ignored by servers).
principal is the name of the principal for whom encrypted credentials
are desired.
logindata is an encrypted value. It may only be present if the
version number is 2.0.0 or higher. It must be present to read
credentials which are protected by the login agent functionality of
the CDC. It is constructed as a single RSA block encrypted under the
public key of the CDC. The public key of the CDC is learned by some
local means. Possibilities include a local configuration file or by
using DASS to read and verify a chain of certificates ending with the
CDC [the CDC serving a directory should have its public key listed
under a name consisting of the directory name with the RDN
"CSS=X509"; the OID for the type CSS is 1.3.24.9.1]. The contents of
the block are as follows:
- The low order eight bytes contain a randomly generated DES key
with the last byte of the DES key placed in the last byte of
the RSA block. This DES key will be used by the CDC to
encrypt the response. Key parity bits are ignored.
- The next to last eight bytes contain a long Posix time with
the integer time encoded as a byte string using big endian
order.
- The next eight bytes (from the end) contain a hash of the
password. The algorithm for computing this hash is listed in
section 4.4.2. The CDC never computes this hash; it simply
compares the value it receives with the value associated with
the credentials.
- The next sixteen bytes (from the end) contain zero.
- The remainder of the RSA block (which should be the same size
as the public modulus of the CDC) contains a random number.
The first byte should be chosen to be non-zero but so the
value in the block does not exceed the RSA modulus. Servers
should ignore these bits. This random number need not be of
cryptographic strength, but should not be the same value for
all encryptions. Repeating the DES key would be adequate.
- The byte string thus constructed is encrypted using the RSA
algorithm by treating the string of bytes as a "big endian"
integer and treating the integer result as "big endian" to
make a string of bytes.
token will not be present in the initial implementation but a space
is reserved in case some future implementation wants to authenticate
and audit the node from which a user is logging in.
2.3.2.6 ReadCredentialProtectedResponse
This is the second possible response to a ReadPrinLoginRequest. It
is returned when the encrypted credentials are protected from
password guessing by the CDC acting as a login agent. Its syntax is:
ReadCredentialProtectedResponse::=[16] IMPLICIT SEQUENCE {
status [0] IMPLICIT CDCStatus DEFAULT success,
encryptedCredential [1] BIT STRING,
flags [2] BIT STRING OPTIONAL
}
status indicates that the request succeeded or the cause of the
failure.
encryptedCredential contains the DASSPrivateKey structure (defined in
section 4.1) encrypted under a DES key computed from the user's name
and password as specified in section 4.4.2 and then reencrypted under
the DES key provided in the ReadPrinLoginRequest.
The first 24 bits of flags, if present, contains the version number
of the protocol. Implementers of this version of the spec should
supply 2.0.0 and should accept any version number of the form 2.x.x.
Other bits are reserved for future use (they should not be supplied
and they should be ignored).
2.3.2.7 WriteCredentialRequest
This is a request to update the encrypted credential structure. It
is used when a user's key or password changes. The syntax of the
request is:
WriteCredentialRequest ::= [17] IMPLICIT SEQUENCE {
flags [0] BIT STRING DEFAULT {},
authtoken [2] BIT STRING OPTIONAL,
principal [3] Name,
logindata [4] BIT STRING DEFAULT {},
furtherSensitiveStuff [5] BIT STRING
}
The first 24 bits of flags is a version number. Clients implementing
this version of the spec should supply 2.0.0. Servers should accept
any value of the form 2.x.x. Additional bits are reserved for future
use (clients should not supply them and servers should ignore them).
token, if present, authenticates the entity making the request. A
request will be accepted either from a principal proving knowledge of
the password (see logindata below) or a principal presenting a token
in this field and satisfying the authorization policy of the CDC.
This field need not be present if logindata includes the hash2 of the
password (anyone knowing the old password may set a new one).
principal is the name of the object for which encrypted credentials
should be updated.
logindata is encrypted as in ReadPrinLoginRequest. It proves that
the requester knows the old password of the principal to be updated
(unless the token supplied is from the user's CA) and includes the
key which encrypts furtherSensitiveStuff.
furtherSensitiveStuff is an encrypted field constructed as follows:
- The first eight bytes consist of the hash2 defined in section
4.4.2 with the last byte of the hash2 value stored first. The
CDC stores this value and compares it with the values supplied
in future requests of ReadCredentialRequest and
WriteCredentialRequest.
- The next (variable number of) bytes contains a DASSPrivateKey
structure (defined in section 4.1). This is the new
credential structure that will be returned by the CDC on
future ReadCredentialRequests.
- The result is padded with zero bytes to a multiple of eight
bytes.
- The entire padded string is encrypted using the key from
logindata or token using DES in CBC mode with zero IV.
the new eight byte "hash2" defined in section 4.4.2 concatenated with
the DASSPrivateKey structure encrypted under the new "hash1" all
encrypted under the DES key included in logindata.
2.3.2.8 HereIsStatus
This is the response message to ill-formed requests and requests that
only return a status and no data. It's syntax is:
HereIsStatus ::= [1] IMPLICIT SEQUENCE {
status [0] IMPLICIT CDCStatus DEFAULT success
}
status indicates success or the cause of the failure.
2.3.2.9 Status Codes
The following are the CDCStatus codes that can be returned by
servers. Not all of these values are possible with all calls, and
some of the status codes are not possible with any of the calls
described in this document.
CDCStatus ::= INTEGER {
success(0),
accessDenied(1),
wrongCDC(2), --this CDC does not store the
--requested information
unrecognizedCA(3),
unrecognizedPrincipal(4),
decodeRequestError(5),--invalid BER
illegalRequest(6), --request not recognised
objectDoesNotExist(7),
illegalAttribute(8),
notPrimaryCDC(9),--write requests not accepted
--at this CDC replica
authenticationFailure(11),
incorrectPassword(12),
objectAlreadyExists(13),
objectWouldBeOrphan(15),
objectIsPermanent(16),
objectIsTentative(17),
parentIsTentative(18),
certificateNotFound(19),
attributeNotFound(20),
ioErrorOnCertifDatabase(100),
databaseFull(101),
serverInternalError(102),
serverFatalError(103),
insufficientResources(104)
}
3. Services Provided
This section specifies the services provided by DASS in terms of
abstract interfaces and a model implementation. A particular
implementation may support only a subset of these services and may
provide them through interfaces which combine functions and supply
some parameters implicitly. The specific calling interfaces are in
some cases language and operating system specific. An actual
implementation may choose, for example, to structure interfaces so
that security contexts are established and then passed implicitly in
calls rather than explicitly including them in every call. It might
also bundle keys into opaque structures to be used with supplied
encryption and decryption routines in order to enhance security and
modularity and better comply with export regulations. Annex B
describes a Portable API designed so that applications using a
limited subset of the capabilities of DASS can be easily ported
between operating systems and between DASS and Kerberos based
environments. The model implementation describes data structures
which include cached values to enhance performance. Implementations
may choose different contents or different caching strategies so long
as the same sequence of calls would produce the same output for some
caching policy.
DASS operates on four kinds of data structures: Certificates,
Credentials, Tokens, and Certification Authority State. Certificates
and Tokens are passed between implementations and thus their exact
format must be architecturally specified. This detailed bit-for-bit
specification is in section 4. Credentials generally exist only
within a single node and their format is therefore not specified
here. The contents of all of these data structures is listed below
followed by the algorithms for manipulating them.
There are three kinds of services provided by DASS: Certificate
Maintenance, Credential Maintenance, and Authentication. The first
two kinds exist only in support of the third. Certificate maintenance
functions maintain the database of public keys in the naming service.
These functions tend to be fairly specialized and may not be
supported on all platforms. Before authentication can take place,
both authenticating principals must have constructed credentials
structures. These are built using the Credential Maintenance calls.
The Authentication functions use credential information and
certificates, produce and consume authentication tokens and tell the
two communicating parties one another's names.
3.1 Certificate Contents
For purposes of this architecture, a certificate is a data structure
posted in the naming service which proclaims that knowledge of the
private key associated with a stated public key authenticates a named
principal. Certificates are "signed" by some authority, are readable
by anyone, and can be verified by anyone knowing the public key of
the authority. DASS organizes the CA trust hierarchy around the
naming hierarchy. There exists a trusted authority associated with
each directory in the naming hierarchy. Generally, each authority
creates certificates stating the public keys of each of its children
(in the naming hierarchy) and the public key of its parent (in the
naming hierarchy). In this way, anyone knowing the public key of any
authority can learn the public key of any other by "walking the
tree". In order that principals may authenticate even when all of
their ancestor directories do not participate in DASS, authorities
may also create "cross-certificates" which certify the public key of
a named entity which is not a descendent. Rules for finding and
following these cross-certificates are described in the Get_Pub_Keys
routines. Every principal is expected to know the public key of the
CA of the directory in which it is named. This must be securely
learned when the principal is initialized and may be maintained in
some form of local storage or by having the principal sign a
certificate listing the name and public key of its parent and posting
that certificate in the naming service.
The syntax and content of DASS certificates are defined in terms of
X.509 (Directory - Authentication Framework). While that standard
prescribes a single syntax for certificates, DASS considers
certificates to be of one of six types:
- Normal Principal certificates are signed by a CA and certify
the name and public key of a principal where the name of the
CA is a prefix of the name of the principal and is one
component shorter.
- Trusted Authority certificates are signed by an ordinary
principal and certify the name and public key of the
principal's CA (i.e., the CA whose name is a prefix of the
principal's name and is one component shorter).
- Child certificates are signed by a CA and certify the name and
public key of a CA of a descendent directory (i.e., where the
name of the issuing CA is a prefix of the name of the subject
CA and is one component shorter).
- Parent certificates are signed by a CA and certify the name
and public key of the CA of its parent directory (i.e., whose
name is a prefix of the name of the issuer and is one
component shorter).
- Cross certificates are signed by a CA and certify the name and
public key of a CA of a directory where neither name is a
prefix of the other.
- Self certificates are signed by a principal or a CA and the
issuer and subject name are the same. They are not used in
this version of the architecture but are defined as a
convenient data structure in which in which implementations
may insecurely pass public keys and they may be used in the
future in certain key roll-over procedures.
It is intended that some future version of the architecture relax the
restrictions above where prefixes must be one component shorter.
Being able to handle certificates where prefixes are two or more
components shorter complicates the logic of treewalking somewhat and
is not immediately necessary, so such certificates are disallowed for
now.
The syntax of certificates is defined in section 4. For purposes of
the algorithms which follow, the following is the portion of the
content which is used (names in brackets refer to the field names in
the ASN.1 encoded structure):
- UID of the issuer (optional)
- Full name of the issuer (the authority or principal signing)
[issuer]
- UID of the subject (optional)
- Full name of the subject (the authority or principal whose key
is being certified) [subject]
- Public Key of the subject [subjectPublicKey]
- Period of validity (effective date and expiration date)
[valid]
- Signature over the entire content of the certificate created
using the private key of the issuer.
When parsing a certificate, the reader compares the two name fields
to determine what type of certificate it is. For Parent and Trusted
Authority certificates, the names are ignored for purposes of all
further processing. For Child and Normal Principal certificates, only
the suffix by which the child's name is longer than the parent's is
used for further processing. The reason for this is so that if a
branch of the namespace is renamed, all of the certificates in the
moved branch remain valid for purposes of DASS processing. The only
purposes of having full names in these certificates are (1) to comply
with X.509, (2) for possible interoperability with other
architectures using different algorithms, and (3) to allow principals
to securely store their own names in trusted authority certificates
in the case where they do not have enough local storage to keep it.
3.2 Encrypted Private Key Structure
In order that humans need only remember a password rather than a full
set of credentials, and also to make installation of nodes and
servers easier, there is a defined format for encrypting RSA secrets
under a password and posting in the naming service. This structure
need only exist when passwords are used to protect RSA secrets; for
servers which keep their secrets in non-volatile memory or users who
carry smart cards, they are unnecessary.
This structure includes the RSA private/public key pair encrypted
under a DES key. The DES key is computed as a one-way hash of the
password. This structure also optionally includes the UID of the
principal. It is needed only if a single RSA key is shared by
multiple principals (with multiple UIDs).
Since this structure is posted in the name service and may be used by
multiple implementations, its format must be architecturally defined.
The exact encoding is listed in section 4.
3.3 Authentication Tokens
This section of the document defines the contents of the
authentication tokens which are produced and consumed by Create_token
and Accept_token. With DASS, the token passed from the client to the
server is complex, with a large number of optional parts, while the
token passed from server to client (in the case of mutual
authentication only) is small and simple.
The authentication token potentially contains a large number of
parts, most of which are optional depending on the type of
authentication. The following defines the content and purpose of each
of the parts, but does not describe the actual encoding (in the
belief that such details would be distracting). The encoding is in
section 4.
The authentication process begins when the initiator calls
Create_token with the name of the target. This routine returns an
authentication token, which is sent to the target. The target calls
Accept_token passing it the token. Both routines produce a second
"mutual authentication token". The target returns this to the
initiator to prove that it received the token.
3.3.1 Initial Authentication Token
The components of the initial authentication token are (names in
brackets refer to the field names within the ASN.1 encoded structures
defined in section 4):
a) Encrypted Shared Key - [authenticatingKey] - This is a Shared
(DES) key encrypted under the public key of the target. Also
included in the encrypted structure is a validity interval and
a recognizable pattern so that the receiver can tell whether
the decryption was successful.
b) Login Ticket - [sourcePrincipal.userTicket] - This is a
"delegation certificate" signed by a principal's long term
private key delegating to a short term public key. Its "active
ingredients" are:
1) UID of delegating principal [subjectUID]
2) Period of validity [validity]
3) Delegation public key [delegatingPublicKey]
4) Signature by private key of principal
The existence of this signature is testimony that the
private key corresponding to the delegation public key
speaks for the user during the validity interval.
This data structure is optional and will be missing if the
authentication is only on behalf of a Local Username on a
node (i.e., proxy) rather than on behalf of a real principal
with a real key.
c) Shared Key Ticket - [sourcePrincipal.sharedKeyTicketSignature]
- This is a signature of the Encrypted Shared Key by the
Delegation Public key in the Login Ticket. The existence of
this signature is testimony that the DES key in the encrypted
shared key speaks for the user.
This data structure is optional and will be missing if the
authentication is only on behalf of a Local Username on a node
(i.e., proxy) rather than on behalf of a real principal with a
real key. It will also be missing if delegation is taking
place.
d) Node Ticket - [sourceNode.nodeTicketSignature] - This is a
signature of the Encrypted Shared key and a "Local Username"
on the host node by the node's private key. The existence of
this signature is testimony by the node that the DES key in
the encrypted shared key speaks for the named account on that
node.
e) Delegator - [sourcePrincipal.delegator] - This data structure
contains the private login key encrypted under the Shared key.
It is optional and is present only if the initiator is
delegating to the destination.
f) Authenticator - [authenticatorData] - This data structure
contains a timestamp and a message digest of the channel
bindings signed by the Shared Key. It is always present.
g) Principal name - [sourcePrincipal.userName] - This is the name
of the initiating principal. It is optional and will be
missing for strong proxy where bits on the wire are at a
premium and where the destination is capable of independently
constructing the name.
h) Node name - [sourceNode.nodeName] - This is the name of the
initiating node. It is optional and will be missing for strong
proxy where bits on the wire are at a premium and the name is
present elsewhere in the message being passed.
i) Local Username - [sourceNode.username] - This is the local
user name on the initiating node. It is optional and will be
missing for strong proxy where bits on the wire are at a
premium and where the name is present elsewhere in the message
being passed.
3.3.2 Mutual Authentication Token
The authentication buffer sent from the target to the initiator (in
the case of mutual authentication) is much simpler. It contains only
the timestamp taken from the authenticator encrypted under the Shared
Key. It is ASN.1 encoded to allow for future extensions.
3.4 Credentials
DASS organizes its internal state with Credentials structures. There
are many kinds of information which can be stored in credentials.
Rather than making a different kind of data structure for each kind
of data, DASS provides a single credentials structure where most of
its fields are optional. Operating systems must provide some
mechanism for having several processes share credentials. An example
of a mechanism for doing this would be for credentials to be stored
in a file and the name of the file is used as a "handle" by all
processes which use those credentials. Some of the calls which follow
cause credentials structures to be updated. It is important to the
performance of a system that updates to credentials (such as occur
during the routines Verify_Principal_Name and Verify_Node_Name, where
the caches are updated) be visible to all processes sharing those
credentials.
In many of the calls which follow, the credentials passed may be
labeled: claimant credentials, verifier credentials or some such.
This indicates whose credentials are being passed rather than a type
of credentials. DASS supports only one type of credentials, though
the fields present in the credentials of one sort of principal may be
quite different from those present in the credentials of another.
An implementation may choose to support multiple kinds of credentials
structures each of which will support only a subset of the functions
available if it is not implementing the full architecture. This
would be the case, for example, if an implementation did not support
the case where a server both received requests from other principals
and made requests on its own behalf using a single set of
credentials.
The following are a list of the fields that may be contained in a
credentials structure. They are grouped according to common usage.
3.4.1 Claimant information
This is the information used when the holder of these credentials is
requesting something. It includes:
a) Full X.500 name of the principal
b) Public Key of the principal
c) Login Ticket - a login ticket contains:
1) the UID of the principal
2) a period of validity (effective date & expiration date)
3) a delegation public key
4) a signature of the ticket contents by the principal's long
term key
d) Delegation Private Key (corresponding to the public key in c3)
e) Encrypted Shared Key (present only when credentials were
created by accept_token; this information is needed to verify
a node ticket after credentials are accepted)
3.4.2 Verifier information
This is the information needed by a server to decrypt incoming
requests. It is also used by generate_server_ticket to generate a
login ticket.
a) RSA private key.
3.4.3 Trusted Authority
This is information used to seed the walk of the CA hierarchy to
reliably find the public key(s) associated with a name.
Normally, the trusted authority in a set of credentials will be
the directory parent of the principal named in Claimant
information. In some circumstances, it may instead be the
directory parent of the node on which the credentials reside.
a) Full X.500 name of a CA
b) Corresponding RSA Public Key
c) Corresponding UID
3.4.4 Remote node authentication
This information is present only for credentials generated by
"Accept_token". It includes information about any remote node which
vouched for the request.
a) Full X.500 name of the node
b) Local Username on the node
c) Node ticket.
3.4.5 Local node credentials
This information is added by Combine_credentials, and is used by
Create_token to add a node signature to outbound requests.
a) Full X.500 name of the node
b) Local Username on the node
c) RSA private key of the node
3.4.6 Cached outgoing contexts
There may be one (or more) such structures for each server for which
this principal has created authentication tokens. These represent a
cache: they may be discarded at any time with no effect except on
performance. For each association, the following information is kept:
a) Destination RSA Public Key (index)
b) Encrypted Shared key
c) Shared Key Ticket (optional, included if there has been a
non-delegating connection)
d) Node Ticket
e) Delegator (optional, included if there has been a delegating
connection)
f) Validity interval
g) Shared Key
3.4.7 Cached Incoming Contexts
There may be one such structure for each client from which this server
has received an authentication token. These represent a cache: they
may be discarded at any time with no effect except on performance. (An
implementation may choose to keep one System-wide Cache (and list of
incoming timestamps). While it is unlikely that the same Encrypted
Shared Key will result from encryption of Shared keys generated by
different clients or for different servers, an implementation must
ensure that an entry made for one client/server can not be reused by
another client/server. Similarly an implementation may choose to keep
separate caches for the Shared Key/Validity Interval/Delegation Public
Key, the Nodename/UID/key/username and the Principal name/UID/key.)
For each association, the following information is kept:
a) Encrypted Shared key (index)
b) Shared Key
c) Validity Interval
d) Full X.500 name of Client Principal
e) UID of Client Principal
f) Public Key of Client Principal
g) Name of Client Node
h) UID of Client Node
i) Public Key of Client Node
j) Local Username on Client node
k) Delegation Public key of Client Principal's Login Ticket
The Name, UID and Public key of the Principal are all entered
together once the Login Ticket has been verified. Similarly the Node
name, Node key and Username are entered together once the Node Ticket
has been verified. These pieces of information are only present if
they have been verified.
3.4.8 Received Authenticators
A record of all the authenticators received is kept. This is used to
detect replayed messages. (This list must be common to all targets
that could accept the same authenticator (channel bindings will
prevent other targets from accepting the same authenticator). This
includes different `servers' sharing the same key.) The entries in
this list may be deleted when the timestamp is old enough that they
would no longer be accepted. This list is kept separate from the
Cached incoming context in order that the information in the cached
incoming context can be discarded at any time. An implementation
could choose to save these timestamps with the cached incoming
context if it ensures that it can never purge entries from the cache
before the timestamp has aged sufficiently. This list is accessed
based on an extract from the signature from the Authenticator. The
extract must be at least 64 bits, to ensure that it is very unlikely
that 2 authenticators will be received with matching signatures.
a) Extract from Signature from Authenticator
b) Timestamp
If an implementation runs out of space to store additional
authenticators, it may either reject the token which would have
overflowed the table or it may temporarily narrow the allowed clock
skew to allow it to free some of the space used to hold "old"
authenticators. The first strategy will always falsely reject
tokens; the second may cause false rejection of tokens if the allowed
clock skew gets narrowed beyond the actual clock skew in the network.
3.5 CA State
The CA needs to maintain some internal state in order to generate
certificates. This internal state must be protected at all times, and
great care must be taken to prevent its being disclosed. A CA may
choose to maintain additional state information in order to enhance
security. In particular, it is the responsibility of the CA to
assure that the same UID is not serially reused by two holders of a
single name. In most cases, this can be done by creating the UID at
the time the user is registered. To securely permit users to keep
their UIDs when transferring from another CA, the CA must keep a
record of any UIDs used by previous holders of the name. Since
actions of a CA are so security sensitive, the CA should also
maintain an audit trail of all certificates signed so that a history
can be reconstructed in the event of a compromise. Finally, for the
convenience of the CA operator, the CA should record a list of the
directories for which it is responsible and their UIDs so that these
need not be entered whenever the CA is to be used. The state
includes at least the following information:
- Public Key of CA
- Private Key of CA
- Serial number of next certificate to be issued
3.6 Data types used in the routines
There are several abstract data types used as parameters to the
routines described in this section. These are listed here
a) Integer
b) Name
Names unless otherwise noted are always X.500 names. While
most of the design of DASS is naming service independent, the
syntax of certificates and tokens only permits X.500 names to
be used. If DASS is to be used in an environment where some
other form of name is used, those names must be translated
into something syntactically compliant with X.500 using some
mechanism which is beyond the scope of this architecture. The
only other form of name appearing in this architecture is a
"local user name", which corresponds to the simple name of an
"account" on a node. As a type, such names appear in
parameter lists as "Strings".
c) String
A String is a sequence of printable characters.
d) Absolute Time
A UTC time. The precision of these Times is not stated. A
precision of the order of one second in all times is
sufficient.
e) Time Interval
A Time interval is composed of 2 times. A Start Time and an
End Time, both of which are Absolute Times
f) Timestamp
A Timestamp is a time in POSIX format. I.e., two 32 bit
Integers. The first representing seconds, and the second
representing nanoseconds.
g) Duration
A Duration is the length of a time interval.
h) Octet String
A sequence of bytes containing binary data
i) Boolean
A value of either True or False
j) UID
A UID is an bit string of 128 bits.
k) OID
An OID is an ISO Object Identifier.
l) Shared key
A Shared key is a DES key, a sequence of 8 bytes
m) CA State
A structure of the form described in '3.5
n) Credentials
A structure of the form described in '3.4
o) Certificate
An ASN.1 encoding of the structure described in '3.1
p) Authentication Token
An ASN.1 encoding of the structure described in '3.3.1
q) Mutual Authentication Token
An ASN.1 encoding of the structure described in '3.3.2
r) Encrypted Credentials
An ASN.1 encoding of the structure described in '3.2
s) Public key
A representation of an RSA Public key, including all the
information needed to encode the public key in a certificate.
t) Set of Public key/UID pairs
A set of Public key/UID pairs. This Data type is only used
internally in DASS - it does not appear in any interface used
to other architectures.
3.7 Error conditions
These routines can return the following error conditions (an
implementation may indicate errors with more or less precision):
a) Incomplete chain of trustworthy CAs
b) Target has no keys which can be trusted.
c) Invalid Authentication Token
d) Login Ticket Expired
e) Invalid Password
f) Invalid Credentials
g) Invalid Authenticator
h) Duplicate Authenticator
3.8 Certificate Maintenance Functions
Authentication services depend on a set of data structures maintained
in the naming service. There are two kinds of information:
Certificates, which associate names and public keys and are signed by
off-line Certification Authorities; and Encrypted Credentials, which
contain RSA Private Keys and certain context information encrypted
under passwords. Encrypted Credentials are only necessary in
environments where passwords are used. Credentials may alternatively
be stored in some other secure manner (for example on a smart card).
The certificate maintenance services are designed so that the most
sensitive - the actual signing of certificates - may be done by an
off-line authority. Once signed, certificates must be posted in the
naming service to be believed. The precise mechanisms for moving
certificates between off-line CAs and the on-line naming service are
implementation dependent. For the off-line mechanisms to provide any
actual security, the CAs must be told what to sign in some reliable
manner. The mechanisms for doing this are implementation dependent.
The abstract interface says that the CA is given all of the
information that goes into a certificate and it produces the signed
certificate. There are requirements surrounding the auditing of a
CA's actions. The details of what actions are audited, where the
audit trail is maintained, and what utilities exist to search that
audit trail are not specified here. The functions a CA must provide
are:
3.8.1 Install CA
Install_CA(
keysize Integer, --inputs
CA_state CA State, --outputs
CA_Public_Key Public Key)
This routine need only generate a public/private key pair of the
requested size. Keysize is likely to be in implementation constant
rather than a parameter. The value is likely to be either 512 or
640. Key sizes throughout will have to increase over time as
factoring technology and CPU speeds improve. Both keys are stored as
part of the CA_state; the public key is returned so that other CAs
may cross-certify this one. The `Next Serial number' in the CA state
is set to 1.
3.8.2 Create Certificate
Create_certificate(
--inputs
Renewal Boolean,
Include_UID Boolean,
Issuer_name Name,
Issuer_UID UID,
Effective_date Absolute Time,
Expiration_date Absolute Time,
Subject_name Name,
Subject_UID UID,
Subject_public_key Public Key,
--updated
CA_state CA State,
--outputs
Certificate Certificate)
This procedure creates and signs a certificate. Note that the
various contents of the certificate must be communicated to the CA in
some reliable fashion. The Issuer_name and UID are the name and UID
of the directory on whose behalf the certificate is being signed.
This routine formats and signs a certificate with the private key in
CA_state. It audits the creation of the certificate and updates the
sequence number which is part of CA_state. The Issuer and Subject
names are X.500 names. If the CA state includes a history of what
UIDs have previously been used by what names, this call will only
succeed in the collision case if the Renewal boolean is set true. If
the Include_UID boolean is set true, this routine will generate a
1992 format X.509 certificate; otherwise it will generate a 1988
format X.509 certificate.
3.8.3 Create Principal
Create_principal(
--inputs
Password String,
keysize Integer,
Principal_name Name,
Principal_UID UID,
Parent_Public_key Public Key,
Parent_UID UID,
--outputs
Encrypted_Credentials Encrypted Credentials,
Trusted_authority_certificate Certificate)
This procedure creates a new principal by generating a new
public/private key pair, encrypting the public and private keys under
the password, and signing a trusted authority certificate for the
parent CA. In an implementation not using passwords (e.g., smart
cards), an alternative mechanism must be used for initially creating
principals. If a principal has protected storage for trusted
authority information, it is not necessary to create a trusted
authority certificate and store it in the naming service. Some
procedure analogous to this one must be executed, however, in which
the principal learns the public key and UID of its CA and its own
name.
This routine creates two output structures with the following steps:
a) Generate a public/private key pair using the indicated
keysize. An implementation will likely fix the keysize as an
implementation constant, most likely 512 or 640 bits, rather
than accepting it as a parameter. Key sizes generally will
have to increase over time as factoring technology and CPU
speeds improve.
b) Form the encrypted credentials by using the public key,
private key, and Principal_UID and encrypting them using a
hash of the password as the key.
c) Generate a trusted authority certificate (which is identical
in format to a "parent" certificate) getting fields as
follows:
1) Certificate version is X.509 1992.
2) Issuer name is the Principal name (which is an X.500 name).
3) Issuer UID is the Principal UID.
4) Validity is for all time.
5) Subject name is constructed from the Principal name by
removing the last simple name from the hierarchical name.
6) Subject UID is the CA_UID.
7) Subject Public Key is the CA_Public_Key
8) Sequence number is 1.
9) Sign the certificate with the newly generated private key of
the principal.
3.8.4 Change Password
Change_password( --inputs
Encrypted_credentials Encrypted Credentials,
Old_password String,
New_password String,
--outputs
Encrypted_credentials Encrypted Credentials)
If credentials are stored encrypted under a password, it is possible
to change the password if the old one is known. Note that it is
insufficient to just change a user's password if the password has
been disclosed. Anyone knowing the old password may have already
learned the user's private key. If a password has been disclosed,
the secure recovery procedure is to call create_principal again
followed by create_certificate to certify the new key.
Using DASS, it may not be appropriate for users to periodically
change their passwords as a precaution unless they also change their
private keys by the procedure above. The only likely use of the
change_password procedure is to handle the case where an
administrator has chosen a password for the user in the course of
setting up the account and the user wishes to change it to something
the user can remember. A future version of the architecture may
smooth key roll-over by having the change_password command also
generate a new key and sign a "self" certificate in which the old key
certifies the new one. As a separate step, a CA which notices a self
certificate posted in the naming service could certify the new key
instead of the old one when the user's certificate is renewed. While
this procedure is not as rapid or as reliable as having the user
directly interact with the CA, it offers a reasonable tradeoff
between security and convenience when there is no evidence of
password compromise.
This routine simply decrypts the encrypted credentials structure
supplied using the password supplied. It returns a bad status if the
format of the decrypted information is bad (indicating an incorrect
password). Otherwise, it creates a new encrypted credentials
structure by encrypting the same data with the new password. It would
be highly desirable for the user interface to this function to
provide the capability to randomly generate passwords and prohibit
easily guessed user chosen passwords using length, character set, and
dictionary lookup rules, but such capabilities are beyond the scope
of this document. If encrypted credentials are stored in some local
secure storage, the above function is all that is necessary (in fact,
if the storage is sufficiently secure, no password is needed;
credentials could be stored unenciphered). If they are stored in a
naming service, this function must be coupled with one which
retrieves the old encrypted credentials from the naming service and
stores the new. The full protocol is likely to include access
control checks that require the principal to acquire credentials and
produce tokens. For best security, the encrypted credentials should
be accessible only through a login agent. The role of the login
agent is to audit and limit the rate of password guessing. If
passwords are well chosen, there is no significant threat from
password guessing because searching the space is computationally
infeasible. In the context of a login agent, change password will be
implemented with a specialized protocol requiring knowledge of the
password and (for best security) a trusted authority from which the
public key of the login agent can be learned. See section 2.3.2 for
the plans for the non-X.500 credential storage facility.
3.8.5 Change Name
Change_name(
--inputs
Claimant_Credentials Credentials,
New_name Name,
CA_Public_Key Public Key,
CA_UID UID,
--outputs
Trusted_Authority_Certificate Certificate)
DASS permits a principal to have many current aliases, but only one
current name. A principal can authenticate itself as any of its
aliases but verifies the names of others relative to the name by
which it knows itself. Aliases can be created simply by using the
create_certificate function once for each alias. To change the name
of a principal, however, requires that the principal securely learn
the public key and UID of its new parent CA. As with
create_principal, if a principal has secure private storage for its
trusted authority information, it need not create a certificate, but
some analogous procedure must be able to install new naming
information.
This routine produces a new Trusted Authority Certificate with
contents as follows:
a) Issuer name is New_name (an