Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 1507

DASS - Distributed Authentication Security Service

Pages: 119
Part 1 of 4 – Pages 1 to 25
None   None   Next

Top   ToC   RFC1507 - Page 1
Network Working Group                                         C. Kaufman
Request for Comments: 1507                 Digital Equipment Corporation
                                                          September 1993

              Distributed Authentication Security Service

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard.  Discussion and
   suggestions for improvement are requested.  Please refer to the
   current edition of the "Internet Official Protocol Standards" for the
   standardization state and status of this protocol.  Distribution of
   this memo is unlimited.

Table of Contents

    1.   Introduction ................................................ 2
         1.1  What is DASS? .......................................... 2
         1.2  Central Concepts ....................................... 4
         1.3  What This Document Won't Tell You ..................... 11
         1.4  The Relationship between DASS and ISO Standards ....... 17
         1.5  An Authentication Walkthrough ......................... 20
    2.   Services Used .............................................. 25
         2.1  Time Service .......................................... 25
         2.2  Random Numbers ........................................ 26
         2.3  Naming Service ........................................ 26
    3.   Services Provided .......................................... 37
         3.1  Certificate Contents .................................. 38
         3.2  Encrypted Private Key Structure ....................... 40
         3.3  Authentication Tokens ................................. 40
         3.4  Credentials ........................................... 43
         3.5  CA State .............................................. 47
         3.6  Data types used in the routines ....................... 47
         3.7  Error conditions ...................................... 49
         3.8  Certificate Maintenance Functions ..................... 49
         3.9  Credential Maintenance Functions ...................... 55
         3.10 Authentication Procedures ............................. 63
         3.11 DASSlessness Determination Functions .................. 87
    4.   Certificate and message formats ............................ 89
         4.1  ASN.1 encodings ....................................... 89
         4.2  Encoding Rules ........................................ 96
         4.3  Version numbers and forward compatibility ............. 96
         4.4  Cryptographic Encodings ............................... 97
    Annex A - Typical Usage ........................................ 101
         A.1  Creating a CA ........................................ 101
Top   ToC   RFC1507 - Page 2
         A.2  Creating a User Principal ............................ 102
         A.3  Creating a Server Principal .......................... 103
         A.4  Booting a Server Principal ........................... 103
         A.5  A user logs on to the network ........................ 103
         A.6  An Rlogin (TCP/IP) connection is made ................ 104
         A.7  A Transport-Independent Connection ................... 104
    Annex B - Support of the GSSAPI ................................ 104
         B.1  Summary of GSSAPI .................................... 105
         B.2  Implementation of GSSAPI over DASS ................... 106
         B.3  Syntax ............................................... 110
    Annex C - Imported ASN.1 definitions ........................... 112
    Glossary ....................................................... 114
   Security Considerations ......................................... 119
   Author's Address ................................................ 119

    Figure 1 - Authentication Exchange Overview ....................  24

1. Introduction

1.1 What is DASS?

   Authentication is a security service. The goal of authentication is
   to reliably learn the name of the originator of a message or request.
   The classic way by which people authenticate to computers (and by
   which computers authenticate to one another) is by supplying a
   password.  There are a number of problems with existing password
   based schemes which DASS attempts to solve.  The goal of DASS is to
   provide authentication services in a distributed environment which
   are both more secure (more difficult for a bad guy to impersonate a
   good guy) and easier to use than existing mechanisms.

   In a distributed environment, authentication is particularly
   challenging.  Users do not simply log on to one machine and use
   resources there.  Users start processes on one machine which may
   request services on another.  In some cases, the second system must
   request services from a third system on behalf of the user.  Further,
   given current network technology, it is fairly easy to eavesdrop on
   conversations between computers and pick up any passwords that might
   be going by.

   DASS uses cryptographic mechanisms to provide "strong, mutual"
   authentication.  Mutual authentication means that the two parties
   communicating each reliably learn the name of the other.  Strong
   authentication means that in the exchange neither obtains any
   information that it could use to impersonate the other to a third
   party.  This can't be done with passwords alone.  Mutual
   authentication can be done with passwords by having a "sign" and a
   "counter-sign" which the two parties must utter to assure one another
Top   ToC   RFC1507 - Page 3
   of their identities.  But whichever party speaks first reveals
   information which can be used by the second (unauthenticated) party
   to impersonate it.  Longer sequences (often seen in spy movies)
   cannot solve the problem in general.  Further, anyone who can
   eavesdrop on the conversation can impersonate either party in a
   subsequent conversation (unless passwords are only good once).
   Cryptography provides a means whereby one can prove knowledge of a
   secret without revealing it.  People cannot execute cryptographic
   algorithms in their heads, and thus cannot strongly authenticate to
   computers directly.  DASS lays the groundwork for "smart cards":
   microcomputers sealed in credit cards which when activated by a PIN
   will strongly authenticate to a computer.  Until smart cards are
   available, the first link from a user to a DASS node remains
   vulnerable to eavesdropping.  DASS mechanisms are constructed so that
   after the initial authentication, smart card or password based
   authentication looks the same.

   Today, systems are constructed to think of user identities in terms
   of accounts on individual computers.  If I have accounts on ten
   machines, there is no way a priori to see that those ten accounts all
   belong to the same individual.  If I want to be able to access a
   resource through any of the ten machines, I must tell the resource
   about all ten accounts.  I must also tell the resource when I get an
   eleventh account.

   DASS supports the concept of global identity and network login.  A
   user is assigned a name from a global namespace and that name will be
   recognized by any node in the network.  (In some cases, a resource
   may be configured as accessible only by a particular user acting
   through a particular node.  That is an access control decision, and
   it is supported by DASS, but the user is still known by his global
   identity).  From a practical point of view, this means that a user
   can have a single password (or smart card) which can be used on all
   systems which allow him access and access control mechanisms can
   conveniently give access to a user through any computer the user
   happens to be logged into.  Because a single user secret is good on
   all systems, it should never be necessary for a user to enter a
   password other than at initial login.  Because cryptographic
   mechanisms are used, the password should never appear on the network
   beyond the initial login node.

   DASS was designed as a component of the Distributed System Security
   Architecture (DSSA) (see "The Digital Distributed System Security
   Architecture" by M. Gasser, A. Goldstein, C. Kaufman, and B. Lampson,
   1989 National Computer Security Conference).  It is a goal of DSSA
   that access control on all systems be based on users' global names
   and the concept of "accounts" on computers eventually be replaced
   with unnamed rights to execute processes on those computers.  Until
