RFCs in HTML Format

RFC 1507

              Distributed Authentication Security Service

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

Kaufman                                                         [Page 1]

RFC 1507 DASS September 1993 A.2 Creating a User Principal ............................ 102 A.3 Creating a Server Principal .......................... 103 A.4 Booting a Server Principal ........................... 103 A.5 A user logs on to the network ........................ 103 A.6 An Rlogin (TCP/IP) connection is made ................ 104 A.7 A Transport-Independent Connection ................... 104 Annex B - Support of the GSSAPI ................................ 104 B.1 Summary of GSSAPI .................................... 105 B.2 Implementation of GSSAPI over DASS ................... 106 B.3 Syntax ............................................... 110 Annex C - Imported ASN.1 definitions ........................... 112 Glossary ....................................................... 114 Security Considerations ......................................... 119 Author's Address ................................................ 119 Figures Figure 1 - Authentication Exchange Overview .................... 24 1. Introduction 1.1 What is DASS? Authentication is a security service. The goal of authentication is to reliably learn the name of the originator of a message or request. The classic way by which people authenticate to computers (and by which computers authenticate to one another) is by supplying a password. There are a number of problems with existing password based schemes which DASS attempts to solve. The goal of DASS is to provide authentication services in a distributed environment which are both more secure (more difficult for a bad guy to impersonate a good guy) and easier to use than existing mechanisms. In a distributed environment, authentication is particularly challenging. Users do not simply log on to one machine and use resources there. Users start processes on one machine which may request services on another. In some cases, the second system must request services from a third system on behalf of the user. Further, given current network technology, it is fairly easy to eavesdrop on conversations between computers and pick up any passwords that might be going by. DASS uses cryptographic mechanisms to provide "strong, mutual" authentication. Mutual authentication means that the two parties communicating each reliably learn the name of the other. Strong authentication means that in the exchange neither obtains any information that it could use to impersonate the other to a third party. This can't be done with passwords alone. Mutual authentication can be done with passwords by having a "sign" and a "counter-sign" which the two parties must utter to assure one another Kaufman [Page 2]
RFC 1507 DASS September 1993 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 Kaufman [Page 3]
RFC 1507 DASS September 1993 this happens, computers will continue to support the concept of "local accounts" and access controls on resources on those systems will still be based on those accounts. There is today within the Berkeley rtools running over the Internet Protocol suite the concept of a ".rhosts database" which gives access to local accounts from remote accounts. We envision that those databases will be extended to support granting access to local accounts based on DASS global names as a bridge between the past and the future. DASS should greatly simplify the administration of those databases for the (presumably common) case where a user should be granted access to an account ignoring his choice of intermediate systems. 1.2 Central Concepts 1.2.1 Strong Authentication with Public Keys DASS makes heavy use of the RSA Public Key cryptosystem. The important properties of the RSA algorithms for purposes of this discussion are: - It supports the creation of a public/private key pair, where operations with one key of the pair reverse the operations of the other, but it is computationally infeasible to derive the private key from the public key. - It supports the "signing" of a message with the private key, after which anyone knowing the public key can "verify" the signature and know that it was constructed with knowledge of the private key and that the message was not subsequently altered. - It supports the "enciphering" of a message by anyone knowing the public key such that only someone with knowledge of the private key can recover the message. With access to the RSA algorithms, it is easy to see how one could construct a "strong" authentication mechanism. Each "principal" (user or computer) would construct a public/private key pair, publish the public key, and keep secret the private key. To authenticate to you, I would write a message, sign it with my private key, and send it to you. You would verify the message using my public key and know the message came from me. If mutual authentication were desired, you could create an acknowledgment and sign it with your private key; I could verify it with your public key and I would know you received my message. The authentication algorithms used by DASS are considerably more complex than those described in the paragraph above in order to deal Kaufman [Page 4]
RFC 1507 DASS September 1993 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 Kaufman [Page 5]
RFC 1507 DASS September 1993 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 Kaufman [Page 6]
RFC 1507 DASS September 1993 service without trusting it for more than the service it is delivering. When using some services, for example remote login services, I may want that service to act on my behalf in calling additional services. DASS provides a mechanism whereby I can pass secrets to such services that allow them to impersonate me. Future versions of this architecture may allow "limited delegation" so that a user may delegate to a server only those rights the server needs to carry out the user's wishes. This version can limit delegation only in terms of time. The information a user gives a server (other than the initial login node) can be used to impersonate the user but only for a limited period of time. Smart cards will permit that time limitation to apply to the initial login node as well. 1.2.4 Certification Authorities A flaw in the strong authentication mechanism described above is that it assumes that every "principal" (user and node) knows the public key of every other principal it wants to authenticate. If I can fool a server into thinking my public key is actually your public key, I can impersonate you by signing a message, saying it is from you, and having the server verify the message with what it thinks is your public key. To avoid the need to securely install the public key of every principal in the database of every other principal, the concept of a "Certification Authority" was invented. A certification authority is a principal trusted to act as an introduction service. Each principal goes to the certification authority, presents its public key, and proves it has a particular name (the exact mechanisms for this vary with the type of principal and the level of security to be provided). The CA then creates a "certificate" which is a message containing the name and public key of the principal, an expiration date, and bookkeeping information signed by the CA's private key. All "subscribers" to a particular CA can then be authenticated to one another by presenting their certificates and proving knowledge of the corresponding secret. CAs need only act when new principals are being named and new private keys created, so that can be maintained under tight physical security. The two problems with the scheme as described so far are "revocation" and "scaleability". 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 Kaufman [Page 7]
RFC 1507 DASS September 1993 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. Kaufman [Page 8]
RFC 1507 DASS September 1993 DASS addresses this problem by creating a hierarchy of CAs. The CA hierarchy is tied to the naming hierarchy. For each directory in the namespace, there is a single CA responsible for certifying the public keys of its members. That CA will also certify the public keys of the CAs of all child directories and of the CA of the parent directory. With this cross-certification, it is possible knowing the public key of any CA to verify the public keys of a series of intermediate CAs and finally to verify the public key of any principal. Because the CA hierarchy is tied to the naming hierarchy, the trust placed in any individual CA is limited. If a CA is compromised, it can impersonate any of the principals listed in its directory, but it cannot impersonate arbitrary principals. DASS provides mechanisms for every principal to know the public key of its "parent" CA - the CA controlling the directory in which it is named. The result is the following rules for the implications of a compromised CA: a) A CA can impersonate any principal named in its directory. b) A CA can impersonate any principal to a server named in its directory. c) A CA can impersonate any principal named in a subdirectory to any server not named in the same subdirectory. d) A CA can impersonate to any server in a subdirectory any principal not named in the same subdirectory. The implication is that a compromise low in the naming tree will compromise all principals below that directory while a compromise high in the naming tree will compromise only the authentication of principals far apart in the naming hierarchy. In particular, when multiple organizations share a namespace (as they do in the case of X.500), the compromise of a CA in one organization can not result in false authentication within another organization. DASS uses the X.500 directory hierarchy for principal naming. At the top of the hierarchy are names of countries. National authorities are not expected to establish certification authorities (at least initially), so an alternative mechanism must be used to authenticate entities "distant" in the naming hierarchy. The mechanism for this in DASS is the "cross-certificate" where a CA certifies the public key for some CA or principal not its parent or child. By limiting the chains of certificates they will use to parent certificates followed by a single "cross certificate" followed by child Kaufman [Page 9]
RFC 1507 DASS September 1993 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. Kaufman [Page 10]
RFC 1507 DASS September 1993 Another way in which user keys are protected is that the architecture does not require that they be available except briefly at login. This reduces the threat of a user walking away from a logged on workstation and having someone take over the workstation and extract his key. It also makes the use of RSA based smart cards practical; the card could keep the user's private key and execute one signature operation at login time to authenticate an entire session. 1.3 What This Document Won't Tell You Architecture documents are by their nature difficult to read. This one is no exception. The reason is that an architecture document contains the details sufficient to build interoperable implementations, but it is not a design specification. It goes out of its way to leave out any details which an implementation could choose without affecting interoperability. It also does not specify all the uses of the services provided because these services are properly regarded as general purpose tools. The remainder of this section includes information which is not properly part of the authentication architecture, but which may be useful in understanding why the architecture is the way it is. 1.3.1 How DASS is Embedded in an Operating System While architecturally DASS does not require any operating system support in order to be used by an application (other than the services listed in Section 2), it is expected that actual implementations of DASS will be closely tied to the operating systems of host computers. This is done both for security and for convenience. In particular, it is expected that when a user logs into a node, a set of credentials will be created for that user and then associated by the operating system with all processes initiated by or on behalf of the user. When a user delegates to a service, the remote operating system is expected to accept the delegation and start up the remote process with the delegated credentials. Most nodes are expected to have credentials of their own and support the concept of user accounts. When user credentials are created, the node is expected to verify them in its own context, determine the appropriate user account, and add node credentials to the created credentials set. 1.3.2 Forms of Credentials In the DASS architecture, there is a single data structure called "Credentials" with a large number of optional parts. In an Kaufman [Page 11]
RFC 1507 DASS September 1993 implementation, it is possible that not all of the architecturally allowed subsets will be supported and credentials structures with different subsets of the data may be implemented quite differently. The major categories of credentials likely to be supported in an implementation are: - Claimant credentials - these are the credentials which would normally be associated with a user process in order that it be able to create authentication tokens. It would contain the user's name, login ticket, session private key, and (at least logically) local node credentials and cached outgoing contexts. - Verifier credentials - these are the credentials which would normally be associated with a server which must verify tokens and produce mutual authentication response tokens. Since servers may be started by a node on demand, some representation of verifier credentials must exist independent of a process. If an operating system wishes to authenticate a request before starting a server process, the credentials must exist in usable form. An implementation may choose to have all services on a "node" share a verifier credentials structure, or it may choose to have each service have its own. - Combined credentials - architecturally, a server may have a structure which is both claimant credentials and verifier credentials combined so that the server may act in either role using a single structure. There is some overlap in the contents. There is no requirement, however, that an implementation support such a structure. - Stub credentials - In the architecture, a credentials structure is created whenever a token is accepted. If delegation took place, these are claimant credentials usable by their possessor to create additional tokens. If no delegation took place, this structure exists as an architectural place holder against which an implementation may attempt to authenticate user and node names. An implementation might choose to implement stub credentials with a different mechanism than claimant or verifier credentials. In particular, it might do whatever user and node authentication is useful itself and not support this structure at all. Kaufman [Page 12]
RFC 1507 DASS September 1993 1.3.3 Support for Alternative Certification Authority Implementations A motivating factor in much of the design of DASS is the need to protect certification authorities from compromise. CAs are only used to create certificates for new principals and to renew them on expiration (expiration intervals are likely to be measured in months). They therefore do not need to be highly available. For maximum security, CAs could be implemented on standalone PCs where the hardware, software, and keys can be locked in a safe when the CA is not in use. The certificates the CA generates must be delivered to the naming service to be registered, and a possible mechanism for this is for the CA to have an RS232 line to an on-line component which can pass certificates and related information but not login sessions. The intent would be to make it implausible to mount a network attack against the CA. Alternatively, certificates could be carried to the network on a floppy disk. For CAs to be secure, a whole host of design details must be done right. The most important of these is the design of user and system manager interfaces that make it difficult to "trick" a user or system manager into doing the wrong thing and certifying an impostor or revealing a key. Mechanisms for generating keys must also be carefully protected to assure that the generated key cannot be guessed (because of lack of randomness) and is not recorded where a penetrator can get it. Because a certificate contains relatively little human intelligible information (its most important components are UIDs and public keys), it will be a challenge to design a user interface that assures the human operator only authorizes the signing of intented certificates. Such considerations are beyond the scope of the architecture (since they do not affect interoperability), but they did affect the design in subtle ways. In particular, it does not assume uniform security throughout the CA hierarchy and is designed to assure that the compromise of a CA in one part of the hierarchy does not have global implications. The architecture does not require that CAs be off-line. The CA could be software that can run on any node when the proper secret is installed. Administrative convenience can be gained by integrating the CA with account registration utilities and naming service maintenance. As such, the CA would have to be on-line when in use in order to register certificates in the naming service. The CA key could be unlocked with a password and the password could be entered on each use both to authenticate the CA operator and to assure that compromise of the host node while the CA is not in use will not compromise the CA. This design would be subject to attacks based on planting Trojan horses in the CA software, but is entirely interoperable with a more secure implementation. Realistic tradeoffs Kaufman [Page 13]
RFC 1507 DASS September 1993 must be made between security, cost, and administrative convenience bearing in mind that a system is only as secure as its weakest link and that there is no benefit in making the CA substantially more secure than the other components of the system. 1.3.4 Services Provided vs. Application Program Interface Section 3 of this document specifies "abstract interfaces" to the services provided by DASS. This means it tells what services are provided, what parameters are supplied by the caller, and what data is returned. It does not specify the calling interfaces. Calling interfaces may be platform, operating system, and language dependent. They do not affect interoperability; different implementations which implement completely different calling interfaces can still interoperate over a network. They do, however, affect portability. A program which runs on one platform can only run on another which implements an identical API. In order to support portability of applications - not just between implementations of DASS but between implementations of DASS and implementations of Kerberos - a "Generic Security Service API" has been designed and is outlined in Annex B. This API could be the only "published" interface to DASS services. This interface does not, however, give access to all the functions provided by DASS and it provides some non-DASS services. It does not give access to the "login" service, for example, so the login function cannot be implemented in a portable way. Clearly an implementation must provide some implementation of the login function, though perhaps only to one system program and the implementation need not be portable. Similarly, the Generic API provides no access to node authentication information, so applications which use these services may not be portable. The Generic API provides services for encryption of user data for integrity and possibly privacy. These services are not specified as a part of the DASS architecture. This is because we envisioned that such services would be provided by the communications network and not in applications. These services are provided by the Generic API because these services are provided by Kerberos, there exist applications which use these services, and they are desired in the context of the IETF-CAT work. The DASS architecture includes a Key Distribution service so that the encryption functions of the Generic API can be supported and integrated. Annex B specifies how those services can be implemented using DASS services. The Services Provided also differ from the GSSAPI because there are important extensions envisioned to the API for future applications and it was important to assure that architecturally those services Kaufman [Page 14]
RFC 1507 DASS September 1993 were available. In particular, DASS provides the ability for a principal to have multiple aliases and for the receiver of an authentication token to verify any one of them. We want DASS to support the case where a server only learns the name it is trying to validate in the course of evaluating an ACL. This may be long after a connection is accepted. The Services Provided section therefore separates the Accept_token function from the Verify Principal Name. The other motivation behind a different interface is that DASS provides node authentication - the ability to authenticate the node from which a request originates as well as the user. Because Kerberos provides no such mechanism, the capability is missing from the GSSAPI, but we expect some applications will want to make use of it. 1.3.5 Use of a Naming Service With the exception of the syntactical representation of names, which is tied to X.500, the DASS architecture is designed to be independent of the particular underlying naming service. While the intention is that certificates be stored in an X.500 naming service in the fields architecturally reserved for this purpose in the standard, this specification allows for the possibility of different forms of certificate stores. The SPX implementation of DASS implements its own certificate distribution service because we did not want to introduce a dependency on an X.500 naming service. 1.3.6 Key Hiding - Credentials The abstract interfaces described in section 3 specify that "credentials" and "keys" are the inputs and outputs of various routines. Credentials structures in particular contain secret information which should not be made available to the calling application. In most cases, keeping this information from applications is simply a matter of prudence - a misbehaving application can do nearly as much damage using the credentials as it can by using the secrets directly. Having access to the keys themselves may allow an application to bypass auditing or leak a key to an accomplice who can use it on another node where a large amount of activity is less likely to be noticed. In some cases, most dramatically where a "node key" is present in user credentials, it is vital that the contents of the credentials be kept out of the hands of applications. To accomplish this, a concrete interface is expected to create "credentials handles" that are passed in and out of DASS routines. The credentials themselves would be kept in some portion of memory where unprivileged code can't get at them. Kaufman [Page 15]
RFC 1507 DASS September 1993 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 Kaufman [Page 16]
RFC 1507 DASS September 1993 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. Kaufman [Page 17]
RFC 1507 DASS September 1993 Almost all practical authentication mechanisms suitable for use in distributed environments rely on knowledge of some secret information. Most differences lie in how one presents evidence that they know the secret. Some schemes, in particular the familiar simple use of passwords, are quite susceptible to attack. Generally, the threats to authentication may be classified as: - forgery, attempting to guess or otherwise fabricate evidence; - replay, where one can eavesdrop upon another's authentication exchange and learn enough to impersonate them; and - interception, where one slips between the communicants and is able to modify the communications channel unnoticed. Most such attacks can be countered by using what is known as strong authentication. Strong authentication refers to techniques that permit one to provide evidence that they know a particular secret without revealing even a hint about the secret. Thus neither the entity to whom one is authenticating, nor an eavesdropper on the conversation can further their ability to impersonate the authenticating principal at some future time as the result of an authentication exchange. Strong authentication mechanisms, in particular those used here, rely on cryptographic techniques. In particular, DASS uses public key cryptography. Note that interception attacks cannot be countered by strong authentication alone, but generally need additional security mechanisms to secure the communication channel, such as data encryption. 1.4.2 Principals and Their Roles All authentication is on behalf of principals. In DASS the following types of principals are recognized: - user principals, normally people with accounts who are responsible for performing particular tasks. Generally it is users that are authorized to do things by virtue of having been granted access rights, or who are to be held accountable for specific actions subject to being audited. - server principals, which are accessed by users. - node principals, corresponding to locations where users and servers, or more accurately, processes acting on behalf of principals can reside. Kaufman [Page 18]
RFC 1507 DASS September 1993 Principals can act in one of two capacities: - the claimant is the active entity seeking to authenticate itself, and - the verifier is the passive entity to whom the claimant is authenticating. Users normally are claimants, whereas servers are usually verifiers, although sometimes servers can also be claimants. There is another kind of principal: - certification authorities (CA's) issue certificates which attest to another principal's public key. 1.4.3 Representation, Delegation and Representation Transfer Of course, although it is users that are responsible for what the computer does, human beings are physically unable to directly do anything within a computer system. In point of fact, it is a process executing on behalf of a user that actually performs useful work. From the point of view of performing security controlled functions, the process is the agent, or representative, of the user, and is authorized by that user to do things on his behalf. In the terms used in the ISO Authentication Framework, the user is said to have a representation in the process. The representation has to come into existence somehow. Delegation refers to the act of creating a representation. A user is said to create a representation for themselves by delegating to a process. If the user creates another process, say by doing an rlogin on a different computer, a representation may be needed there as well. This may be accomplished automatically by a process known as representation transfer. DASS uses the term delegation to also mean the act of creating additional representations on a remote systems. A representation is instantiated in DASS as credentials. Credentials include the identity of the principal as well as the cryptographic "state" needed to engage in strong authentication procedures. Claimant information in credentials enable principals to authenticate themselves to others, whereas verifier information in credentials permit principals to verify the claims of others. Credentials intended primarily for use by a claimant will be referred to as claimant credentials in the text which follows. Credentials intended primarily for use in verification will be referred to as verifier credentials. A particular set of credentials may or may not contain Kaufman [Page 19]
RFC 1507 DASS September 1993 all of the data necessary to be used in both roles. That will depend on the mechanisms by which the credentials were created. In some contexts, but not here, the concept of representation and/or delegation is sometimes referred to as proxy. This term is used in ECMA TR/46. We avoid use of the term because of possible confusion with an unrelated use of the term in the context of DECnet. 1.4.4 Key Distribution, Replay, Mutual Authentication and Trust Strong authentication uses cryptographic techniques. The particular mechanisms used in DASS result in the distribution of cryptographic keys as a side effect. These keys are suitable for use for providing a data origin authentication service and/or a data confidentiality service between a pair of authenticated principals. Replay detection is provided using timestamps on relevant authentication messages, combined with remembering previously accepted messages until they become "stale". This is in contrast to other techniques, such as challenge and response exchanges. Authentication can be one-way or mutual. One-way authentication is when only one party, in DASS the claimant, authenticates to the other. Mutual authentication provides, in addition, authentication of the verifier back to the claimant. In certain communications schemes, for example connectionless transfer, only one-way authentication is meaningful. DASS supports mutual authentication as a simple extension of one-way authentication for use in environments where it makes sense. DASS potentially can allow many different "trust relationships" to exist. All principals trust one or more CA's to safeguard the certification process. Principals use certificates as the basis for authenticating identities, and trust that CA's which issue certificates act responsibly. Users expect CA's to make sure that certificates (and related secrets) are only made for principals that the CA knows or has properly authenticated on its own. 1.5 An Authentication Walkthrough The OSI Authentication Framework characterizes authentication as occurring in six phases. This section attempts to describe DASS in these terms. Kaufman [Page 20]
RFC 1507 DASS September 1993 1.5.1 Installation In this phase, principal certificates are created, as is the additional information needed to create claimant and verifier credentials. OSI defines three sub-phases: - Enrollment. In DASS, this is the definition of a principal in terms of a key, name and UID. - Validation, confirmation of identity to the satisfaction of the CA, after which the CA generates a certificate. - Confirmation. In DASS, this is the act of providing the user with the certificate and with the CA's own name, key and UID, followed up by the user creating a trusted authority for that CA. A trusted authority is a certificate for the CA signed by the user. Included in this step in DASS is the posting of the certificate so as to be available to principals wishing to verify the principal's identity. In addition, the user principal saves the trusted authority so as to be available when it creates credentials. 1.5.2 Distribution DASS distributes certificates by placing them in the name service. 1.5.3 Acquisition Whenever principals wish to authenticate to one another, they access the Name Service to obtain whatever public key certificates they need and create the necessary credentials. In DASS, acquisition means obtaining credentials. Claimant credentials implement the representation of a principal in a process, or, more accurately, provide a representation of the principal for use by a process. In making this representation, the principal delegates to a temporary delegation key. In this fashion the claimant's long term principal key need not remain in the system. Claimant credentials are made by invoking the get credentials primitive. Claimant credentials are a DASS specific data structure containing: - a name - a ticket, a data structure containing Kaufman [Page 21]
RFC 1507 DASS September 1993 . a validity interval, . UID, and . (temporary) delegation public key, along with a . digital signature on the above made with the principal private key - the delegation private key Optionally in addition, there may be credential information relating to the node on which the user is logged in and the account on that node. A detailed description of all the information found in credentials can be found in section 3. Verifier credentials are made with initialize_server. Verifier credentials consist of a principal (long term) private key. The rationale is that these credentials are usually needed by servers that must be able to run indefinitely without re-entry of any long term key. In addition, claimants and verifiers have a trusted authority, which consists of information about a trusted CA. That information is its: - name (this will appear in the "issuer" field in principal certificates), - public key (to use in verifying certificates issued by that CA), and - UID. Trusted authorities are used by principals to verify certificates for other principals' public keys. CAs are arranged in a hierarchy corresponding to the naming hierarchy, where each directory in the naming hierarchy is controlled by a single CA. Each CA certifies the CA of its parent directory, the CAs of each of its child directories, and optionally CAs elsewhere in the naming hierarchy (mainly to deal with the case where the directories up to a common ancestor lack CAs). Even though a principal has only a single CA as a trusted authority, it can securely obtain the public key of any principal in the namespace by "walking the CA hierarchy". 1.5.4 Transfer The DASS exchange of authentication information is illustrated in Figure 1-1. During the transfer phase, the DASS claimant sends an authentication token to the verifier. Authentication tokens are made by invoking the create_token primitive. The authentication token is Kaufman [Page 22]
RFC 1507 DASS September 1993 cryptographically protected and specified as a DASS data structure in ASN.1. The authentication token includes: - a ticket, - a DES authenticating key encrypted using the intended verifier's public key - one of the following: . if delegation is not being performed, a digital signature on the encrypted DES key using the delegation private key, or . if delegation is being performed, sending the delegation private key, DES encrypted using the DES authenticating key - an authenticator, which is a cryptographic checksum made using the DES authenticating key over a buffer containing . a timestamp . any application supplied "channel bindings". For example, addresses or other context information. The purpose of this field is to thwart substitution and replay attacks. - additional optional information concerning node authentication and context. As a side effect, after init_authentication_context, the caller receives a local authentication context, a data structure containing: - the DES key, and - if mutual authentication is being requested, the expected response. In order to construct an authentication token, the claimant needs to access the verifier's public key certificate from the Name Service (labeled CDC, for Certificate Distribution Center, in the figure). Note that while an authenticator can only be used once, it is permissible to re-establish the same local authentication context multiple times. That is, the ticket and DES key establishment components of the authentication token may have a relatively long lifetime. This permits a performance improvement in that repeated applications of public key operations can be alleviated if one caches authentication contexts, along with other components from a successfully used authentication token and the associated verified Kaufman [Page 23]
RFC 1507 DASS September 1993 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 Kaufman [Page 24]
RFC 1507 DASS September 1993 1.5.5 Verification Upon receipt of an authentication token, the verifier extracts the DES key using its verifier credentials, accesses the Name Service (labeled CDC for Certificate Distribution Center) to obtain the certificates needed to perform cryptographic checks on the incoming information, and verifies all of the signatures on the received certificates and the authentication token. Verification can result in creation of new claimant credentials if delegation is performed. As part of this process, verified authenticators are retained for a suitable timeout period. 1.5.6 Unenrolment This is the removal of information from the Name Service. The only other form of revocation supported by DASS is certificate timeout. Every certificate contains an expiration time (expected in ordinary use to be about a year from its signing date). DASS does not currently support the revocation lists in X.509. 2. Services Used Aside from operating system services needed to maintain its internal state, DASS relies on a global distributed database in which to store its certificates, a reliable source of time, and a source of random numbers for creating cryptographic keys. 2.1 Time Service DASS requires access to the current time in several of its algorithms. Some of its uses of time are security critical. In others, network synchronization of clocks is required. DASS does not, however, depend on having a single source of time which is both secure and tightly synchronized. The requirements on system provided time are: - For purposes of validating certificates and tickets, the system needs access to know the date and time accurate to within a few hours with no particular synchronization requirements. If this time is inaccurate, then valid requests may be rejected and expired messages may be accepted. Certificate expiration is a backup revocation mechanism, so this can only cause a security compromise in the event of multiple failures. In theory, this could be provided by having a local clock on every node accurate to within a few hours over the life of the product to provide this function. Kaufman [Page 25]
RFC 1507 DASS September 1993 If an insecure network time service is used to provide this time, there are theoretical security threats, but they are expected to be logistically impractical to exploit. - For purposes of detecting replay of authentication tokens, the system needs access to a strictly monotonic time source which is reasonably synchronized across the network (within a few minutes) for the system to work, but inaccuracy does not present a security threat except as noted below. It may constitute an availability threat because valid requests may be rejected. In order to get strict monotonicity in the presence of a rapid series of requests, time must be returned with high precision. There is no requirement for a high degree of accuracy. Inaccurate time could present a security threat in the following scenario: if a client's clock is made sufficiently fast that its tokens are rejected, someone harvesting those tokens from the wire could replay them later and impersonate the client. In some environments, this might be an easier threat than harvesting tokens and preventing their delivery. - For purposes of aging stale entries from caches, DASS requires reasonably accurate timing of intervals. To the extent that intervals are reported as shorter than the actually were, revocation of certificates from the naming service may not be as timely as it should be. 2.2 Random Numbers In order to generate keys, DASS needs a source of "cryptographic quality" random numbers. Cryptographic quality means that knowing any of the "random numbers" returned from a series and knowing all state information which is not protected, an attacker cannot predict any of the other numbers in the series. Hardware sources are ideal, but there are alternative techniques which may also be acceptable. A 56 bit "truly random" seed (say from a series of coin tosses) could be used as a DES key to encrypt an infinite length known text block in CBC mode to produce a pseudo-rand sequence provided the key and current point in the sequence were adequately protected. There is considerable controversy surrounding what constitutes cryptographic quality random numbers, and it is not a goal of this document to resolve it. 2.3 Naming Service DASS stores creates and uses "certificates" associated with every principal in the system, and encrypted credentials associated with most. This information is stored in an on-line service Kaufman [Page 26]
RFC 1507 DASS September 1993 associated with the principal being certified. The long term vision is for DASS to use an X.500 naming service, and DASS will from its inception authenticate X.500 names. To avoid a dependence on having an X.500 naming service available (and to gain the benefits of a "login agent" that controls password guessing), an alternative certificate distribution center protocol is also described. The specific requirements DASS places on the naming service are: - It must be highly available. A user's naming service entry must be available to any node where the user is to obtain services (or service will be denied). A server's naming service entry must be available from any node from which the service is to be invoked (or service will be denied). - It must be timely. The presence of "stale" information in the naming service may cause some problems. When a password changes, the old password may remain valid (and the new password invalid) to the extent the naming service provides stale information. When a user or server is added to the network, it will not be able to participate in authentication until the information added to the naming service is available at the node doing the authentication. In the unusual circumstance that a key changes, the entity whose key has changed will not be able to use the new key until the new certificate is uniformly available. - It must be secure with regard to certain specific properties. In general, the security of DASS protected applications does not depend on the security of the naming service. It is expected that the availability needs of the naming service will prevent it from being as secure as some applications need to be. There are two aspects of DASS security which do depend on the security of the naming service: timely revocation of certificates and protection of user secrets against dictionary based password guessing. DASS depends on the removal of certificates from the naming service in order to revoke them more quickly than waiting for them to time out. For this mechanism to provide any actual security, it must not be possible for a network entity to "impersonate" the naming service and the naming service must be able to enforce access controls which prevent a revoked certificate from being reinstated by an unauthorized entity. In the long run, it is expected that DASS itself will be used to secure the naming service, which presents certain potential recursion problems (to be addressed in the naming service design). If the naming service is not authenticated (as is expected in early Kaufman [Page 27]
RFC 1507 DASS September 1993 versions) attacks where a revoked certificate is "reinstated" through impersonation of the naming service are possible. The specific functions DASS requests of the naming service are simple: - Given an X.500 name, store a set of certificates associated with that name. - Given an X.500 name, retrieve the set of certificates associated with that name. - Given an X.500 name, store a set of encrypted credentials associated with that name. - Given and X.500 name, retrieve a set of encrypted credentials associated with that name. Implementation over a particular naming service may implement more specialized functions for reasons of efficiency. For example, the certificates associated with a name may be separated into several sets (child, parent, cross, self) so that only the relevant ones may be retrieved. In order that access to the naming service itself be secure, the protocols should be authenticated. Certificates should generally be readable without authentication in order to avoid recursion problems. Requests to read encrypted credentials should be specialized and should include proof of knowledge of the password in order that the naming service can audit and slow down false password guesses. The following sections describe the interfaces to specific naming services: 2.3.1 Interface to X.500 Certificates associated with a particular name are stored as attributes of the entry as specified in X.509. X.509 defines attributes appropriate for parent and cross certificates (CrossCertificatePair, CACertificate) for some principals; we will have to define a DASSUserPrincipal object class including these attributes in order to properly use them with ordinary users. Retrieval is via normal X.500 protocols. Certificates should be world readable and modifiable only by appropriate authorities. Encrypted credentials are stored with the entry of the principal under a yet to be defined attribute. The credentials should be encoded as specified in section 4. In the absence of extensions to the X.500 protocol to control password guessing, the encrypted Kaufman [Page 28]
RFC 1507 DASS September 1993 credentials should be world readable and updatable only by the named principal and other appropriate authorities. 2.3.2 Interface to CDC The CDC (Certificate Distribution Center) is a special purpose name server created to service DASS until an X.500 service is available in all of the environments where DASS needs to operate. The CDC uses a special purpose protocol to communicate with DASS clients. The protocol was designed for efficiency, simplicity, and security. CDCs use DASS as an authentication mechanism and to protect encrypted credentials from unaudited password guessing. Each DASS client maintains a list of CDCs and the portion of the namespace served by that CDC. Each directory has a master replica which is the only one which will accept updates. The CDCs maintain consistency with one another using protocols beyond the scope of this document. When a DASS client wishes to make a request of a CDC, it opens a TCP or DECnet connection to the CDC and sends an ASN.1 (BER) encoded request and receives a corresponding ASN.1 (BER) encoded response. Clients are expected to learn the IP or DECnet address and port number of the CDC supporting a particular name from a local configuration file. To maximize performance, the requests bundle what would be several requests if made in terms of requests for individual certificates. It is intended that all certificates needed for an authentication operation be retrievable with at most two CDC requests/responses (one to the CDC of the client and one to the CDC of the server). Documented here is the protocol a DASS client would use to retrieve certificates and credentials from a CDC and update a user password. This protocol does not provide for updates to the certificate and credential databases. Such updates must be supported for a practical system, but could be done either by extensions to this protocol or by local security mechanisms implemented on nodes supporting the CDC. Similarly, availability can be enhanced by replicating the CDC. Automating the replication of updates could be implemented by extensions to this protocol or by some other mechanism. This specification assumes that updates and replication are local matters solved by individual CA/CDC implementations. Requests and responses are encoded as follows: ReadPrinCertRequest This request asks the CDC to return the child certificates and selected incoming cross certificates for the specified object. The format of the request is: Kaufman [Page 29]
RFC 1507 DASS September 1993 ReadPrinCertRequest ::= [4] IMPLICIT SEQUENCE { flags [0] BIT STRING DEFAULT {}, index [1] IMPLICIT INTEGER DEFAULT 0, resolveFrom [2] Name OPTIONAL, principal Name, crossCertIssuers ListOfIssuers OPTIONAL } ListOfIssuers ::= SEQUENCE OF Name The first 24 bits of flags, if present, contain a protocol version number. Clients following this spec should place the value 2.0.0 in the three bytes. Servers following this spec should accept any value of the form 1.x.x or 2.x.x. flags bits beyond the first 24 are reserved for future use (should not be supplied by clients and should be ignored by servers). index is only used if the response exceeds the size of a single message; in that case, the query is repeated with index set to the value that was returned by ReadPrinCertResponse. resolveFrom and principal imply a set of entities for which certificates should be retrieved. resolveFrom (if present) must be an ancestor of principal and child certificates will be retrieved for principal and all names which are ancestors of principal but descendants of resolveFrom. The encoding of names is per X.500 and is specified in more detail in section 4. The CDC returns the certificates in order of the object they came from, parents before children. crossCertIssuers is a list of cross certifiers that would be believed in the context of this authentication. If supplied, the CDC may return a chain of certificates starting with one of the named crossCertIssuers and ending with the named principal. One of resolveFrom or crossCertIssuers must be present in any request; if both are present, the CDC may return either chain. ReadPrinCertResponse This is the response a CDC sends to a ReadPrinCertRequest. Its syntax is: ReadPrinCertResponse ::= [5] IMPLICIT SEQUENCE { status [0] IMPLICIT CDCstatus DEFAULT success, index [1] INTEGER OPTIONAL, resolveTo [2] Name OPTIONAL, certSequence [3] IMPLICIT CertSequence, indexInvalidator [4] OCTET STRING (SIZE(8)) OPTIONAL, flags [5] BIT STRING OPTIONAL } CertSequence ::= SEQUENCE OF Certificate Kaufman [Page 30]
RFC 1507 DASS September 1993 status indicates success or the cause of the failure. index if present indicates that the request could not be fully satisfied in a single request because of size limitations. The request should be repeated with this index supplied in the request to get more. resolveTo will be present if index is present and should be supplied in the request for more certificates. certSequence contains certificates found matching the search criteria. indexInvalidator may be present and indicates the version of the database being read. If a set of certificates is being read in multiple requests (because there were too many to return in a single message), the reader should check that the value for indexInvalidator is the same on each request. If it is not, the server may have skipped or duplicated some certificates. This field must not be present if the version number in the request was missing or version 1.x.x. The first 24 bits of flags, if present, indicate the protocol version number. Implementers of this version of the spec should supply 2.0.0 and should accept any version number of the form 1.x.x or 2.x.x. ReadOutgoingCertRequest This requests from the CDC a list of all parent and outgoing cross certificates for a specified object. A CDC is capable of storing cross certificates either with the subject or the issuer of the cross certificate. In response to this request, the CDC will return all parent and cross certificates stored with the issuer for the named principal and all of its ancestors. Its syntax is: ReadOutgoingCertRequest ::= [6] IMPLICIT SEQUENCE { flags [0] BIT STRING DEFAULT {}, index [1] IMPLICIT INTEGER DEFAULT 0, principal Name } The first 24 bits of flags is a protocol version number and should contain 2.0.0 for clients implementing this version of the spec. Servers implementing this version of the spec should accept any version number of the form 1.x.x or 2.x.x. The remaining bits are reserved for future use (they should not be supplied by clients and they should be ignored by servers). index is used for continuation (see ReadPrinCertRequest). Kaufman [Page 31]
RFC 1507 DASS September 1993 principal is the name for which certificates are requested. ReadOutgoingCertResponse This is the response to a ReadOutgoingCertRequest. Its syntax is: ReadOutgoingCertResponse::= [7] IMPLICIT SEQUENCE { status [0] IMPLICIT CDCStatus DEFAULT success, index [1] INTEGER OPTIONAL, certSequence [2] IMPLICIT CertSequence, indexInvalidator [3] OCTET STRING (SIZE(8)) OPTIONAL, flags [4] BIT STRING OPTIONAL } CertSequence ::= SEQUENCE OF Certificate status indicates success of the cause of failure of the operation. index is used for continuation; see ReadPrinCertRequest. certSequence is the list of parent and outgoing cross certificates. indexInvalidator is used for continuation; see ReadPrinCertResponse (the same rules apply with respect to version numbers). The first 24 bits of flags, if present, contain the protocol version number. Clients implementing this version of the spec should supply the value 2.0.0. Servers should accept any values of the form 1.x.x or 2.x.x. The remaining bits are reserved for future use (they should not be supplied by clients and should be ignored by servers). ReadCredentialRequest This request is made to retrieve an principal's encrypted credentials. To prevent unaudited password guessing, this structure includes an encrypted value that proves that the requester knows the password that will decrypt the structure. The syntax of the request is: ReadCredentialRequest ::= [2] IMPLICIT SEQUENCE { flags [0] BIT STRING DEFAULT {} principal Name, logindata [2] BIT STRING DEFAULT {}, token [3] BIT STRING OPTIONAL } Kaufman [Page 32]
RFC 1507 DASS September 1993 The first 24 bits of flags contains the version number of the protocol. The value 2.0.0 should be supplied. Any value of the form 1.x.x or 2.x.x should be accepted. Any additional bits are reserved for future use (should not be supplied by clients and should be ignored by servers). principal is the name of the principal for whom encrypted credentials are desired. logindata is an encrypted value. It may only be present if the version number is 2.0.0 or higher. It must be present to read credentials which are protected by the login agent functionality of the CDC. It is constructed as a single RSA block encrypted under the public key of the CDC. The public key of the CDC is learned by some local means. Possibilities include a local configuration file or by using DASS to read and verify a chain of certificates ending with the CDC [the CDC serving a directory should have its public key listed under a name consisting of the directory name with the RDN "CSS=X509"; the OID for the type CSS is]. The contents of the block are as follows: - The low order eight bytes contain a randomly generated DES key with the last byte of the DES key placed in the last byte of the RSA block. This DES key will be used by the CDC to encrypt the response. Key parity bits are ignored. - The next to last eight bytes contain a long Posix time with the integer time encoded as a byte string using big endian order. - The next eight bytes (from the end) contain a hash of the password. The algorithm for computing this hash is listed in section 4.4.2. The CDC never computes this hash; it simply compares the value it receives with the value associated with the credentials. - The next sixteen bytes (from the end) contain zero. - The remainder of the RSA block (which should be the same size as the public modulus of the CDC) contains a random number. The first byte should be chosen to be non-zero but so the value in the block does not exceed the RSA modulus. Servers should ignore these bits. This random number need not be of cryptographic strength, but should not be the same value for all encryptions. Repeating the DES key would be adequate. - The byte string thus constructed is encrypted using the RSA algorithm by treating the string of bytes as a "big endian" Kaufman [Page 33]
RFC 1507 DASS September 1993 integer and treating the integer result as "big endian" to make a string of bytes. token will not be present in the initial implementation but a space is reserved in case some future implementation wants to authenticate and audit the node from which a user is logging in. ReadCredentialProtectedResponse This is the second possible response to a ReadPrinLoginRequest. It is returned when the encrypted credentials are protected from password guessing by the CDC acting as a login agent. Its syntax is: ReadCredentialProtectedResponse::=[16] IMPLICIT SEQUENCE { status [0] IMPLICIT CDCStatus DEFAULT success, encryptedCredential [1] BIT STRING, flags [2] BIT STRING OPTIONAL } status indicates that the request succeeded or the cause of the failure. encryptedCredential contains the DASSPrivateKey structure (defined in section 4.1) encrypted under a DES key computed from the user's name and password as specified in section 4.4.2 and then reencrypted under the DES key provided in the ReadPrinLoginRequest. The first 24 bits of flags, if present, contains the version number of the protocol. Implementers of this version of the spec should supply 2.0.0 and should accept any version number of the form 2.x.x. Other bits are reserved for future use (they should not be supplied and they should be ignored). WriteCredentialRequest This is a request to update the encrypted credential structure. It is used when a user's key or password changes. The syntax of the request is: WriteCredentialRequest ::= [17] IMPLICIT SEQUENCE { flags [0] BIT STRING DEFAULT {}, authtoken [2] BIT STRING OPTIONAL, principal [3] Name, logindata [4] BIT STRING DEFAULT {}, furtherSensitiveStuff [5] BIT STRING } The first 24 bits of flags is a version number. Clients implementing Kaufman [Page 34]
RFC 1507 DASS September 1993 this version of the spec should supply 2.0.0. Servers should accept any value of the form 2.x.x. Additional bits are reserved for future use (clients should not supply them and servers should ignore them). token, if present, authenticates the entity making the request. A request will be accepted either from a principal proving knowledge of the password (see logindata below) or a principal presenting a token in this field and satisfying the authorization policy of the CDC. This field need not be present if logindata includes the hash2 of the password (anyone knowing the old password may set a new one). principal is the name of the object for which encrypted credentials should be updated. logindata is encrypted as in ReadPrinLoginRequest. It proves that the requester knows the old password of the principal to be updated (unless the token supplied is from the user's CA) and includes the key which encrypts furtherSensitiveStuff. furtherSensitiveStuff is an encrypted field constructed as follows: - The first eight bytes consist of the hash2 defined in section 4.4.2 with the last byte of the hash2 value stored first. The CDC stores this value and compares it with the values supplied in future requests of ReadCredentialRequest and WriteCredentialRequest. - The next (variable number of) bytes contains a DASSPrivateKey structure (defined in section 4.1). This is the new credential structure that will be returned by the CDC on future ReadCredentialRequests. - The result is padded with zero bytes to a multiple of eight bytes. - The entire padded string is encrypted using the key from logindata or token using DES in CBC mode with zero IV. the new eight byte "hash2" defined in section 4.4.2 concatenated with the DASSPrivateKey structure encrypted under the new "hash1" all encrypted under the DES key included in logindata. HereIsStatus This is the response message to ill-formed requests and requests that only return a status and no data. It's syntax is: Kaufman [Page 35]
RFC 1507 DASS September 1993
RFC 1507 DASS September 1993 B.3 Syntax The GSSAPI specification recommends the following ASN.1 encoding for the tokens and messages generated through the GSSAPI: --optional top-level token definitions to frame -- different mechanisms GSSAPI DEFINITIONS ::= BEGIN MechType ::= OBJECT IDENTIFIER -- data structure definitions ContextToken ::= -- option indication (delegation, etc.) indicated -- within mechanism-specific token [APPLICATION 0] IMPLICIT SEQUENCE { thisMech MechType, responseExpected BOOLEAN, innerContextToken ANY DEFINED BY MechType -- contents mechanism-specific } PerMsgToken ::= -- as emitted by GSS_Sign and processed by -- GSS_Verify [APPLICATION 1] IMPLICIT SEQUENCE { thisMech MechType, innerMsgToken ANY DEFINED BY MechType -- contents mechanism-specific } SealedMessage ::= -- as emitted by GSS_Seal and processed by -- GSS_Unseal [APPLICATION 2] IMPLICIT SEQUENCE { sealingToken PERMSGTOKEN, confFlag BOOLEAN, userData OCTET STRING -- encrypted if confFlag TRUE } The object identifier for the DASS MechType is The innerContextToken of a token is a DASS token or mutual authentication token. The innerMsgToken is a null string in the case where the message is encrypted and the token is included as part of a SealedMessage. Kaufman [Page 110]
RFC 1507 DASS September 1993 Otherwise, it is an eight octet sequence computed as the CBC residue computed using a key and string of bytes defined as follows: - Pad the message provided by the application with 1-8 bytes of pad to produce a string whose length is a multiple of 8 octets. Each pad byte has a value equal to the number of pad bytes. - Compute the key by taking the timestamp of the association (two four byte integers laid out in big endian order with the most significant integer first), complementing the high order bit (to avoid aliasing with mutual authenticators), and encrypting the block in ECB mode with the shared key of the association. The userData field of a SealedMessage is exactly the application provided byte string if confFlag=FALSE. Otherwise, it is the application supplied message encrypted as follows: - Pad the message provided by the application with 1-8 bytes of pad to produce a string whose length = 4 (mod 8). Each pad byte has a value equal to the number of pad bytes. - Append a four byte CRC32 computed over the message + pad. - Compute a key by taking the timestamp of the association (two four byte integers laid out in big endian order with the most significant integer first), complementing the high order bit (to avoid aliasing with mutual authenticators), and encrypting the block in ECB mode with the shared key of the association. - Encrypt the message + pad + CRC32 using CBC and the key computed in the previous step. A note of the logic behind the above: - Because the shared key of an association may be reused by many associations between the same pair of principals, it is necessary to bind the association timestamp into the messages somehow to prevent messages from a previous association being replayed into a new sequence. The technique above of generating an association key accomplishes this and has a side benefit. An implementation may with to keep the long term keys out of the hands of applications for purposes of confinement but may wish to put the encryption associated with an association in process context for reasons of performance. Defining an association key makes that possible. Kaufman [Page 111]
RFC 1507 DASS September 1993 - The reason that the association specific key is not specified as the output of Create_token and Accept_token is that the DCE RPC security implementation requires that a series of associations between two principals always have the same key and we did not want to have to support a different interface in that application. - The CRC32 after pad constitutes a cheap integrity check when data is encrypted. - The fact that padding is done differently for encrypted and signed messages means that there are no threats related to sending the same message encrypted and unencrypted and using the last block of the encrypted message as a signature on the unencrypted one. Annex C Imported ASN.1 definitions This annex contains extracts from the ASN.1 description of X.509 and X.500 definitions referenced by the DASS ASN.1 definitions. CCITT DEFINITIONS ::= BEGIN joint-iso-ccitt OBJECT IDENTIFIER ::= {2} ds OBJECT IDENTIFIER ::= {joint-iso-ccitt 5} algorithm OBJECT IDENTIFIER ::= {ds 8} iso OBJECT IDENTIFIER ::= {1} identified- organization OBJECT IDENTIFIER ::= {iso 3} ecma OBJECT IDENTIFIER ::= {identified-organization 12} digital OBJECT IDENTIFIER ::= { ecma 1011 } -- X.501 definitions AttributeType ::= OBJECT IDENTIFIER AttributeValue ::= ANY -- useful ones are -- OCTET STRING , -- PrintableString , -- NumericString , -- T61String , -- VisibleString AttributeValueAssertion ::= SEQUENCE {AttributeType, AttributeValue} Name ::= CHOICE {-- only one possibility for now -- RDNSequence} Kaufman [Page 112]
RFC 1507 DASS September 1993 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName DistinguishedName ::= RDNSequence RelativeDistinguishedName ::= SET OF AttributeValueAssertion -- X.509 definitions Certificate ::= SIGNED SEQUENCE { version [0] Version DEFAULT 1988 , serialNumber SerialNumber , signature AlgorithmIdentifier , issuer Name, valid Validity, subject Name, subjectPublicKey SubjectPublicKeyInfo } Version ::= INTEGER { 1988(0)} SerialNumber ::= INTEGER Validity ::= SEQUENCE{ notBefore UTCTime, notAfter UTCTime} SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier , subjectPublicKey BIT STRING } AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER , parameters ANY DEFINED BY algorithm OPTIONAL} ALGORITHM MACRO BEGIN TYPE NOTATION ::= "PARAMETER" type VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) END -- of ALGORITHM ENCRYPTED MACRO BEGIN TYPE NOTATION ::=type(ToBeEnciphered) VALUE NOTATION ::= value(VALUE BIT STRING) -- the value of the bit string is generated by -- taking the octets which form the complete -- encoding (using the ASN.1 Basic Encoding Rules) -- of the value of the ToBeEnciphered type and -- applying an encipherment procedure to those octets-- END SIGNED MACRO ::= BEGIN TYPE NOTATION ::= type (ToBeSigned) VALUE NOTATION ::= value(VALUE SEQUENCE{ ToBeSigned, AlgorithIdentifier, -- of the algorithm used to generate -- the signature ENCRYPTED OCTET STRING -- where the octet string is the result Kaufman [Page 113]
RFC 1507 DASS September 1993 -- of the hashing of the value of "ToBeSigned" END -- of SIGNED SIGNATURE MACRO ::= BEGIN TYPE NOTATION ::= type(OfSignature) VALUE NOTATION ::= value(VALUE SEQUENCE{ AlgorithmIdentifier, -- of the algorithm used to compute the signature ENCRYPTED OCTET STRING -- where the octet string is a function (e.g., a -- compressed or hashed version) of the value -- "OfSignature", which may include the identifier -- of the algorithm used to compute -- the signature--} ) END -- of SIGNATURE -- X.509 Annex H (not part of the standard) encryptionAlgorithm OBJECT IDENTIFIER ::= {algorithm 1} rsa ALGORITHM PARAMETER KeySize ::= {encryptionAlgorithm 1} KeySize ::= INTEGER END Glossary authentication The process of determining the identity (usually the name) of the other party in some communication exchange. authentication context Cached information used during a particular instance of authentication and including a shared symmetric (DES) key as well as components of the authentication token conveyed during establishment of this context. authentication token Information conveyed during a strong authentication exchange that can be used to authenticate its sender. An authentication token can, but is not necessarily limited to, include the claimant identity and ticket, as well as signed and encrypted secret key exchange messages conveying a secret key to be used in future cryptographic operations. An Kaufman [Page 114]
RFC 1507 DASS September 1993 authentication token names a particular protocol data structure component. authorization The process of determining the rights associated with a particular principal. certificate The public key of a particular principal, together with some other information relating to the names of the principal and the certifying authority, rendered unforgeable by encipherment with the private key of the certification authority that issued it. certification authority An authority trusted by one or more principals to create and assign certificates. claimant The party that initiates the authentication process. In the DASS architecture, claimants possess credentials which include their identity, authenticating private key and a ticket certifying their authenticating public key. credentials Information "state" required by principals in order to for them to authenticate. Credentials may contain information used to initiate the authentication process (claimant information), information used to respond to an authentication request (verifier information), and cached information useful in improving performance. cryptographic checksum Information which is derived by performing a cryptographic transformation on the data unit. This information can be used by the receiver to verify the authenticity of data passed in cleartext decipher To reverse the effects of encipherment and render a message comprehensible by use of a cryptographic key. delegation The granting of temporary credentials that allow a process to act on behalf of a principal. Kaufman [Page 115]
RFC 1507 DASS September 1993 delegation key A short term public/private key pair used by a claimant to act on behalf of a principal for a bounded period. The delegation public key appears in the ticket, whereas the delegation private key is used to sign secret key exchange messages. DES Data Encryption Standard: a symmetric (secret key) encryption algorithm used by DASS. An alternate encryption algorithm could be substituted with little or no disruption to the architecture. DES key A 56-bit secret quantity used as a parameter to the DES encryption algorithm. digital signature A value computed from a block of data and a key which could only be computed by someone knowing the key. A digital signature computed with a secret key can only be verified by someone knowing that secret key. A digital signature computed with a private key can be verified by anyone knowing the corresponding public key. encipher To render incomprehensible except to the holder of a particular key. If you encipher with a secret key, only the holder of the same secret can decipher the message. If you encipher with a public key, only the holder of the corresponding private key can decipher it. initial trust certificate A certificate signed by a principal for its own use which states the name and public key of a trusted authority. global user name A hierarchical name for a user which is unique within the entire domain of discussion (typically the network). local user name A simple (non-hierarchical) name by which a user is known within a limited context such as on a single computer. Kaufman [Page 116]
RFC 1507 DASS September 1993 principal Abstract entity which can be authenticated by name. In DASS there are user principals and server principals. private key Cryptographic key used in asymmetric (public key) cryptography to decrypt and/or sign messages. In asymmetric cryptography, knowing the encryption key is independent of knowing the decryption key. The decryption (or signing) private key cannot be derived from the encrypting (or verifying) public key. proxy A mapping from an external name to a local account name for purposes of establishing a set of local access rights. Note that this differs from the definition in ECMA TR/46. public key Cryptographic key used in asymmetric cryptography to encrypt messages and/or verify signatures. RSA The Rivest-Shamir-Adelman public key cryptosystem based on modular exponentiation where the modulus is the product of two large primes. When the term RSA key is used, it should be clear from context whether the public key, the private key, or the public/private pair is intended. secret key Cryptographic key used in symmetric cryptography to encrypt, sign, decrypt and verify messages. In symmetric cryptography, knowledge of the decryption key implies knowledge of the encryption key, and vice-versa. sign A process which takes a piece of data and a key and produces a digital signature which can only be calculated by someone with the key. The holder of a corresponding key can verify the signature. source The initiator of an authentication exchange. strong authentication Authentication by means of cryptographically derived authentication tokens and credentials. The actual working definition is closer to that of "zero knowledge" proof: Kaufman [Page 117]
RFC 1507 DASS September 1993 authentication so as to not reveal any information usable by either the verifier, or by an eavesdropping third party, to further their potential ability to impersonate the claimant. target The intended second party (other than the source) to an authentication exchange. ticket A data structure certifying an authenticating (public) key by virtue of being signed by a user principal using their (long term) private key. The ticket also includes the UID of the principal. trusted authority The public key, name and UID of a certification authority trusted in some context to certify the public keys of other principals. UID A 128 bit unique identifier produced according to OSF standard specifications. user key A "long term" RSA key whose private portion authenticates its holder as having the access rights of a particular person. verify To cryptographically process a piece of data and a digital signature to determine that the holder of a particular key signed the data. verifier The party who will perform the operations necessary to verify the claimed identity of a claimant. Kaufman [Page 118]
RFC 1507 DASS September 1993

Back to RFC index





Register domain name and transfer | Cheap webhosting service | Domain name registration