Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 1507

DASS - Distributed Authentication Security Service

Pages: 119
Experimental
Part 3 of 4 – Pages 55 to 89
First   Prev   Next

Top   ToC   RFC1507 - Page 55   prevText
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.
Top   ToC   RFC1507 - Page 56
    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
Top   ToC   RFC1507 - Page 57
   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
Top   ToC   RFC1507 - Page 58
       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
Top   ToC   RFC1507 - Page 59
      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
Top   ToC   RFC1507 - Page 60
   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
Top   ToC   RFC1507 - Page 61
   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
Top   ToC   RFC1507 - Page 62
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.
Top   ToC   RFC1507 - Page 63
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
Top   ToC   RFC1507 - Page 64
   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
Top   ToC   RFC1507 - Page 65
   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
Top   ToC   RFC1507 - Page 66
       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.
Top   ToC   RFC1507 - Page 67
    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.

   Verifying_credentials are the credentials of the recipient of the
   token.  They must include the private key of the entity named as the
   target in Create_token or the call will fail.  The cached incoming
   contexts section of the verifying credentials may be modified as a
   side effect of this call.

   Accepted_credentials will contain additional information about the
   token creator. If delegation was requested, these credentials can be
   used to make additional calls to Create_token on the creator's
   behalf. Whether or not delegation was requested, they can also be
   used in the calls which follow to gain additional information about
   the token creator.

   The deleg_req_flag indicates whether the accepted_credentials include
   delegation which can be used by the recipient to act on behalf of the
   principal.  Mutual_req_flag, replay_det_req_flag, and
   sequence_req_flag are passed through from Create_token in support of
Top   ToC   RFC1507 - Page 68
   the GSSAPI.  DASS makes no use of these fields.

   The mutual_authentication_token can be returned to the token creator
   as proof of receipt. In many protocols, this will be used by a client
   to authenticate a server. Only the genuine server would be able to
   compute the mutual_authentication_token from the token.

   The shared_key and instance_identifier can be used to encrypt or sign
   data between the two authenticating parties. See Create_token.

   This routine verifies the contents of the authentication token in the
   context of the verifying credentials (In particular, the Private Key
   of the server is used.  Also, the Cached Incoming Contexts and
   Incoming Timestamp list is used.) and returns information about it.
   The algorithm updates a cache of information. This cache is not
   updated if the algorithm exits with an error. The algorithm is as
   follows:

    a) If there is a Login Ticket, but no Shared Key Ticket or
       Delegator then exit with error `Invalid Authenticator'. If
       there is a Shared Key Ticket or Delegator, but no Login Ticket
       then exit with error `Invalid Authentication Token'.

       Look up the Encrypted Shared key in the Cached Incoming Contexts
       of the credentials structure. (This cache entry is used during
       the execution of this routine. An implementation must ensure that
       references to the cache entry can not be affected by other users
       modifying the cache.  One way is to use a copy of the cache entry,
       and update it at exit.)  If it is not found then create
       a new cache entry as follows:

      1) Encrypted Shared Key, from the Authentication Token.

      2) Shared Key and Validity Interval, by decrypting the
         Encrypted Shared Key using the server private key in
         credentials. If the decryption fails then exit with error
         `Invalid Authentication Token'.

    b) Check that the Validity Interval (in the cache entry) includes
       the current time; return `Invalid Authentication Token' if not.

       Check the Timestamp is within max-clock-skew of the current
       time, return `invalid Authentication Token' if not.

       Reconstruct the Authenticator including the Channel Bindings
       passed as a parameter.
Top   ToC   RFC1507 - Page 69
       Check that the reconstructed Authenticator is signed by the
       Shared key. If not then exit with error `Invalid
       Authentication Token'.

       Look up the Authenticator Signature in the Received
       Authenticators. If the same Signature is found in the list
       then exit with error `Duplicate Authenticator'. Otherwise add
       the Signature and timestamp to the list.

       If there is a Login Ticket and the Delegation Public key is in
       the cache entry, then check that the same key is specified in
       the Login Ticket, if not then exit with error `Invalid
       Authentication Token'. Place the Delegation Public key in the
       cache if it is not already there.

       If there is a Login Ticket, the Delegation Public key was not
       previously in the cache entry, and there is a Shared Key
       Ticket in the Authentication Token, then check that the Shared
       Key Ticket is signed by the Delegation Public Key in the Login
       Ticket. If not then exit with error `Invalid Authentication
       Token'.

       If a delegator is present in the message then decrypt the
       delegator using the Shared key. If the private key does not
       match the Delegation Public key then exit with error
       `Invalid Authentication Token' (The prime in the delegator
       is used to find the other prime (from the modulus). The division
       must not have a remainder.  Neither prime may be 1. The two
       primes are then used to reconstruct any other information
       needed to perform cryptographic operations.).

       Build the delegation credentials data structure as follows:

       1) Claimant credentials:
        (i)  Login Ticket from the Authentication token
        (ii) Delegation Private key from the decrypted delegator if
              the token is delegating.
        (iii)Encrypted Shared Key from the Authentication token.
       2) There are no verifier credentials.
       3) Trusted authorities are copied from the verifying_credentials
          passed to this routine (If an implementation is able to
          obtain the original Trusted Authorities of the Principal then
          it may do so instead of using the server's Trusted
          Authorities.).
       4) Remote node credentials (Node name, Username, Node Ticket)
       5) There are no local node credentials.
       6) There are no cached contexts.