Top   ToC   RFC1507 - Page 4
   this happens, computers will continue to support the concept of
   "local accounts" and access controls on resources on those systems
   will still be based on those accounts.  There is today within the
   Berkeley rtools running over the Internet Protocol suite the concept
   of a ".rhosts database" which gives access to local accounts from
   remote accounts.  We envision that those databases will be extended
   to support granting access to local accounts based on DASS global
   names as a bridge between the past and the future.  DASS should
   greatly simplify the administration of those databases for the
   (presumably common) case where a user should be granted access to an
   account ignoring his choice of intermediate systems.

1.2 Central Concepts

1.2.1 Strong Authentication with Public Keys

   DASS makes heavy use of the RSA Public Key cryptosystem.  The
   important properties of the RSA algorithms for purposes of this
   discussion are:

    - It supports the creation of a public/private key pair, where
      operations with one key of the pair reverse the operations of
      the other, but it is computationally infeasible to derive the
      private key from the public key.

    - It supports the "signing" of a message with the private key,
      after which anyone knowing the public key can "verify" the
      signature and know that it was constructed with knowledge of
      the private key and that the message was not subsequently

    - It supports the "enciphering" of a message by anyone knowing
      the public key such that only someone with knowledge of the
      private key can recover the message.

   With access to the RSA algorithms, it is easy to see how one could
   construct a "strong" authentication mechanism.  Each "principal"
   (user or computer) would construct a public/private key pair, publish
   the public key, and keep secret the private key.  To authenticate to
   you, I would write a message, sign it with my private key, and send
   it to you.  You would verify the message using my public key and know
   the message came from me.  If mutual authentication were desired, you
   could create an acknowledgment and sign it with your private key; I
   could verify it with your public key and I would know you received my

   The authentication algorithms used by DASS are considerably more
   complex than those described in the paragraph above in order to deal
Top   ToC   RFC1507 - Page 5
   with a large number of practical concerns including subtle security
   threats.  Some of these are discussed below.

1.2.2 Timestamps vs. Challenge/Response

   Cryptosystems give you the ability to sign messages so that the
   receiver has assurance that the signer of the message knew some
   cryptographic secret.  Free-standing public key based authentication
   is sufficiently expensive that it is unlikely that anyone would want
   to sign every message of an interactive communication, and even if
   they did they would still face the threat of someone rearranging the
   messages or playing them multiple times.  Authentication generally
   takes place in the context of establishing some sort of "connection,"
   where a conversation will ensue under the auspices of the single
   peer-entity authentication.  This connection might be
   cryptographically protected against modification or reordering of the
   messages, but any such protection would be largely independent of the
   authentication which occurred at the start of the connection.  DASS
   provides as a side effect of authentication the provision of a shared
   key which may be used for this purpose.

   If in our simple minded authentication above, I signed the message
   "It's really me!" with my private key and sent it to you, you could
   verify the signature and know the message came from me and give the
   connection in which this message arrived access to my resources.
   Anyone watching this message over the network, however, could replay
   it to any server (just like a password!) and impersonate me.  It is
   important that the message I send you only be accepted by you and
   only once.  I can prevent the message from being useful at any other
   server by including your name in the message.  You will only accept
   the message if you see your name in it.  Keeping you from accepting
   the message twice is harder.

   There are two "standard" ways of providing this replay protection.
   One is called challenge/response and the other is called timestamp-
   based.  In a challenge response type scheme, I tell you I want to
   authenticate, you generate a "challenge" (generally a number), and I
   include the challenge in the message I sign.  You will only accept a
   message if it contains the recently generated challenge and you will
   make sure you never issue the same challenge to me twice (either by
   using a sequence number, a timestamp, or a random number big enough
   that the probability of a duplicate is negligible).  In the
   timestamp-based scheme, I include the current time in my message.
   You have a rule that you will not accept messages more than - say -
   five minutes old and you keep track of all messages you've seen in
   the last five minutes.  If someone replays the message within five
   minutes, you will reject it because you will remember you've seen it
   before; if someone replays it after five minutes, you will reject it
Top   ToC   RFC1507 - Page 6
   as timed out.

   The disadvantage of the challenge/response based scheme is that it
   requires extra messages.  While one-way authentication could
   otherwise be done with a single message and mutual authentication
   with one message in each direction, the challenge/response scheme
   always requires at least three messages.

   The disadvantage of the timestamp-based scheme is that it requires
   secure synchronized time.  If our clocks drift apart by more than
   five minutes, you will reject all of my attempts to authenticate.  If
   a network time service spoofer can convince you to turn back your
   clock and then subsequently replays an expired message, you will
   accept it again.  The multicast nature of existing distributed time
   services and the likelihood of detection make this an unlikely
   threat, but it must be considered in any analysis of the security of
   the scheme.  The timestamp scheme also requires the server to keep
   state about all messages seen in the clock skew interval.  To be
   secure, this must be kept on stable storage (unless rebooting takes
   longer than the permitted clock skew interval).

   DASS uses the timestamp-based scheme.  The primary motivations behind
   this decision were so that authentication messages could be
   "piggybacked" on existing connection establishment messages and so
   that DASS would fit within the same "form factor" (number and
   direction of messages) as Kerberos.

