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 X.500 name)
b) Issuer_UID is Principal UID from Credentials.
c) Validity is for all time.
d) Subject name is constructed from the Issuer name by removing
the last simple name from the hierarchical name, and
converting to an X.500 name.
e) Subject UID is CA_UID
f) Subject Public Key is CA_Public_Key
g) Sequence number is 1.
h) The certificate is signed with the private key of the
principal from the credentials. Note that this call will only
succeed if the principal's private key is in the credentials,
which will only be true if the credentials were created by
calling Create_server_credentials.
3.9 Credential Maintenance Functions
DASS credentials can potentially have information about two
principals. This functionality is included to support the case
where a user on a node has two identities that might be
recognized for purposes of managing access controls. First,
there is the user's network identity; second, there is an
identity as controlling a particular "account" or "username" on
that node. There are two reasons for recognizing this second
identity: first, access controls might be specified such that
only a user is only permitted access to certain resources when
coming through certain trusted nodes (e.g., files that can't be
accessed from a terminal at home); and second, before the
transition strategy to global identities is complete, as a way to
refer to USER@NODE in a way analogous to existing mechanisms but
with greater security.
The mapping of global usernames to local user names on a node is
outside the scope of DASS. This is done via a "proxy database"
or some analogous local mechanism. What DASS provides are
mechanisms for adding node oriented credentials into a user's
credentials structure, carrying the dual authentication
information in authentication tokens, and extracting the
information from the credentials structure created by
Accept_token.
Some applications of DASS will not make use of the node
authentication related extensions. In that case, they will never
use the Combine_credentials, Create_credentials, Get_node_info,
or Verify_node_name functions.
The "normal" sequence of events surrounding a user logging into a
node are as follows:
a) When the user logs in, he types either a local user ID known
to the node or a global name (the details of the user
interface are implementation specific). Through some sort of
local mapping, the node determines both a global name and a
local account name. The user also enters a password
corresponding to the global name.
b) The node calls network_login specifying the user's global name
and the supplied password. The result is credentials which
can be used to access network services but which have not yet
been verified to be valid.
c) The node calls verify_principal_name using its own credentials
to verify the authenticity of the user's credentials (these
node credentials must have previously been established by a
call to initialize_server during node initialization).
d) If that test succeeds, the node adds its credentials to those
of the user by calling combine_credentials.
The set of facilities for manipulating credentials follow:
3.9.1 Network login
Network_login(
--inputs
Name Name,
password String,
keysize Integer,
expiration Time interval,
TA_credentials Credentials,--optional
--outputs
Claimant_credentials Credentials)
This function creates credentials for a principal when the principal
"logs into the network".
Name is the X.500 name of the principal.
Password is a secret which authenticates the principal to the
network.
Keysize specifies the size of the temporary "login" or "delegation"
key. In a real implementation, it is expected to be an
implementation constant (most likely 384 or 512 bits).
Expiration sets a lifetime for the credentials created. For a normal
login, this is likely to be an implementation constant on the order
of 8-72 hours. Some mechanism for overriding it must be provided to
make it possible (for example) to submit a background job that might
run days or even months after they are submitted.
TA_credentials are used if the encrypted credentials are protected
by a login agent. If they are missing, the password will be less well
protected from guessing attacks.
This routine does not (as one might expect) securely authenticate the
principal to the calling procedure. Since the password is used to
obtain the principal's private key, this call will normally fail if
the principal supplies an invalid password. A penetrator who has
compromised the naming service could plant fake encrypted credentials
under any name and impersonate that name as far as this call is
concerned. A caller that wishes to authenticate the user in addition
to obtaining credentials to be able to act on the user's behalf
should call Verify_principal_name (below) with the created
credentials and the credentials of the calling process.
This routine constructs a credentials structure from information
found in the naming service encrypted using the supplied password.
a) If the encrypted credentials structure is protected with a
login agent, retrieve the public key of the login agent:
1) If TA_credentials are available, use them in a call to
Get_Pub_Keys to get the public key of the login agent (whose
name is derived from the name of the principal by truncating
the last element of the RDN and adding CSS=X509).
2) If TA_credentials are not available, look up the public key
of the login agent in the naming service.
Login agents limit and audit password guesses, and are
important when passwords may not be well chosen (as when users
are allowed to choose their own). To fully prevent the
password guessing threat, principals may only log onto nodes
that already have TA_credentials which can be used to
authenticate the login agent. To support nodes which have no
credentials of their own and to allow this procedure to
support node initialization, it is possible to network login
without TA credentials.
A principal who logs into a node that lacks TA credentials is
subject to the following subtle security threat: A penetrator
who impersonates the naming service could post his own public
key and address as those of the login agent. This procedure
would then in the process of logging in reveal the the
penetrator enough information for the penetrator to mount an
unaudited password guessing attack against the principal's
credentials.
b) Retrieve the encrypted credentials from the naming service or
login agent. In the case of the login agent, the password is
one-way hashed to produce proof of knowledge of the password
and the hashed value is supplied to the login agent encrypted
under its public key as part of the request.
c) Decrypt the encrypted credentials structure using a the
supplied password. Verify that the decryption was successful
by verifying that the resulting structure can be parsed
according the the ASN.1 rules for Encrypted_Credentials and
that the two included primes when multiplied together produce
the included modulus. If the decryption was unsuccessful then
the routine returns the `Invalid password' error status. The
decryption results in both the Private Key and the Public Key.
d) Generate a public/private key pair for the Delegation Key,
using the indicated keysize. Key size is likely to be an
implementation constant rather than a supplied parameter, with
likely values being 384 and 512 bits. Key sizes generally
will have to increase over time as factoring technology and
CPU speeds improve. Delegation keys can be relatively shorter
than long term keys because DASS is designed so that
compromise of the delegation key after it has expired does not
result in a security compromise. An important advantage of
making key size an implementation constant is that nodes can
generate key pairs in advance, thus speeding up this procedure.
Key generation is the most CPU intensive RSA procedure and
could make login annoyingly slow.
e) Construct a Login Ticket by signing with the user's private
key a combination of the public key, a validity period
constructed from the current time and the expiration passed in
the call, and the principal UID found in the encrypted-key
structure.
f) Forget the user's private key.
g) Retrieve from the naming service any trusted authority
certificates stored with the user's entry. Discard any that
are not signed by the user's public key and UID. An
implementation in which the login node has credentials of its
own may choose its trusted authority information instead of
retrieving and verifying trusted authority certificates from
the naming service. This will have a subtle effect on the
security of the resulting system.
h) Construct a credentials structure from:
1) Claimant credentials:
(i) Name of the principal from calling parameter
(ii) Login Ticket as constructed in (e)
(iii)Delegation Private key as constructed in (d)
(iv) Public key from the encrypted credentials structure
2) No verifier credentials
3) Trusted Authorities: for the most recently signed trusted
authority certificate (There is normally only one Trusted
Authority Certificate. If there is more than one then an
implementation may choose to maintain a list of all the valid
keys. They should all refer to the same CA (UID and name).):
(i) Name of the CA from the subject field of the certificate
(ii) Public Key of the CA from the subject public key field
(iii)UID of the CA from the subject UID field
4) no remote node credentials
5) no local node credentials
6) no cached outgoing associations
7) no cached incoming associations
3.9.2 Create Credentials
Create_credentials(
--outputs
Claimant_credentials Credentials)
This routine creates an "empty" credentials structure. It is needed
in the case of a user logging into a node and obtaining node oriented
credentials but no global username credentials. Because the
"combine_credentials" call wants to modify a set of user credentials
rather than create a new set, this call is needed to produce the
"shell" for combine_credentials to fill in.
It is unlikely that any real implementation would support this
function, but rather would have some functions which combine
network_login, create_credentials, and combine_credentials in
whatever ways are supported by that node.
3.9.3 Combine Credentials
Combine_credentials(
--inputs
node_credentials Credentials,
localusername String,
--updated
user_credentials Credentials)
This routine is provided by implementations which support the notion
of local node credentials. After the node has verified to its own
satisfaction that the user_credentials are entitled to access to a
particular local account, this call adds node credential information
to the user_credential structure. This function may be applied to
user_credentials created by network_login, create_credentials, or
accept_token.
a) Fill in the local node credentials substructure of
user_credentials as follows:
1) Full name of the node: from Full name of the Principal in
node_credentials
2) Local username on the node: from proxy lookup
3) RSA private key of the node: from verifier credentials in
node_credentials
b) Optionally, change the trusted authorities to match the
trusted authorities from the node credentials. This is an
implementation option, done most likely as a performance
optimization. The only case where this option is required is
where no trusted authorities existed in the user credentials
(because they were created by create_credentials of
accept_token). Server credentials should generally keep their
own trusted authorities.
It is likely that an implementation will choose not to replicate its
node credentials in every credentials structure that it supports, but
rather will maintain some sort of pointer to a single copy. This
algorithm is stated as it is only for ease of specification.
3.9.4 Initialize_server
initialize_server(
--inputs
Name Name,
password String,
TA_credentials Credentials, --optional
--outputs
Server_credentials Credentials)
Somehow a server must get access to its credentials. One way is for
the credentials to be stored in the naming service like user
credentials encrypted under a service password. The service then
needs to gain at startup time access to a service password. This may
be easier to manage and is not insecure so long as the service
password is well chosen. Alternately, the service needs some
mechanism to gain access directly to its credentials. The credentials
created by this call are intended to be very long lived. They do not
time out, so a node or server might store them in Non-Volatile memory
after "initial installation" rather than calling this routine at each
"boot". These credentials are shared between all servers which use
the same key. This routine works as follows:
a) Retrieve from the naming service or login agent the encrypted
credentials structure corresponding to the supplied name. See
Network_login for a discussion of the use of TA_credentials
and login agents.
b) Decrypt that structure using a one-way hash of the supplied
password. Verify that the decryption was successful. Verify
that the public key in the structure matches the private key.
c) Retrieve from the naming service any trusted authority
certificates stored under the supplied name. Discard any which
do not contain the UID from the encrypted credentials
structure or are not signed by the key in the encrypted
credentials structure.
d) Construct a credentials structure from:
1) Claimant credentials:
(i) Name of the principal from the calling parameter
(ii) UID of the principal from the encrypted-key structure
(iii) No login ticket
(iv) No login secret key
2) Verifier credentials:
(i) Server secret key from the encrypted-key structure
3) Trusted Authorities: from the most recently signed Trusted
Authority Certificate:
(i) Name of CA from the Subject Name field
(ii) UID of the CA from the Subject UID field
(iii) Public Key of the CA from the Subject Public Key field
4) no node credentials
5) no cached outgoing associations
6) no cached incoming associations
3.9.5 Generate Server Ticket
generate_server_ticket(
--inputs
expiration Time interval,
--updated
Server_credentials Credentials)
Server credentials created by initialize_server can be used to accept
incoming authentication tokens and can act as node_credentials for
outgoing authentications, but cannot create user_credentials of their
own. If a server initiates connections on its own behalf, it must
have a ticket just like any other user might have. That ticket has
limited lifetime and the right to act on behalf of the server can be
delegated. The server cannot, however, delegate the right to receive
connections intended for it. An implementation must come up with a
policy for the expiration of server tickets and how long before
expiration they are renewed. A likely policy is for this procedure
to be implicitly called by Create_token if there is no current ticket
present in the credentials. If so, this interface need not be
exposed.
This routine is implemented as follows:
a) Generate an RSA public/private key pair.
b) Compute a validity interval from the current time and the
expiration supplied.
c) Construct a login ticket from the RSA public key (from a),
validity interval (from b), the UID from the credentials, and
signed with the server key in the credentials. (Discard
previous Login Ticket if there was one).
d) Discard all information in the Cached Outgoing Contexts.
3.9.6 Delete Credentials
delete_credentials(
--updated
credentials Credentials)
Erases the secrets in the credentials structure and deallocates the
storage.
3.10 Authentication Procedures
The guts of the authentication process takes place in the next two
calls. When one principal wishes to authenticate to another, it calls
Create_token and sends the token which results to the other. The
recipient calls Accept_token and creates a new set of credentials.
The other calls in this section manipulate the received credentials
in order to retrieve its contents and verify the identity of the
token creator.
3.10.1 Create Token
Create_token(
--inputs
target_name Name,
deleg_req_flag Boolean,
mutual_req_flag Boolean,
replay_det_req_flag Boolean,
sequence_req_flag Boolean,
chan_bindings Octet String,
Include_principal_name Boolean,
Include_node_name Boolean,
Include_username Boolean,
--updated
claimant_credentials Credentials,
--outputs
authentication_token Authentication token,
mutual_authentication_token
Mutual Authentication token,
Shared_key Shared Key,
instance_identifier Timestamp)
This routine is used by the initiator of a connection to create an
authentication token which will prove its identity. If the claimant
credentials includes node/account information, the token will include
node authentication.
target_name is the X.500 name of the intended recipient of the token.
Only an entity with access to the private key associated with that
name will be able to verify the created token and generate the
mutual_authentication_token.
deleg_req_flag indicates whether the caller wishes to delegate to the
recipient of the token. If it is set, the delegated_credentials
returned by Accept_token will be capable of generating tokens on
behalf of the caller. Node based authentication information cannot be
delegated. The mutual_req_flag, replay_det_req_flag , and
sequence_req_flag are put in the authentication token and passed to
the target. This information is included in the token to make it
easier to implement the GSSAPI over DASS. DASS itself makes no use
of this information.
In most applications, the purpose of a token exchange is to
authenticate the principals controlling the two ends of a
communication channel. chan_bindings contains an identifier of the
channel which is being authenticated, and thus its format and content
should be tied to the underlying communication protocol. DASS only
guarantees that the information has been communicated reliably to the
named target. If DASS is used with a cryptographically protected
channel (such as SP4), this data should contain a one-way hash of the
key used to encrypt the channel. If that channel is multiplexed, the
data should also include the ID of the subchannel. If the channel is
not encrypted, the network must be trusted not to modify data on a
connection. The source and target network addresses and a connection
ID should be included in the chan_bindings at the source and checked
at the target. A token exchange also results in the two ends sharing
a key and an instance identifier. If that key and instance
identifier are used to cryptographically protect subsequent
communications, then chan_bindings need not have any cryptographic
significance but may be used to differentiate multiple entities
sharing the public keys of communicating principals. For example, if
a service is replicated and all replicas share a public key,
chan_bindings should include something that identifies a single
instance of the service (such as current address) so that the token
cannot be successfully presented to more than one of the servers.
include_principal_name, include_node_name, and include_username are
flags which determine whether the principal name, node name, and/or
username from the credentials structure are to be included in the
token. This information is made optional in a token so that
applications which communicate this information out of band can
produce "compressed" tokens. If this information is included in the
token, it will be used to populate the corresponding fields in the
credentials structure created by Accept_token. claimant_credentials
are the credentials of the calling procedure. The secrets contained
therein are used to sign the token and the trusted authorities are
used to securely learn the public key of the target. The cached
outgoing contexts portion of the credentials may be updated as a side
effect of this call.
The major output of this routine is an authentication_token which
can be passed to the target in order to authenticate the caller.
In addition to returning an authentication token, this routine
returns a mutual_authentication_token, a shared_key, and an
instance_identifier. The mutual authentication token is the same as
the one generated by the Accept_token call at the target. If the
protocol using DASS wishes mutual authentication, the target should
return this token to the source. The source will compare it to the
one returned by this routine using Compare_Mutual_Token (below) and
know that the token was accepted at its proper destination.
The DES key and instance identifier can be used to encrypt or sign
data to be sent to this target. The key and instance will be given to
the target by Accept_token, and the key will only be known by the two
parties to the authentication. If a single set of credentials is used
to authenticate to the same target more than once, the same DES key
is likely to be returned each time. If the parties wish to protect
against the possibility of an outside agent mixing and matching
messages from one authenticated session with those of another, they
should include the instance identifier in the messages. The instance
identifier is a timestamp and it is guaranteed that the DES
key/instance identifier pair will be unique.
An implementation may wish to "hide" the DES key from calling
applications by placing it in system storage and providing calls
which encrypt/decrypt/sign/verify using the key.
The primary tasks of this routine are to create its output
parameters. As a side effect, it may also update claimant_credentials
It's algorithm is as follows:
a) The login ticket is checked. If it has passed the end of its
lifetime an `Login Ticket Expired' error is returned. If there
is a login ticket, but no corresponding private key then an
`Invalid credentials' error is returned (this is the case if
the credentials were created by an authentication-without-
delegation operation). If there is no login ticket or an
expired one and if the long term private key is present in the
credentials, an implementation may choose to automatically call
create_server_ticket to renew the ticket.
b) Create new timestamp using the current time. (This timestamp
must be unique for this Shared Key. The timestamp is a 64 bit
POSIX time, with a resolution of 1 nanosecond An implemen tation
must ensure that timestamps cannot be reused.)
c) The public key and UID of target_name are looked up by calling
get_pub_keys, using the target_name and the Trusted Authority
section of the claimant_credentials structure. If none is
found, an error status is returned. Otherwise, the cached
outbound connections portion of credentials are searched
(indexed by target Public Key) for a cached Shared key with a
validity interval which has not expired. If a suitable one is
found skip to step g, else create a cache entry as follows:
d) Destination Public Key is the one found looking up the target.
A Shared Key is generated at random. A validity interval is
chosen according to node policy but not to exceed the validity
interval of the ticket in the credentials (if any).
e) Create the Encrypted Shared Key, using the public key of the
Target, and place in the cache.
f) If node authentication credentials are available in the
credentials structure, create a "Node Ticket" signature using
the node secret and include it in the cache.
g) If delegation is requested and no delegator is present in the
cache, create one by encrypting the delegation private key
under the Shared key. The delegation private key is
represented as an ASN.1 data structure containing only one of
the primes (p).
h) If delegation is not requested and no Shared Key Ticket is in
the cache, create one by signing the requisite information
with the delegation private key.
i) Create the Authenticator. The contents of the Authenticator
(including the channel bindings) are encoded into ASN.1, and
the signature is computed. The Authenticator is then
re-encoded, without including the Channel Bindings but using
the same signature.
j) Create output_token as follows:
1) Encrypted Shared Key from cache
2) Login Ticket from Claimant Credentials (if present)
3) Shared Key Ticket from cache (if no delegation and if
present)
4) Node Ticket from cache (if present)
5) Delegator from cache (if delegation and if present)
6) Authenticator
7) Principal name from credentials (if present and parameter
requests this)
8) Node name from credentials (if present and parameter request
this)
9) Local Username from credentials (if present and parameter
requests this)
k) Compute Mutual_authentication_token by encrypting the
timestamp from the authenticator using the Shared key.
l) The instance_identifier is the timestamp. This and the Shared
key are returned for use by the caller for further encryption
operations (if these are supported).
3.10.2 Accept_token
Accept_token(
--inputs
authentication_token Authentication Token,
chan_bindings Octet String,
--updated
verifying_credentials Credentials,
--outputs
accepted_credentials Credentials,
deleg_req_flag Boolean,
mutual_req_flag Boolean,
replay_det_req_flag Boolean,
sequence_req_flag Boolean,
mutual_authentication_token
Mutual authentication token
shared_key Shared Key,
instance_identifier Timestamp)
This routine is used by the recipient of an authentication token to
validate it. authentication_token is the token as received;
chan_bindings is the identifier of the channel being authenticated.
See the description of Create_token for information on the
appropriate contents for chan_bindings. DASS does not enforce any
particular content, but checks to assure that the same value is
supplied to both Create_token and Accept_token.