Top   ToC   RFC1507 - Page 70
    c) The returned boolean values are obtained from the
       Authenticator.

    d) Mutual_authentication_token is computed by encrypting the
       timestamp from the Authenticator with the Shared key from the
       cache.

    e) Instance_identifier is the timestamp from the Authenticator.
       This and the Shared key are returned to the caller for further
       encryption operations (if these are supported).

3.10.3 Compare Mutual Token

   Compare_mutual_token(
                                                    --inputs
                       Generated_token    Mutual authentication token,
                       Received_token     Mutual authentication token,
                                                     --outputs
                       equality_flag         Boolean)

   This routine compares two mutual authentication tokens and tells
   whether they match.  In the expected use, the first is the token
   generated by Create_token at the initiating end and the second is the
   token generated by Accept_token at the accepting end and returned to
   the initiating end.  This routine can be implemented as a byte by
   byte comparison of the two parameters.

3.10.4 Get Node Info

   get_node_info(
                                                    --inputs
                       accepted_credentials  Credentials,
                                                    --outputs
                       nodename              Name,
                       username              String)

   This routine extracts from accepted credentials the name of the node
   from which the authentication token came and the named account on
   that node. Because this information is not cryptographically
   protected within the token, this information can only be regarded as
   a "hint" by the receiving application.  It can, however, be verified
   using Verify_node_name in a cryptographically secure manner.  This
   information will only be present if these are accepted credentials
   and it the caller of Create_token set the include_node_name and/or
   include_username flags.

   An actual implementation is not likely to have get_node_info and
   verify_node_name as separate calls.  They are specified this way
Top   ToC   RFC1507 - Page 71
   because there are different ways this information might be used.  For
   most applications, the nodename and username will be included in the
   token, and a single function might extract and verify them (it might
   in fact be part of accept token).  For other applications, the
   nodename and username will not be in the token but rather will be
   computed from other information passed during connection initiation
   so a call would have to take these as inputs.  Still other
   applications such as ACL evaluators that want to support the renaming
   and aliasing capabilities of DASS would defer verifying node
   information until they came upon an ACL which allowed access only
   from a particular node.  They would then verify that the name on the
   ACL was an authenticatable alias for the node which created the
   token.  All of these uses can be defined in terms of calls to
   get_node_info and verify_node_name.

3.10.5 Get Principal UID

   get_principal_uid(
                                                    --inputs
                       accepted_credentials  Credentials,
                                                    --outputs
                       uid                   UID)

   This routine extracts a principal UID from a set of credentials.

   As with Get_Node_Info, this interface is not likely to appear in an
   actual implementation, but rather will be bundled with other
   routines.  It is specified this way because there might be a variety
   of algorithms by which credentials are evaluated and all of them can
   be defined in terms of these primitives.

   In DASS, it is possible for a principal to have many aliases.  This
   can happen either because the principal was given multiple names to
   limit the number of CAs that need to be trusted when authenticating
   to different servers or because the principal's name has changed and
   the old name remains behind as an alias.  Accept_token returns the
   name by which the principal identified itself when creating its
   credentials. A service may know the user by some alias. The normal
   way to handle this is for the service to know the principal's UID
   (which is constant over name changes) and to compare it with the UID
   in the token to identify a likely alias situation. It gets the UID
   from the token using this routine. It then confirms the alias by
   calling verify_principal_name.

   The UID is in a signed portion of accepted credentials, but the
   signature may not have been verified at the time this call is issued.
   The information returned by this routine must therefore be regarded
   as a hint.  If a call to Verify_principal_name succeeds, however,
Top   ToC   RFC1507 - Page 72
   then the caller can securely know that the name given to that routine
   and the UID returned by this one are the authenticated source of the
   token.

3.10.6 Get Principal Name

   get_principal_name(
                                                    --inputs
                       accepted_credentials  Credentials,
                                                    --outputs
                       name                  Name)

   This routine extracts a principal name from a set of credentials.
   This name is the name most recently associated with the principal. It
   may be the name that the principal supplied when the credentials were
   created (in which case it may not have been verified yet) or it may
   be a different name that has been verified.

   As with Get_Node_Info and Get_Principal_UID, this routine is not
   likely to appear in an actual implementation, but will be bundled in
   some fashion with related procedures.  The name returned by this
   procedure is not guaranteed to have been cryptographically verified.
   Verify_Principal_Name performs that function.

3.10.7 Get Lifetime

   get_lifetime(
                                                    --inputs
                       Claimant_credentials  Credentials,
                                                    --outputs
                       lifetime              Duration)

   This routine computes the life remaining in a set of credentials.
   Its most common use would be to know to renew credentials before they
   expire.

   Returns the remaining lifetime of the login ticket in the
   credentials. This can either be the done on the node where the
   original login took place, or at a server which has been delegated
   to. It indicates how much longer these credentials can be used for
   further delegations. This routine will return 0 if the login ticket
   has passed the end of its life, if there is no login ticket, or if
   the credentials do not contain the private key certified by the
   ticket (i.e., where they were created by an authentication-without-
   delegation operation).