1.2.3 Delegation

   In a distributed environment, authentication alone is not enough.
   When I log onto a computer, not only do I want to prove my identity
   to that computer, I want to use that computer to access network
   resources (e.g., file systems, database systems) on my behalf.  My
   files should (normally) be protected so that I can access them
   through any node I log in through.  DASS allows them to be so
   protected without allowing all of the systems that I might ever use
   to access those files in my absence.  In the process of logging in,
   my password gives my login node access to my RSA secret.  It can use
   that secret to "impersonate" me on any requests it makes on my
   behalf.  It should forget all secrets associated with me when I log
   off.  This limits the trust placed in computer systems.  If someone
   takes control of a computer, they can impersonate all people who use
   that computer after it is taken over but no others.

   Normally when I access a network service, I want to strongly
   authenticate to it.  That is, I want to prove my identity to that
   service, but I don't want to allow that service to learn anything
   that would allow it to impersonate me.  This allows me to use a
Top   ToC   RFC1507 - Page 7
   service without trusting it for more than the service it is
   delivering.  When using some services, for example remote login
   services, I may want that service to act on my behalf in calling
   additional services.  DASS provides a mechanism whereby I can pass
   secrets to such services that allow them to impersonate me.

   Future versions of this architecture may allow "limited delegation"
   so that a user may delegate to a server only those rights the server
   needs to carry out the user's wishes.  This version  can limit
   delegation only in terms of time.  The information a user gives a
   server (other than the initial login node) can be used to impersonate
   the user but only for a limited period of time.  Smart cards will
   permit that time limitation to apply to the initial login node as

1.2.4 Certification Authorities

   A flaw in the strong authentication mechanism described above is that
   it assumes that every "principal" (user and node) knows the public
   key of every other principal it wants to authenticate.  If I can fool
   a server into thinking my public key is actually your public key, I
   can impersonate you by signing a message, saying it is from you, and
   having the server verify the message with what it thinks is your
   public key.

   To avoid the need to securely install the public key of every
   principal in the database of every other principal, the concept of a
   "Certification Authority" was invented.  A certification authority is
   a principal trusted to act as an introduction service.  Each
   principal goes to the certification authority, presents its public
   key, and proves it has a particular name (the exact mechanisms for
   this vary with the type of principal and the level of security to be
   provided).  The CA then creates a "certificate" which is a message
   containing the name and public key of the principal, an expiration
   date, and bookkeeping information signed by the CA's private key.
   All "subscribers" to a particular CA can then be authenticated to one
   another by presenting their certificates and proving knowledge of the
   corresponding secret.  CAs need only act when new principals are
   being named and new private keys created, so that can be maintained
   under tight physical security.

   The two problems with the scheme as described so far are "revocation"
   and "scaleability". Certificate Revocation

   Revocation is the process of announcing that a key has (or may have)
   fallen into the wrong hands and should no longer be accepted as proof
Top   ToC   RFC1507 - Page 8
   of some particular identity.  With certificates as described above,
   someone who learns your secret and your certificate can impersonate
   you indefinitely - even after you have learned of the compromise.  It
   lacks the ability corresponding to changing your password.  DASS
   supports two independent mechanisms for revoking certificates. In the
   future, a third may be added.

   One method for revocation is using timeouts and renewals of
   certificates.  Part of the signed message which is a certificate may
   be a time after which the certificate should not be believed.
   Periodically, the CA would renew certificates by signing one with a
   later timeout.  If a key were compromised, a new key would be
   generated and a new certificate signed.  The old certificate would
   only be valid until its timeout.  Timeouts are not perfect revocation
   mechanisms because they provide only slow revocation (timeouts are
   typically measured in months for the load on the CA and communication
   with users to be kept manageable) and they depend on servers having
   an accurate source of the current time.  Someone who can trick a
   server into turning back its clock can use expired certificates.

   The second method is by listing all non-revoked certificates in the
   naming service and believing only certificates found there.  The
   advantage of this method is that it is almost immediate (the only
   delay is for name service "skulking" and caching delays).  The
   disadvantages are: (1) the availability of authentication is only as
   good as the availability of the naming service and (2) the security
   of revocation is only as good as the security of the naming service.

   A third method for revocation - not currently supported by DASS - is
   for certification authorities to periodically issue "revocation
   lists" which list certificates which should no longer be accepted. Certification Authority Hierarchy

   While using a certification authority as an introduction service
   scales much better than having every principal learn the public key
   of every other principal by some out of band means, it has the
   problem that it creates a central point of trust.  The certification
   authority can impersonate any principal by inventing a new key and
   creating a certificate stating that the new key represents the
   principal.  In a large organization, there may be no individual who
   is sufficiently trusted to operate the CA.  Even if there were, in a
   large organization it would be impractical to have every individual
   authenticate to that single person.  Replicating the CA solves the
   availability problem but makes the trust problem worse.  When
   authentication is to be used in a global context - between companies
   - the concept of a single CA is untenable.
Top   ToC   RFC1507 - Page 9
   DASS addresses this problem by creating a hierarchy of CAs.  The CA
   hierarchy is tied to the naming hierarchy.  For each directory in the
   namespace, there is a single CA responsible for certifying the public
   keys of its members.  That CA will also certify the public keys of
   the CAs of all child directories and of the CA of the parent
   directory.  With this cross-certification, it is possible knowing the
   public key of any CA to verify the public keys of a series of
   intermediate CAs and finally to verify the public key of any

   Because the CA hierarchy is tied to the naming hierarchy, the trust
   placed in any individual CA is limited.  If a CA is compromised, it
   can impersonate any of the principals listed in its directory, but it
   cannot impersonate arbitrary principals.

   DASS provides mechanisms for every principal to know the public key
   of its "parent" CA - the CA controlling the directory in which it is
   named.  The result is the following rules for the implications of a
   compromised CA:

    a) A CA can impersonate any principal named in its directory.

    b) A CA can impersonate any principal to a server named in its

    c) A CA can impersonate any principal named in a subdirectory to
       any server not named in the same subdirectory.

    d) A CA can impersonate to any server in a subdirectory any
       principal not named in the same subdirectory.

   The implication is that a compromise low in the naming tree will
   compromise all principals below that directory while a compromise
   high in the naming tree will compromise only the authentication of
   principals far apart in the naming hierarchy.  In particular, when
   multiple organizations share a namespace (as they do in the case of
   X.500), the compromise of a CA in one organization can not result in
   false authentication within another organization.

   DASS uses the X.500 directory hierarchy for principal naming.  At the
   top of the hierarchy are names of countries.  National authorities
   are not expected to establish certification authorities (at least
   initially), so an alternative mechanism must be used to authenticate
   entities "distant" in the naming hierarchy.  The mechanism for this
   in DASS is the "cross-certificate" where a CA certifies the public
   key for some CA or principal not its parent or child.  By limiting
   the chains of certificates they will use to parent certificates
   followed by a single "cross certificate" followed by child
Top   ToC   RFC1507 - Page 10
   certificates, a DASS implementation can avoid the need to have CAs
   near the root of the tree or can avoid the requirement to trust them
   even if they do exist.  A special case can also be supported whereby
   a global authority whose name is not the root can certify the local
   roots of independent "islands".

1.2.5 User vs. Node Authentication

   In concept, DASS mechanisms support the mutual authentication of two
   principals regardless of whether those principals are people,
   computers, or applications.  Those mechanisms have been extended,
   however, to deal with a common case of a pair of principals acting
   together (a user and a node) authenticating to a single principal (a
   remote server).  This is done by having optionally in each
   credentials structure two sets of secrets - one for the user and one
   for the node.  When authentication is done using such credentials,
   both secrets sign the request so the receiving party can verify that
   both principals are present.

   This setup has a number of advantages.  It permits access controls to
   be enforced based on both the identity of the user and the identity
   of the originating node.  It also makes it possible to define users
   of systems who have no network wide identities who can access network
   resources on the basis of node credentials alone.  The security of
   such a setup is less because a node can impersonate all of its users
   even when they are not logged in, but it offers an easier transition
   from existing global identities for all users.

1.2.6 Protection of User Keys

   DASS mechanisms generally deal with authentication between principals
   each knowing a private key.  For principals who are people, special
   mechanisms are provided for maintaining that private key.  In
   particular, it many cases it will be most convenient to keep
   passwords as secrets rather than private keys.  This architecture
   specifies a means of storing private keys encrypted under passwords.
   This would provide security as good as hiding a private key were it
   not that people tend to choose passwords from a small space (like
   words in a dictionary) such that a password can be more easily
   guessed than a private key.  To address this potential weakness, DASS
   specifies a protocol between a login node and a login agent whereby
   the login agent can audit and limit the rate of password guesses.
   Use of these features is optional.  A user with a smart card could
   store a private key directly and bypass all of these mechanisms.  If
   users can be forced to choose "good" passwords, the login agent could
   be eliminated and encrypted credentials could be stored directly in
   the naming service.
Top   ToC   RFC1507 - Page 11
   Another way in which user keys are protected is that the architecture
   does not require that they be available except briefly at login.
   This reduces the threat of a user walking away from a logged on
   workstation and having someone take over the workstation and extract
   his key.  It also makes the use of RSA based smart cards practical;
   the card could keep the user's private key and execute one signature
   operation at login time to authenticate an entire session.

1.3 What This Document Won't Tell You

   Architecture documents are by their nature difficult to read.  This
   one is no exception. The reason is that an architecture document
   contains the details sufficient to build interoperable
   implementations, but it is not a design specification. It goes out of
   its way to leave out any details which an implementation could choose
   without affecting interoperability. It also does not specify all the
   uses of the services provided because these services are properly
   regarded as general purpose tools.

   The remainder of this section includes information which is not
   properly part of the authentication architecture, but which may be
   useful in understanding why the architecture is the way it is.

1.3.1 How DASS is Embedded in an Operating System

   While architecturally DASS does not require any operating system
   support in order to be used by an application (other than the
   services listed in Section 2), it is expected that actual
   implementations of DASS will be closely tied to the operating systems
   of host computers.  This is done both for security and for

   In particular, it is expected that when a user logs into a node, a
   set of credentials will be created for that user and then associated
   by the operating system with all processes initiated by or on behalf
   of the user.  When a user delegates to a service, the remote
   operating system is expected to accept the delegation and start up
   the remote process with the delegated credentials.  Most nodes are
   expected to have credentials of their own and support the concept of
   user accounts.  When user credentials are created, the node is
   expected to verify them in its own context, determine the appropriate
   user account, and add node credentials to the created credentials

1.3.2 Forms of Credentials

   In the DASS architecture, there is a single data structure called
   "Credentials" with a large number of optional parts.  In an
Top   ToC   RFC1507 - Page 12
   implementation, it is possible that not all of the architecturally
   allowed subsets will be supported and credentials structures with
   different subsets of the data may be implemented quite differently.

   The major categories of credentials likely to be supported in an
   implementation are:

    - Claimant credentials  - these are the credentials which would
      normally be associated with a user process in order that it be
      able to create authentication tokens.  It would contain the
      user's name, login ticket, session private key, and (at least
      logically) local node credentials and cached outgoing

    - Verifier credentials -  these are the credentials which would
      normally be associated with a server which must verify tokens
      and produce mutual authentication response tokens.  Since
      servers may be started by a node on demand, some
      representation of verifier credentials must exist independent
      of a process.  If an operating system wishes to authenticate a
      request before starting a server process, the credentials must
      exist in usable form.  An implementation may choose to have
      all services on a "node" share a verifier credentials
      structure, or it may choose to have each service have its own.

    - Combined credentials - architecturally, a server may have a
      structure which is both claimant credentials and verifier
      credentials combined so that the server may act in either role
      using a single structure.  There is some overlap in the
      contents.  There is no requirement, however, that an
      implementation support such a structure.

    - Stub credentials - In the architecture, a credentials
      structure is created whenever a token is accepted.  If delegation
      took place, these are claimant credentials usable by their
      possessor to create additional tokens.  If no delegation took
      place, this structure exists as an architectural place holder
      against which an implementation may attempt to authenticate
      user and node names.  An implementation might choose to
      implement  stub credentials  with a different mechanism than
      claimant or verifier credentials.  In particular, it might do
      whatever user and node authentication is useful itself and not
      support this structure at all.