Top   ToC   RFC1507 - Page 73
3.10.8 Verify Node Name

   Verify_node_name(
                                                    --inputs
                       nodename              Name,
                       username              String,
                                                     --updated
                       verifying_credentials Credentials,
                       accepted_credentials  Credentials,
                                                    --outputs
                       Name matches          Boolean)

   This routine tests whether the originating node of an authentication
   token can be authenticated as having the provided name. Like a
   principal, a node may have multiple aliases. One of them may be
   returned by Get_node_info, but this call allows a suspected alias to
   be verified.  The verifying credentials supplied with this call must
   be the same credentials as were used in the Accept_token call. The
   procedure for completing this request is as follows:

    a) If there is no Node Ticket in the claimant credentials then
       return False.

    b) Search the incoming context cache of the verifying credentials
       for an entry containing the same encrypted shared key as the
       encrypted shared key subfield of the claimant information of
       the accepted credentials.  In the steps which follow,
       references to "the cache" refer to this entry.  If none is
       found, initialize such an entry as follows:

      1) Encrypted shared key from the encrypted shared key subfield
         of the claimant information of the accepted credentials.

      2) The shared key and validity interval are determined by
         decrypting the encrypted shared key using the RSA private
         key in the verifier information of the server credentials.
         If this procedure is called after a call to Accept_token
         using the same server credentials (as is required for
         correct use), the shared key and validity interval must
         correctly decrypt.  If called in some other context, the
         results are undefined.  The validity interval is not
         checked.

      3) Initialize all other entries in the cache to missing.

    c) If there is a "local username on client node" in the cache and
       it does not match the username supplied as a parameter, return
       False.
Top   ToC   RFC1507 - Page 74
    d) If there is a "name of client node" in the cache and it
       matches the nodename supplied as a parameter:

      1) Set the "Full name of the node" subfield of the remote node
         authentication field of the accepted credentials to be the
         nodename supplied as a parameter.

      2) Set the "Local Username on the node" subfield of the remote
         node authentication field of the accepted credentials to be
         the username supplied as a parameter.

      3) return True.

    e) Call the Get_Pub_Keys subroutine with the server_credentials,
       the nodename supplied as a parameter, and Try_Hard=False.

    f) If "Public Key of Client Node" is missing from the cache,
       check all of the Public keys returned to see if one verifies
       the node ticket.  If one does, set the "Public Key of Client
       Node" and "UID of Client Node" fields in the cache to be the
       PK/UID pair that verified the ticket and set the "Local
       Username on Client node" field to be the username supplied as
       a parameter..

    g) If any of the Public Key/UID pairs match the "Public Key of
       Client Node" and "UID of Client Node" fields in the cache,
       then:

      1) Set the "name of client node" in the cache equal to the
         nodename supplied as a parameter.

      2) Set the "Full name of the node" subfield of the remote node
         authentication field of the accepted credentials to be the
         nodename supplied as a parameter.

      3) Set the "Local Username on the node" subfield of the remote
         node authentication field of the accepted credentials to be
         the username supplied as a parameter.

      4) Return True.

    h) If none of them match, call Get_Pub_Keys again with
       Try_Hard=True and repeat steps 6 & 7.  If Step 7 fails a
       second time, return False.
Top   ToC   RFC1507 - Page 75
3.10.9 Verify Principal Name

   Verify_principal_name(
                                                    --inputs
                       principal_name        Name,
                                                     --updated
                       verifier_credentials  Credentials,
                       claimant_credentials  Credentials,
                                                    --outputs
                       Name matches          Boolean)

   This routine tests (in the context of the verifier credentials)
   whether the claimant credentials are authenticatable as being those
   of the named principal.  This procedure is called with a set of
   accepted credentials to authenticate their source, or with a set of
   credentials produced by network_login to authenticate the creator of
   those credentials.  If the claimant credentials were created by
   Accept_token, then the verifier credentials supplied in this call
   must be the same as those used in that call.  The procedure for
   completing this request is as follows:

    a) If there is no Login Ticket in the claimant credentials, then
       return False.

    b) If the current time is not within the validity interval of the
       Login Ticket, then return False.

    c) If there is an Encrypted Shared Key present in the Claimant
       information field of the claimant credentials, then find or
       create a matching cache entry in the Cached Incoming Contexts
       of the verifier credentials.  In the description which
       follows, references to "the cache" refer to this entry.  If
       the cache entry must be created, its contents is set to be as
       follows:

      1) Encrypted shared key from the encrypted shared key subfield
         of the claimant information of the accepted credentials.

      2) The shared key and validity interval are determined by
         decrypting the encrypted shared key using the RSA private
         key in the verifier information of the server credentials.
         If this procedure is called after a call to Accept_token
         using the same server credentials (as is required for
         correct use), the shared key and validity interval must
         correctly decrypt.  If called in some other context, the
         results are undefined.  The validity interval is not
         checked.