Top   ToC   RFC1507 - Page 13
1.3.3 Support for Alternative Certification Authority

   A motivating factor in much of the design of DASS is the need to
   protect certification authorities from compromise. CAs are only used
   to create certificates for new principals and to renew them on
   expiration (expiration intervals are likely to be measured in
   months). They therefore do not need to be highly available. For
   maximum security, CAs could be implemented on standalone PCs where
   the hardware, software, and keys can be locked in a safe when the CA
   is not in use. The certificates the CA generates must be delivered to
   the naming service to be registered, and a possible mechanism for
   this is for the CA to have an RS232 line to an on-line component
   which can pass certificates and related information but not login
   sessions. The intent would be to make it implausible to mount a
   network attack against the CA.  Alternatively, certificates could be
   carried to the network on a floppy disk.

   For CAs to be secure, a whole host of design details must be done
   right. The most important of these is the design of user and system
   manager interfaces that make it difficult to "trick" a user or system
   manager into doing the wrong thing and certifying an impostor or
   revealing a key. Mechanisms for generating keys must also be
   carefully protected to assure that the generated key cannot be
   guessed (because of lack of randomness) and is not recorded where a
   penetrator can get it. Because a certificate contains relatively
   little human intelligible information (its most important components
   are UIDs and public keys), it will be a challenge to design a user
   interface that assures the human operator only authorizes the signing
   of intented certificates. Such considerations are beyond the scope of
   the architecture (since they do not affect interoperability), but
   they did affect the design in subtle ways.  In particular, it does
   not assume uniform security throughout the CA hierarchy and is
   designed to assure that the compromise of a CA in one part of the
   hierarchy does not have global implications.

   The architecture does not require that CAs be off-line. The CA could
   be software that can run on any node when the proper secret is
   installed.  Administrative convenience can be gained by integrating
   the CA with account registration utilities and naming service
   maintenance. As such, the CA would have to be on-line when in use in
   order to register certificates in the naming service.  The CA key
   could be unlocked with a password and the password could be entered
   on each use both to authenticate the CA operator and to assure that
   compromise of the host node while the CA is not in use will not
   compromise the CA.  This design would be subject to attacks based on
   planting Trojan horses in the CA software, but is entirely
   interoperable with a more secure implementation.  Realistic tradeoffs
Top   ToC   RFC1507 - Page 14
   must be made between security, cost, and administrative convenience
   bearing in mind that a system is only as secure as its weakest link
   and that there is no benefit in making the CA substantially more
   secure than the other components of the system.

1.3.4 Services Provided vs. Application Program Interface

   Section 3 of this document specifies "abstract interfaces" to the
   services provided by DASS. This means it tells what services are
   provided, what parameters are supplied by the caller, and what data
   is returned. It does not specify the calling interfaces.  Calling
   interfaces may be platform, operating system, and language dependent.
   They do not affect interoperability; different implementations which
   implement completely different calling interfaces can still
   interoperate over a network. They do, however, affect portability. A
   program which runs on one platform can only run on another which
   implements an identical API.

   In order to support portability of applications - not just between
   implementations of DASS but between implementations of DASS and
   implementations of Kerberos - a "Generic Security Service API" has
   been designed and is outlined in Annex B. This API could be the only
   "published" interface to DASS services.  This interface does not,
   however, give access to all the functions provided by DASS and it
   provides some non-DASS services. It does not give access to the
   "login" service, for example, so the login function cannot be
   implemented in a portable way. Clearly an implementation must provide
   some implementation of the login function, though perhaps only to one
   system program and the implementation need not be portable.
   Similarly, the Generic API provides no access to node authentication
   information, so applications which use these services may not be

   The Generic API provides services for encryption of user data for
   integrity and possibly privacy. These services are not specified as a
   part of the DASS architecture. This is because we envisioned that
   such services would be provided by the communications network and not
   in applications. These services are provided by the Generic API
   because these services are provided by Kerberos, there exist
   applications which use these services, and they are desired in the
   context of the IETF-CAT work. The DASS architecture includes a Key
   Distribution service so that the encryption functions of the Generic
   API can be supported and integrated. Annex B specifies how those
   services can be implemented using DASS services.

   The Services Provided also differ from the GSSAPI because there are
   important extensions envisioned to the API for future applications
   and it was important to assure that architecturally those services
Top   ToC   RFC1507 - Page 15
   were available.  In particular, DASS provides the ability for a
   principal to have multiple aliases and for the receiver of an
   authentication token to verify any one of them.  We want DASS to
   support the case where a server only learns the name it is trying to
   validate in the course of evaluating an ACL.  This may be long after
   a connection is accepted.  The Services Provided section therefore
   separates the Accept_token function from the Verify Principal Name.
   The other motivation behind a different interface is that DASS
   provides node authentication - the ability to authenticate the node
   from which a request originates as well as the user.  Because
   Kerberos provides no such mechanism, the capability is missing from
   the GSSAPI, but we expect some applications will want to make use of

1.3.5 Use of a Naming Service

   With the exception of the syntactical representation of names, which
   is tied to X.500, the DASS architecture is designed to be independent
   of the particular underlying naming service.  While the intention is
   that certificates be stored in an X.500 naming service in the fields
   architecturally reserved for this purpose in the standard, this
   specification allows for the possibility of different forms of
   certificate stores.  The SPX implementation of DASS implements its
   own certificate distribution service because we did not want to
   introduce a dependency on an X.500 naming service.