Top   ToC   RFC1507 - Page 76
      3) Initialize all other entries in the cache to missing.

    d) If there is a cache entry and if the "Public Key of Client
       Principal" field is present and if the "UID of Client
       Principal" field is present and matches the UID in the Login
       Ticket, then:

      1) Set the Public Key of the principal field in the Claimant
         information to be the Public Key of Client Principal.

      2) If the "Full name of the principal" field is missing from
         the claimant information of the claimant credentials, then
         set it to the "Name of Client Principal" field from the
         cache.

    e) If there is a cache entry and if the "Name of Client
       Principal" field is present and if it matches the principal
       name supplied to this routine and if the UID in the cache
       matches the UID in the Login Ticket, return True.

    f) Call the Get_Pub_Keys subroutine with the name and verifier
       credentials supplied to this routine and Try_Hard=FALSE.
       Ignore any keys retrieved where the corresponding UID does not
       match the UID in the claimant credentials.

    g) If the Public Key of the principal is missing from the
       claimant information of the claimant credentials, then attempt
       to verify the signature on the login ticket with each public
       key returned by Get_Pub_Keys.  If verification succeeds:

      1) Set the Public Key of the principal in the claimant
         information of the claimant credentials to be the Public Key
         that verified the ticket.

      2) If the Full name of the principal in the claimant
         information of the claimant credentials is missing, set it
         to the name supplied to this routine.

      3) If there is a cache entry, set the Name of Client Principal
         to be the name supplied to this routine, the UID of Client
         Principal to be the UID from the Login Ticket, and the
         Public Key of Client Principal to be the Public Key that
         verified the ticket.

      4) Return True.

    h) If the Public Key of the principal is present in the claimant
       information of the claimant credentials, then see if it
Top   ToC   RFC1507 - Page 77
       matches any of the public keys returned by Get_Pub_Keys.  If
       one of them matches:

      1) If the Full name of the principal in the claimant
         information of the claimant credentials is missing, set it
         to the name supplied to this routine.

      2) If there is a cache entry, set the Name of Client Principal
         to be the name supplied to this routine, the UID of Client
         Principal to be the UID from the Login Ticket, and the
         Public Key of Client Principal to be the Public Key that
         verified the ticket.

      3) Return True.

    i) If steps 7 & 8 fail, retry the call to Get_Pub_Keys with
       Try_Hard=TRUE, and retry steps 7 & 8.  If they fail again,
       return false.

3.10.10 Get Pub Keys

   Get_Pub_Keys(
                                                    --inputs
                       TA_credentials     Credentials
                       Try_Hard           Boolean,
                       Target Name        Name,
                                                    --outputs
                       Pub_keys           Set of Public key/UID pairs

   This common subroutine is used in the execution of Create_Token,
   Verify_Principal_Name, and Verify_Node_Name.  Given the name of a
   principal, it retrieves a set of public key/UID pairs which
   authenticate that principal (normally only one pair).  It does this
   by retrieving from the naming service a series of certificates,
   verifying the signatures on those certificates, and verifying that
   the sequence of certificates constitute a valid "treewalk".

   The credentials structure passed into this procedure represent a
   starting point for the treewalk.  Included in these credentials will
   be the public key, UID, and name of an authority that is trusted to
   authenticate all remote principals (directly or indirectly).

   The "Try_Hard" bit is a specification anomaly resulting from the fact
   that caches maintained by this routine are not transparent to the
   calling routines.  It tells this procedure to bypass caches when
   doing all name service lookups because the information in caches is
   believed to be stale.  In general, a routine will call Get_Pub_Keys
   with Try_Hard set false and try to use the keys returned.  If use of
Top   ToC   RFC1507 - Page 78
   those keys fails, the calling routine may call this routine again
   with Try_Hard set true in hopes of getting additional keys.
   Routinely calling this routine with Try_Hard set true is likely to
   have adverse performance implications but would not affect the
   correctness or the security of the operation.

   The name supplied is the full X.500 name of the principal for whom
   public keys are needed as part of some authentication process.

   This procedure securely learns the public keys and UIDs of foreign
   principals by constructing a valid chain of certificates between its
   trusted TA and the certificate naming the foreign principal.  In the
   simplest case, where the TA has signed a certificate for the foreign
   principal, the chain consists of a single certificate.  Otherwise,
   the chain must consist of a series of certificates where the first is
   signed by the TA, the last is a certificate for the foreign
   principal, and the subject of each principal in the chain is the
   issuer of the next.  What follows is first a definition of what
   constitutes a valid chain of certificates followed by a model
   algorithm which constructs all of (and only) the valid chains which
   exist between the TA and the target name.

   In order to limit the implications of the compromise of a single CA,
   and also to limit the complexity of the search of the certificate
   space, there are restrictions on what constitutes a valid chain of
   certificates from the TA to the Name provided.  The only CAs whose
   compromise should be able to compromise an authentication are those
   controlling directories that are ancestors of one of the two names
   and that are not above a common ancestor.  Therefore, only
   certificates signed by those CAs will be considered valid in a
   certificate chain.  Normally, the CA for a directory is expected to
   certify a public key and UID for the CA of each child directory and
   one parent directory.  A CA may also certify another CA for some
   remote part of the naming hierarchy, and such certificates are
   necessary if there are no CAs assigned to directories high in the
   naming hierarchy.

   A certificate chain is considered valid if it meets the following
   criteria:

    a) It must consist of zero or more  parent certificates, followed
       by zero or one   cross certificates, followed by zero or more
       child certificates.

    b) The number of parent certificates may not exceed the number of
       levels in the naming hierarchy between the TA name and the
       name of the least common ancestor in the naming hierarchy
       between the TA name and the target name.