1.3.6 Key Hiding - Credentials

   The abstract interfaces described in section 3 specify that
   "credentials" and "keys" are the inputs and outputs of various
   routines.  Credentials structures in particular contain secret
   information which should not be made available to the calling
   application.  In most cases, keeping this information from
   applications is simply a matter of prudence - a misbehaving
   application can do nearly as much damage using the credentials as it
   can by using the secrets directly.  Having access to the keys
   themselves may allow an application to bypass auditing or leak a key
   to an accomplice who can use it on another node where a large amount
   of activity is less likely to be noticed.  In some cases, most
   dramatically where a "node key" is present in user credentials, it is
   vital that the contents of the credentials be kept out of the hands
   of applications.

   To accomplish this, a concrete interface is expected to create
   "credentials handles" that are passed in and out of DASS routines.
   The credentials themselves would be kept in some portion of memory
   where unprivileged code can't get at them.
Top   ToC   RFC1507 - Page 16
   There is another aspect of the way credentials are used which is
   important to the design of real implementations.  In normal use, a
   user will create a set of credentials in the process of logging on to
   a system and then use them from many processes or jobs.  When many
   processes share a set of credentials, it is important for the sake of
   performance that they share one set of credentials rather than having
   a copy of the credentials made for each.  This is because information
   is cached in credentials as a side effect of some requests and for
   good performance those caches should be shared.

   As an example, consider a system executing a series of copy commands
   moving files from one system to another.  The credentials of the user
   will have been established when the user logged on.  The first time a
   copy is requested, a new process will start up, open a connection to
   the destination system, and create a token to authenticate itself.
   Creating that token will be an expensive operation, but information
   will be computed and "cached" in the credentials structure which will
   allow any subsequent tokens on behalf of that user to that server to
   be computed cheaply.  After the copy completes, the connection is
   closed and the process terminates.  In response to a second copy
   request, another new process will be created and a new token
   computed.  For this operation to get a performance benefit from the
   caching, the information computed by the first process must somehow
   make it to the second.

   A model for how this caching might work can be seen in the way
   Kerberos caches credentials.  Kerberos keeps credentials in a file
   whose name can be computed from the name of the local user.  This
   file is initialized as part of the login process and its protection
   is set so that only processes running under the UID of the user may
   read and write the file.  Processes cache information there; all
   processes running on behalf of the user share the file.

   There are two problems with this scheme: first, on a diskless node
   putting information in a file exposes it to eavesdroppers on the
   network; second, it does not accomplish the "key hiding" function
   described earlier in this section.  In a more secure implementation,
   the kernel or a privileged process would manage some "pool" of
   credentials for all processes on a node and would grant access to
   them only through the DASS calls.  Credentials structures are complex
   and varying length; DASS may organize them as a set of pools rather
   than as contiguous blocks of data.  All such design issues are
   "beyond the scope of the architecture".  Implementations must decide
   how to control access to credentials.  They could copy the Kerberos
   scheme of having credentials available to processes with the UID of
   the login session which created them and to privileged processes or
   there may be a more elaborate mechanism for "passing" credentials
   handles from process to process.  This design should probably follow
Top   ToC   RFC1507 - Page 17
   the operating system mechanisms for passing around local privileges.

1.3.7 Key Hiding - Contexts

   The "GSSAPI" has a concept of a security context which has some of
   the same key hiding problems as a credentials structure.  Security
   contexts are used in calls to cryptographically protect user data
   (from modification or from disclosure and modification) using keys
   established during authentication.  The "services provided"
   specification says that create_ and accept_token return a "shared
   key" and "instance identifier".  The GSSAPI says that a context
   handle is returned which is an integer.  A secure implementation
   would keep the key and instance identifier in protected memory and
   only allow access to them through provided interfaces.

   Unlike credentials, there is probably no need to provide mechanisms
   for contexts to be shared between processes.  Contexts will normally
   be associated with some notion of a communications "connection" and
   ends of a connection are not normally shared.  If an implementation
   chooses to provide additional services to applications like message
   sequencing or duplicate detection, contexts will have to contain
   additional fields.  These can be created and maintained without any
   additional authentication services.

1.4 The Relationship between DASS and ISO Standards

   This section provides an introduction to DASS authentication in terms
   of the ISO Authentication Framework (DP10181-2).   The purpose of
   this introduction is to give the reader an intuitive understanding of
   the way DASS works and how its mechanisms and terminology relate to
   standards.  Important details have been omitted here but are spelled
   out in section 3.

1.4.1 Concepts

   The primary goal of authentication is to prevent impersonation, that
   is, the pretense to a false identity. Authentication always involves
   identification in some form. Without authentication, anyone could
   claim to be whomever they wished and get away with it.

   If it didn't matter with whom one was communicating, elaborate
   procedures for authentication would be unnecessary. However, in most
   systems, and in timesharing and distributed processing environments
   in particular, the rights of individuals are often circumscribed by
   security policy. In particular, authorization (identity based access
   control) and accountability (audit) provisions could be circumvented
   if masquerading attempts were impossible to prevent or detect.
Top   ToC   RFC1507 - Page 18
   Almost all practical authentication mechanisms suitable for use in
   distributed environments rely on knowledge of some secret
   information. Most differences lie in how one presents evidence that
   they know the secret. Some schemes, in particular the familiar simple
   use of passwords, are quite susceptible to attack. Generally, the
   threats to authentication may be classified as:

    - forgery, attempting to guess or otherwise fabricate evidence;

    - replay, where one can eavesdrop upon another's authentication
      exchange and learn enough to impersonate them; and

    - interception, where one slips between the communicants and is
      able to modify the communications channel unnoticed.

   Most such attacks can be countered by using what is known as strong
   authentication. Strong authentication refers to techniques that
   permit one to provide evidence that they know a particular secret
   without revealing even a hint about the secret. Thus neither the
   entity to whom one is authenticating, nor an eavesdropper on the
   conversation can further their ability to impersonate the
   authenticating principal at some future time as the result of an
   authentication exchange.

   Strong authentication mechanisms, in particular those used here, rely
   on cryptographic techniques. In particular, DASS uses public key
   cryptography. Note that interception attacks cannot be countered by
   strong authentication alone, but generally need additional security
   mechanisms to secure the communication channel, such as data