Top   ToC   RFC1507 - Page 79
    c) Each  parent certificate must be stored in the naming service
       under the entry of its issuer.

    d) The subject of the cross certificate (if any) must be an
       ancestor of the target name but must be a longer name than the
       least common ancestor of the TA name and the target name.

    e) The cross certificate (if any) must have been stored in the
       naming service under the entry of its issuer or there must
       have been an indication in the naming service that
       certificates signed by this issuer may be stored with their
       subjects.

    f) The issuer of each parent certificate does not have stored
       with it in the naming service a cross certificate with the
       same issuer whose subject is an ancestor of the target name.

    g) Each child certificate must be stored in the naming service
       under the entry of its subject.

    h) The subject of each child certificate does not have associated
       with it in the naming service a cross certificate with the
       same subject whose issuer is the same as the issuer of any of
       the parent certificates or the cross certificate of the chain.

    i) The subject of each certificate must be the issuer of the
       certificate that follows in the chain.  The equality test can
       be met by either of two methods:

      1) The public key of the subject in the earlier certificate
         verifies the signature of the later and the subject UID in
         the earlier certificate is equal to the issuer UID in the
         later; or

      2) The public key of the subject in the earlier certificate
         verifies the signature of the later, the earlier lacks a
         subject UID and/or the later lacks an issuer UID and the
         name of the subject in the earlier certificate is equal to
         the name of the issuer in the later.

    j) The Public Key of the TA verifies the signature of the first
       certificate.

    k) The UID of the TA equals the UID of the issuer of the first
       certificate  or the UID is missing on one or both places and
       the name of the TA equals the name of the issuer of the first
       certificate.
Top   ToC   RFC1507 - Page 80
    l) All of the certificates are valid X.509 encodings and the
       current time is within all of their validity intervals.

   If a chain is valid, the name which it authenticates can be
   constructed as follows:

    a) If the chain contains a cross certificate, the name
       authenticated can be constructed by taking the subject name
       from the cross certificate and appending to it a relative name
       for each child certificate which follows.  The relative name
       is the extension by which the subject name in the child
       certificate extends the issuer name.

    b) If the chain does not contain a cross certificate, the name
       authenticated can be constructed by taking the TA name,
       truncating from it the last  n name components where  n is the
       number of  parent certificates in the chain, and appending to
       the result a relative name for each child certificate.  The
       relative name is the extension by which the subject name in
       the child certificate extends the issuer name.

   In the common case, the authenticated name will be the subject
   name in the last certificate.  The authenticated name is
   constructed by the rules above to deal with namespace
   reorganization.  If a branch of the namespace is renamed (due to,
   for example, a corporate acquisition or reorganization), only the
   certificates around the break point need to be regenerated.
   Certificates below the break will continue to contain the old
   names (until renewed), but the algorithms above assure the
   principals in that branch will be able to authenticate as their
   new names.  Further, if the certificates at the branch point are
   maintained for both the old and new names for an interim period,
   principals in the moved branch will be able to authenticate as
   either their old or new names for that interim period without
   having duplicate certificates.

   A final complication that the algorithm must deal with is the
   location of  cross certificates.  If a key is compromised or for
   some other reason it is important to revoke a certificate ahead
   of its expiration, it is removed from the naming service.  This
   algorithm will only use certificates that it has recently
   retrieved from the naming service, so revocation is as effective
   as the mechanisms that prevent impersonation of the naming
   service.   There are plans to eventually use DASS mechanisms to
   secure access to the naming service; until they are in place,
   name service impersonation is a theoretical threat to the
   security of revocation.  Opinions differ as to whether it is a
   practical threat.   Child certificates are always stored with the
Top   ToC   RFC1507 - Page 81
   subject and will not be found unless stored in the name server of
   the subject.    Parent  certificates are always stored with the
   issuer and will not be found unless stored in the name server of
   the issuer.  For best security, cross certificates should be
   stored with the issuer because the name server for the subject
   may not be adequately trustworthy to perform revocation.  There
   are performance and availability penalties, however, in doing so.
   The architecture and the algorithm therefore support storing
   cross certificates with either the issuer or the subject.  There
   must be some sort of flag in the name service associated with the
   issuer saying whether cross certificates from that issuer are
   permitted to be stored in the subject's name service entry, and
   if that flag is set such certificates will be found and used.

   In order to make revocation effective, DASS must assure that
   naming service caches do not become arbitrarily stale (the
   allowed age of a cache entry is included in the sum of times with
   together make up the revocation time).  If DASS uses a naming
   service such as DNS that does not time out cache entries, it must
   bypass cache on all calls and (to achieve reasonable performance)
   maintain its own naming service cache.  It may be advantageous to
   maintain a cache in any case so the that the fact that the
   certificates have been verified can be cached as well as the fact
   that they are current.

3.10.10.1 Basic Algorithm

   For ease of exposition, this first description will ignore the
   operation of any caches.  Permissible modifications to take
   advantage of caches and enhance performance will be covered in
   the next section.  This path will be followed if the Try_Hard bit
   is set True on the call.

   Rather than trying construct all possible chains between the TA
   and the name to be authenticated (in the event of multiple
   certificates per principal, there could be exponentially many
   valid chains), this algorithm computes a set of PK/UID/Name
   triples that are valid for each principal on the path between the
   TA and the name to be authenticated.  By doing so, it minimizes
   the processing of redundant information.

    a) Determining path and initialization

       Several state variables are manipulated during the tree walk.
       These are called:
Top   ToC   RFC1507 - Page 82
      1) Current-directory-name
         This is the name indicating the current place in the tree
         walk.  Initially, this is the name of the TA.

      2) Least-Common-Ancestor-Name
         This is the portion of the names which is common to both the
         CA and the Target.  This is computed at initialization and
         does not change during the treewalk.

      3) Trusted-Key-Set
         For each name which is an ancestor of either the TA or the
         Target but not of the Least-Common-Ancestor, a list of
         PK/UID/Name triples.  This is initialized to a single triple
         from the TA information in the supplied credentials.

      4) Search-when-descending
         This is a list of PK/UID/Name triples of issuers that will
         be trusted when descending the tree.  This set is initially
         empty.

      5) Saved-RDNs
         This is a sequence of Relative Distinguished Names (RDNs)
         stripped off the right of the target name to form
         Least-common-ancestor-name.  This "stack" is initially empty
         and is populated during Step 3.

    b) Ascending the "TA side" of the tree

       While Current-directory-name is not identical to
       Common-point-Name the algorithm moves up the tree. At each
       step it does the following operations.

      1) Find all cross certificates stored in the naming service
         under Current-directory-name in which the subject is an
         ancestor of the principal to be authenticated or an
         indication that cross certificates from this issuer are
         stored in the subject entry.  If there is an indication that
         such certificates are stored in the subject entry, copy all
         triples in Trusted-Key-Set for Current-directory-name into
         the "Search-when-descending" list.  If any such certificates
         are found, filter them to include only those which meet the
         following criteria:

        (i)  For some triple in the Trusted-Key-Set corresponding to
             the Current-directory-name, the public key in the triple
             verifies the signature on the certificate  and either the
             UID in the triple matches the issuer UID in the
             certificate  or the UID in the triple and/or the
Top   ToC   RFC1507 - Page 83
             certificate is missing and the name in the triple matches
             the issuer name in the certificate.

        (ii) No certificates were found signed by this issuer in which
             the subject name is longer than the subject name in this
             certificate (i.e., if there are cross certificates to two
             different ancestors, accept only those which lead to the
             closest ancestor).

        (iii)The current time is within the validity interval of the
             certificate.

      2) If any cross certificates were found (whether or not they
         were all eliminated as part of the filtering process), set
         Current-directory-name to the longest name that was found in
         any certificate and construct a set of PK/UID/Name triples
         for that name from the certificates which pass the filter
         and place them in the Trusted Key Set associated with their
         subject.  Exit the ascending tree loop at this point and
         proceed directly to step 3.  Note that this means that if
         there are cross certificates to an ancestor of the target
         but they are all rejected (for example if they have
         expired), the treewalk will   not construct a chain through
         the least common ancestor and will ultimately fail unless a
         crosslink from a lower ancestor is found stored with its
         subject.  This is a security feature.

      3) If no cross certificates are found, find all the parent
         directory certificates for the directory whose name is in
         the Current-directory-name.  Filter these to find only those
         which meet the following criteria:

        (i)  The current time is within the validity interval.

        (ii) For some triple corresponding to the
             Current-directory-name, the public key in the triple
             verifies the signature on the certificate  and either  the
             UID in the triple matches the issuer UID in the
             certificate  or the UID in the triple and/or the
             certificate is missing and the name in the triple matches
             the issuer name in the certificate.

      4) Construct PK/UID/Name triples from the remaining
         certificates for the directory whose name is constructed by
         stripping the rightmost simple name from the
         Current-directory-name and place them in the Trusted-Key-Set.