1.4.2 Principals and Their Roles

   All authentication is on behalf of principals. In DASS the following
   types of principals are recognized:

    - user principals, normally people with accounts who are
      responsible for performing particular tasks. Generally it is
      users that are authorized to do things by virtue of having
      been granted access rights, or who are to be held accountable
      for specific actions subject to being audited.

    - server principals, which are accessed by users.

    - node principals,  corresponding to locations where users and
      servers, or more accurately, processes acting on behalf of
      principals can reside.
Top   ToC   RFC1507 - Page 19
   Principals can act in one of two capacities:

    - the claimant is the active entity seeking to authenticate
      itself, and

    - the verifier is the passive entity to whom the claimant is

   Users normally are claimants, whereas servers are usually verifiers,
   although sometimes servers can also be claimants.

   There is another kind of principal:

    - certification authorities (CA's) issue certificates which
      attest to another principal's public key.

1.4.3 Representation, Delegation and Representation Transfer

   Of course, although it is users that are responsible for what the
   computer does, human beings are physically unable to directly do
   anything within a computer system. In point of fact, it is a
   process executing on behalf of a user that actually performs
   useful work. From the point of view of performing security
   controlled functions, the process is the agent, or
   representative, of the user, and is authorized by that user to do
   things on his behalf. In the terms used in the ISO Authentication
   Framework, the user is said to have a representation in the

   The representation has to come into existence somehow.  Delegation
   refers to the act of creating a representation. A user is said to
   create a representation for themselves by delegating to a process. If
   the user creates another process, say by doing an rlogin on a
   different computer, a representation may be needed there as well. This
   may be accomplished automatically by a process known as representation
   transfer.  DASS uses the term delegation to also mean the act of
   creating additional representations on a remote systems.

   A representation is instantiated in DASS as credentials.  Credentials
   include the identity of the principal as well as the cryptographic
   "state" needed to engage in strong authentication procedures. Claimant
   information in credentials enable principals to authenticate
   themselves to others, whereas verifier information in credentials
   permit principals to verify the claims of others.  Credentials
   intended primarily for use by a claimant will be referred to as
   claimant credentials in the text which follows.  Credentials intended
   primarily for use in verification will be referred to as verifier
   credentials.  A particular set of credentials may or may not contain
Top   ToC   RFC1507 - Page 20
   all of the data necessary to be used in both roles.  That will depend
   on the mechanisms by which the credentials were created.

   In some contexts, but not here, the concept of representation
   and/or delegation is sometimes referred to as proxy. This term is
   used in ECMA TR/46.  We avoid use of the term because of possible
   confusion with an unrelated use of the term in the context of

1.4.4 Key Distribution, Replay, Mutual Authentication and Trust

   Strong authentication uses cryptographic techniques. The
   particular mechanisms used in DASS result in the distribution of
   cryptographic keys as a side effect. These keys are suitable for
   use for providing a data origin authentication service and/or a
   data confidentiality service between a pair of authenticated

   Replay detection is provided using timestamps on relevant
   authentication messages, combined with remembering previously
   accepted messages until they become "stale". This is in contrast
   to other techniques, such as challenge and response exchanges.

   Authentication can be one-way or mutual. One-way authentication is
   when only one party, in DASS the claimant, authenticates to the other.
   Mutual authentication provides, in addition, authentication of the
   verifier back to the claimant. In certain communications schemes, for
   example connectionless transfer, only one-way authentication is
   meaningful. DASS supports mutual authentication as a simple extension
   of one-way authentication for use in environments where it makes

   DASS potentially can allow many different "trust relationships"
   to exist. All principals trust one or more CA's to safeguard the
   certification process. Principals use certificates as the basis
   for authenticating identities, and trust that CA's which issue
   certificates act responsibly. Users expect CA's to make sure that
   certificates (and related secrets) are only made for principals
   that the CA knows or has properly authenticated on its own.

1.5 An Authentication Walkthrough

   The OSI Authentication Framework characterizes authentication as
   occurring in six phases. This section attempts to describe DASS
   in these terms.
Top   ToC   RFC1507 - Page 21
1.5.1 Installation

   In this phase, principal certificates are created, as is the
   additional information needed to create claimant and verifier
   credentials. OSI defines three sub-phases:

    - Enrollment. In DASS, this is the definition of a principal in
      terms of a key, name and UID.

    - Validation,  confirmation of identity to the satisfaction of
      the CA, after which the CA generates a certificate.

    - Confirmation.  In DASS, this is the act of providing the user
      with the certificate and with the CA's own name, key and UID,
      followed up by the user creating a  trusted authority for that
      CA. A trusted authority is a certificate for the CA signed by
      the user.

   Included in this step in DASS is the posting of the certificate so as
   to be available to principals wishing to verify the principal's
   identity. In addition, the user principal saves the trusted authority
   so as to be available when it creates credentials.

1.5.2 Distribution

   DASS distributes certificates by placing them in the name service.

1.5.3 Acquisition

   Whenever principals wish to authenticate to one another, they access
   the Name Service to obtain whatever public key certificates they need
   and create the necessary credentials. In DASS, acquisition means
   obtaining credentials.

   Claimant credentials implement the representation of a principal in a
   process, or, more accurately, provide a representation of the
   principal for use by a process. In making this representation, the
   principal delegates to a temporary delegation key. In this fashion
   the claimant's long term principal key need not remain in the system.

   Claimant credentials are made by invoking the get credentials
   primitive. Claimant credentials are a DASS specific data structure

    - a name

    - a ticket, a data structure containing
Top   ToC   RFC1507 - Page 22
      .  a validity interval,

      .  UID, and

      .  (temporary) delegation public key, along with a

      .  digital signature on the above made with the principal
         private key

    - the delegation private key

   Optionally in addition, there may be credential information relating
   to the node on which the user is logged in and the account on that
   node.  A detailed description of all the information found in
   credentials can be found in section 3.  Verifier credentials are made
   with initialize_server. Verifier credentials consist of a principal
   (long term) private key. The rationale is that these credentials are
   usually needed by servers that must be able to run indefinitely
   without re-entry of any long term key.

   In addition, claimants and verifiers have a trusted authority, which
   consists of information about a trusted CA.  That information is its:

    - name (this will appear in the "issuer" field in principal

    - public key (to use in verifying certificates issued by that
      CA), and

    - UID.

   Trusted authorities are used by principals to verify certificates for
   other principals' public keys.  CAs are arranged in a hierarchy
   corresponding to the naming hierarchy, where each directory in the
   naming hierarchy is controlled by a single CA.  Each CA certifies the
   CA of its parent directory, the CAs of each of its child directories,
   and optionally CAs elsewhere in the naming hierarchy (mainly to deal
   with the case where the directories up to a common ancestor lack
   CAs).  Even though a principal has only a single CA as a trusted
   authority, it can securely obtain the public key of any principal in
   the namespace by "walking the CA hierarchy".

1.5.4 Transfer

   The DASS exchange of authentication information is illustrated in
   Figure 1-1. During the transfer phase, the DASS claimant sends an
   authentication token  to the verifier. Authentication tokens are made
   by invoking the create_token primitive. The authentication token is
Top   ToC   RFC1507 - Page 23
   cryptographically protected and specified as a DASS data structure in
   ASN.1. The authentication token includes:

    - a ticket,

    - a DES authenticating key encrypted using the intended
      verifier's public key

    - one of the following:

      . if delegation is not being performed, a digital signature on
        the encrypted DES key using the delegation private key, or

      . if delegation is being performed, sending the delegation
        private key, DES encrypted using the DES authenticating key

    - an authenticator, which is a cryptographic checksum made using
      the DES authenticating key over a buffer containing

      . a timestamp

      . any application supplied "channel bindings". For example,
        addresses or other context information. The purpose of this
        field is to thwart substitution and replay attacks.

    - additional optional information concerning node authentication
      and context.

   As a side effect, after init_authentication_context, the caller
   receives a local authentication context, a data structure containing:

    - the DES key, and

    - if mutual authentication is being requested, the expected

   In order to construct an authentication token, the claimant needs to
   access the verifier's public key certificate from the Name Service
   (labeled CDC, for Certificate Distribution Center, in the figure).

   Note that while an authenticator can only be used once, it is
   permissible to re-establish the same local authentication context
   multiple times. That is, the ticket and DES key establishment
   components of the authentication token may have a relatively long
   lifetime. This permits a performance improvement in that repeated
   applications of public key operations can be alleviated if one caches
   authentication contexts, along with other components from a
   successfully used authentication token and the associated verified
Top   ToC   RFC1507 - Page 24
   principal public key value. It is a relatively inexpensive operation
   to create (and verify) "fresh" authenticators based on cached
   authentication context.

      Claimant Actions      | Communications |  Verifier Actions
                            |                |
           verifier name    |                |
                   |        |                |
                   |        |           +---+|
                   \------------------->|   ||
     trusted                |           |   ||
   authorities              |           |CDC||
        |    +-----------+  |certificate|   ||
        |    |  Verify   |<-------------|   ||
        \--->|Certificate|  |           +---+|
             +-----------+  |                |
     Claimant        |      |                |
   credentials    Verifier  |                |   Verifier
        |       Public Key  |                | Credentials
        |            |      |                |       |
        |            V      |                |       V
        |    +-----------+  | Authentication | +-----------+
        |    |   Make    |  |     Token      | |   Check   |   Replay
        \--->|  Token    |-------------------->|   Token   |<-->Cache
             +-----------+  |                | +-----------+
      DES <---/      |      |                |  |   |    \----->DES
      key            |      |                | /Claimant        key
                     |      |                |/Public Key
                     |      |                /      |        trusted
                     |      |      Claimant /|      V     authorities
                     |      |+---+   Name  / | +-----------+     |
            authentication  ||   |<-------/  | |  Verify   |<----/
               context      ||   |certificate| |Certificate|
                     |      ||CDC|------------>|           |-->accept/
                     |      ||   |           | +-----------+   reject
                     |      ||   |           |      |      \
                     |      |+---+           |authentication\
                     V      |     mutual     |   context     V
             +-----------+  | authentication |      |      claimant
          /--|  Accept   |  |    response    | +----------+credentials
         V   |  Mutual   |<--------------------|  Make    |(delegation)
     accept/ +-----------+  |                | | Response |
     reject                 |                | +----------+
                            |                |

              Figure 1 - Authentication Exchange Overview
Top   ToC   RFC1507 - Page 25
1.5.5 Verification

   Upon receipt of an authentication token, the verifier extracts the
   DES key using its verifier credentials, accesses the Name Service
   (labeled CDC for Certificate Distribution Center) to obtain the
   certificates needed to perform cryptographic checks on the incoming
   information, and verifies all of the signatures on the received
   certificates and the authentication token.  Verification can result
   in creation of new claimant credentials if delegation is performed.

   As part of this process, verified authenticators are retained for a
   suitable timeout period.

1.5.6 Unenrolment

   This is the removal of information from the Name Service. The only
   other form of revocation supported by DASS is certificate timeout.
   Every certificate contains an expiration time (expected in ordinary
   use to be about a year from its signing date).  DASS does not
   currently support the revocation lists in X.509.

(page 25 continued on part 2)

Next Section