Top   ToC   RFC1507 - Page 84
      5) Strip the rightmost simple name of the
         Current-directory-name.

      6) Repeat from step (a) (testing to see if
         current-directory-name is the same as Common-point-Name).

    c) Searching the "target side" of the tree for a crosslink:

      1) Initialization: set Current-directory-name to the name
         supplied as input to this procedure.

      2) Retrieve from the naming service all cross certificates
         associated with Current-directory-name.  Filter to only
         those that meet the following criteria:

        (i)  The current time is within their validity interval.

        (ii) The subject name is equal to Current-directory-name.

        (iii)For some PK/UID/Name triple in the
             "Search-when-descending" list compiled while ascending
             the tree, the Public Key verifies the signature on the
             certificate and  either the UID matches the issuer UID in
             the certificate   or a UID is missing from the triple
             and/or the certificate and the Name in the triple matches
             the issuer name in the certificate.

        (iv) There are no certificates found meeting criteria (ii) and
             (iii) matching a PK/UID/Name triple in the
             Search-when-descending list whose subject is a directory
             lower in the naming hierarchy.

      3) If any qualifying certificates are found, construct
         PK/UID/Name triples for each of them; these should replace
         rather than supplement any triples already in the
         Trusted-key-set for that directory.

      4) If after steps (b) and (c), there are no PK/UID/Name triples
         corresponding to Current-directory-name in Trusted-Key-Set,
         shorten Current-directory-name by one RDN (pushing it onto
         the Saved-RDNs stack) and repeat this process until
         Current-directory-name is equal to
         Least-common-ancestor-name  or there is at least one triple
         in Trusted-key-set corresponding to Current-directory-name.

    d) Descending the tree

       While the list Saved-RDNs is not Empty the algorithm moves
Top   ToC   RFC1507 - Page 85
       down the tree. At each step it does the following operations.

      1) Remove the first RDN from Saved-RDNs and append it to the
         Current-directory-name.

      2) Find all the child directory certificates for the directory
         whose name is in the current-directory-name.

      3) Filter these certificates to find only those which meet the
         following criteria:

        (i)  The current time is within the validity interval.

        (ii) For some PK/UID/Name triple in the Current-key-set for
             the parent directory, the Public Key verifies the
             signature on the certificate and either the UID matches
             the issuer UID of the certificate   or the UID is missing
             from the triple and/or the certificate and the Name in
             the triple matches the issuer name in the certificate.

        (iii)The issuer name in the certificate is a prefix of the
             subject name and the difference between the two names is
             the final RDN of Current-directory-name.

      4) Take the key, UID, and name from each remaining certificate
         and form a new triple corresponding to
         Current-directory-name in Trusted-Key-Set. If this set is
         empty then the algorithm exits with the
         'Incomplete-chain-of-trustworthy-CAs' error condition.

      5) repeat from step (a), appending a new simple name to
         Current-directory-name.

    e) Find public keys:
       If there are no triples in the Trusted-Key-Set for the named
       principal, then the algorithm exits with the `Target-has-no-keys-w
       error condition. Otherwise, the Public Key and UID are
       extracted from each pair, duplicates are eliminated, and this
       set is returned as the Pub_keys.

3.10.10.2 Allowed Variations - Caching

   Some use of caches can be implemented without affecting the semantics
   of the Get_Pub_Keys routine.  For example, a crypto-cache could
   remember the public key that verified a signature in the past and
   could avoid the verification operation if the same key was used to
   verify the same data structure again.  In some cases, however, it is
   impossible (or at least inconvenient) for a cache implementation to
Top   ToC   RFC1507 - Page 86
   be completely transparent.

   In particular, for good performance it is important that certificates
   not be re-retrieved from the naming service on every authentication.
   This must be balanced against the need to have changes to the
   contents of the naming service be reflected in DASS calls on a timely
   basis.  There are two cases of interest: changes which cause an
   authentication which previously would have succeeded to fail and
   changes which cause an authentication which previously would have
   failed to succeed.  These two cases are subject to different time
   constraints.

   In general, changes that cause authentication to succeed must be
   reflected quite quickly - on the order of minutes.  If a user
   attempts an operation, it fails, the user tracks down a system
   manager and causes the appropriate updates to take place, and the
   user retries the operation, it is unacceptable for the operation to
   continue to fail for an extended period because of stale caches.

   Changes that cause authentication to fail must be reflected reliably
   within a bounded period of time for security reasons.  If a user
   leaves the company, it must be possible to revoke his ability to
   authenticate within a relatively short period of time - say hours.

   These constraints mean that a naming service cache which contains
   arbitrarily old information is unacceptable.  To meet the second
   constraint, naming service cache entries must be timed out within a
   reasonable period of time unless in implementation verifies that the
   certificate is still present (a crypto-cache which lasted longer
   would be legal; rather than deleting a name service cache entry, in
   implementation might instead verify that the entry was still present
   in the naming service.  This would avoid repeating the cryptographic
   "verify").

   In order to assure that information cached for even a few hours not
   deny authentication for that extended period, it must be possible to
   bypass caches when the result would otherwise be a failure.  Since
   the performance of authentication failures is not a serious concern,
   it is acceptable to expect that before an operation fails a retry
   will be made to the naming service to see if there are any new
   relevant certificates (or in certain obscure conditions, to see if
   any relevant certificates have been deleted).

   If on a call to Get_Pub_Keys, the Try_Hard bit is True, then this
   procedure must return results based on the contents of the naming
   service no more than five minutes previous (this would normally be
   accomplished by ignoring name service caches and making all
   operations directly to the naming service).  If the Try_Hard bit is
Top   ToC   RFC1507 - Page 87
   False, this procedure may return results based on the contents of the
   naming service any time in the previous few hours, in the sense that
   it may ignore any certificate added in the previous few hours and may
   use any certificate deleted in the previous few hours.  Procedures
   which call this routine with Try_Hard set to false must be prepared
   to call it again with Try_Hard True if their operation fails possibly
   from this result.

   The exact timer values for "five minutes" and "a few hours" are
   expected to be implementation constants.

   In the envisioned implementation, the entire "ascending treewalk" is
   retrieved, verified, and its digested contents cached when a
   principal first establishes credentials.  A mechanism should be
   provided to refresh this information periodically for principals
   whose sessions might be long lived, but it would probably be
   acceptable in the unlikely event of a user's ancestor's keys changing
   to require that the user log out and log back in.  This is consistent
   with the observed behavior of existing security mechanisms.

   The descending treewalk, on the other hand, is expected to be
   maintained as a more conventional cache, where entries are kept in a
   fixed amount of memory with a "least recently used" replacement
   policy and a watchdog timer that assures that stale information is
   not kept indefinitely.  A call to Get_Pub_Keys with Try_Hard set
   false would first check that cache for relevant certificates and only
   if none were found there would it go out to the naming service.  If
   there were newer certificates in the naming service, they might not
   be found and an authentication might therefore fail.

   When Try_Hard is false, an implementation may assume that
   certificates not in the cache do not exist so long as that assumption
   does not cause an authentication to falsely succeed.  In that case,
   it may only make that assumption if the certificates have been
   verified to not exist within the revocation time (a few hours).

3.11 DASSlessness Determination Functions

   In order to provide better interoperability with alternative
   authentication mechanisms and to provide backward compatibility with
   older (insecure) authentication mechanisms, it is sometimes important
   to be able to determine in a secure way what the appropriate
   authentication mechanism is for a particular named principal.  For
   some applications, this will be done by a local mechanism, where
   either the person creating access control information must know and
   specify the mechanism for each principal or a system administrator on
   the node must maintain a database mapping names to mechanisms.  Three
   applications come to mind where scaleability makes such mechanisms
Top   ToC   RFC1507 - Page 88
   implausible:

    a) To transparently secure proxy-based applications (like rlogin)
       in an environment where some hosts have been upgraded to
       support DASS and some have not, a node must be willing to
       accept connections authenticated only by their network
       addresses but only if they can be assured that such nodes do
       not have DASS installed.  Access to a resource becomes secure
       without administrative action when all nodes authorized to
       access it have been upgraded.

       In this scenario, the server node must be able to determine
       whether the client node is DASSless in a secure fashion.

    b) Similarly, in a mixed environment where some servers are
       running DASS and some are not, it may be desirable for clients
       to authenticate servers if they can but it would be
       unacceptable for a client to stop being able to access a
       DASSless server once DASS is installed on the client.  In such
       a situation where server authentication is desirable but not
       essential, the client would like to determine in a secure
       fashion whether the server can accept DASS authentication.

    c) In a DASS/Kerberos interoperability scenario, a server may
       decide that Kerberos authentication is "good enough" for
       principals that do not have DASS credentials without
       introducing trust in on-line authorities when DASS credentials
       are available.  In parallel with case 1, we want it to be true
       that when the last principal with authority to access an
       object is upgraded to DASS, we automatically cease to trust
       PasswdEtc servers without administrative action on the part of
       the object owner.  For this purpose, the authenticator must
       learn in a secure fashion that the principal is incapable of
       DASS authentication.

   Reliably determining DASSlessness is optional for implementations of
   DASS and for applications.  No other capabilities of DASS rely on
   this one.

   The interface to the DASSlessness inquiry function is specified as a
   call independent of all others.  This capability must be exposed to
   the calling application so that a server that receives a request and
   no token can ask whether the named principal should be believed
   without a token.  It might improve performance and usability if in
   real interfaces DASSlessness were returned in addition to a bad
   status on the function that creates a token if the token is targeted
   toward a server incapable or processing it.  An application could
   then decide whether to make the request without a token (and give up
Top   ToC   RFC1507 - Page 89
   server authentication) or to abort the request.

3.11.1 Query DASSlessness

   Query_DASSlessness(
                                                      --inputs
                       verifying_credentials Credentials,
                       principal_name        Name,
                                                      --outputs
                       alternate_authentication Set of OIDs)

   This function uses the verifying credentials to search for an
   alternative authentication mechanism certificate for the named
   principal or for any CA on the path between the verifying credentials
   and the named principal.  Such a certificate is identical to an DASS
   X.509 certificate except that it lists a different algorithm
   identifier for the public key of the subject than that expected by
   DASS.

   This function is implemented identically to Get_Pub_Keys except:

    a) If in any set of certificates found, no valid DASS certificate
       is found and one or more certificates are found that would
       otherwise be valid except for an invalid subject public key
       OID, the OID from that certificate or certificates is returned
       and the algorithm terminates.

    b) On initial execution, Try_Hard=False.  If the first execution
       fails to retrieve any valid PK/UID pairs but also fails to
       find any invalid OID certificates, repeat the execution with
       Try_Hard=True.

    c) If the either execution finds PK/UID pairs or if neither finds
       and invalid OID certificates, fail by returning a null set.



(page 89 continued on part 4)

Next Section