OSF DCE SIG M. Gasser (DEC) Request For Comments: 8.0 July 1992 DCE SIG SECURITY REQUIREMENTS 1. INTRODUCTION The DCE Security Working Group, a joint subgroup of the DCE SIG and Security SIG, proposed and voted on a set of requirements for DCE security extensions. This RFC describes the items, the resultant voting process, and provides some analysis. Initially a laundry list of requirements was proposed by individuals; all suggestions were accepted. Then the precise explanation of each requirement was worked out in committee, which took a very long time. Finally, a vote was taken among the working group members, one vendor/one vote, for the priority of each requirement for DCE 1.1 and DCE 2.0. Along the way, a number of items were dropped from consideration. In the sections that form the main body of this document, the "official" statement of each requirement is given, as agreed to by the working group. The subsequent explanatory material is the present author's unofficial elaboration, as an aid to the reader. The identification code scheme (indicated by curly brackets), and the classification of items into groups, were done after the fact and are artificial; they are retained for internal reference purposes, but each item should be understood to stand alone. 2. AUTHORIZATION 2.1. {A1} Authorization Based on Delegation REQT: Given a delegation model that permits the server to know which principals were involved in a delegated request, build an authorization model that permits the server to enforce an authorization decision based on those identities. Extend the authorization mechanism to allow an administrator (e.g., the ACL writer) to specify permitted delegates in a practical way. The idea is fundamentally to permit the delegates (when or if delegation is supported in DCE) to be named in the ACL. Gasser Page 1 DCE-RFC 8.0 DCE SIG Security Requirements July 1992 2.2. {A2} Authorization Based on Style of Authentication REQT: Permit a server to base authorization on the method by which the user logged in without changing the authorization model. "Authentication style" refers to the use of various technologies such as passwords, smart cards, biometrics, etc. A vote for this requirement explicitly prohibits a scheme where the ACL writer can specify an authentication style on the ACL, as it was felt that the ACL writer would not generally have enough information to make a useful decision and any such scheme would be too complex to use. One proposed method for implementing this without impacting any ACL model is to assign the user to different groups depending on the authentication method used. 2.3. {A3} Authorization Based on Capabilities REQT: Permit a server to control access based on the client's presentation of and verifiable legitimate possession of an unforgeable capability designating permitted rights to the information. The capability model referred to here is one in which the client obtains, prior to accessing a server, a kind of "ticket" for some specific information (e.g., a specific file or set of them). This ticket could be in an extended PAC or separately transmitted. A server receiving and verifying such a ticket should not need to make further access control checks based on the client's identity or privileges (although it is permitted to). In principal, capabilities provide a great deal of flexibility for access control and may not be very difficult to implement within the DCE framework. However there is some controversy as to whether this flexibility can be managed in a practical manner. 2.4. {A4} Authorization Based on Location REQT: Extend the authorization mechanism to permit restrictions based on the location of the user or delegates. The server must be able to verify the locations. Location may be encoded as the name of the system into which the user logged in, but might more usefully be represented as the name of a group of systems or another orthogonal naming scheme. A vote for this requirement neither requires nor prohibits the location to be specified on ACLs. Gasser Page 2 DCE-RFC 8.0 DCE SIG Security Requirements July 1992 2.5. {A5} Anonymous Access REQT: Permit an environment whereby a server can verify a client's right to access information without the server's gaining knowledge of the client's identity but with the possibility of maintaining individual accountability and auditability. The term "identity" in this requirement refers to the "individual identity" that uniquely isolates the individual user, not group identities that pertain to a number of individuals. Authorization in such a case would be based on the client's other attributes in the PAC, rather than on the client's individual identity. The accountability requirement implies an approach where the server receives the client's individual identity in a sealed form that the server cannot decipher, but which the server can write to an audit log for subsequent retrieval by some trusted authority. 2.6. {A7} Authorization Based on Security Attributes REQT: All security attributes of the user and delegates that the server can verify (obtained either from the client or by access to other information) should be useful as input to an authorization decision. The API should hide from the server application, as much as possible, the detailed syntax and semantics of this information. Authorization services should provide abstractions to track changes to security attributes of users in a way that is opaque to server applications. In DCE today servers grant access based on the principal name and group memberships, which servers can obtain in a verified manner from a PAC that the server verifies. In the future, as other attributes are added to the PAC or verified by the server through another mechanism (e.g., by querying a third party), a vote for this requirement is a vote to enhance the authorization services to permit access to be based on these attributes. There is also a strong statement that the authorization API must be such that applications should not necessarily have to worry about the nature of these attributes. For example, it should be possible to add in the future a new user attribute called "clearance" and an ACL tag of "minimum_clearance", and existing applications that use the DCE ACL services should continue to work on objects with these new ACL entries. The group deferred voting on this item as it was deemed too confusing and would require long discussion. Gasser Page 3 DCE-RFC 8.0 DCE SIG Security Requirements July 1992 2.7. {A8} Other Security Attributes REQT: Through an extensible mechanism, permit the server to obtain from the client verifiable security attributes of the user other than principal or group memberships. This requirement is a prerequisite to {A7}. Examples of new attributes that might be supported are clearance and role. 2.8. {A9} Mandatory Access Controls (Labeling) REQT: Transmit labels associated with client principals and processes for optional enforcement by a server. Provide labels on information against which the client labels can be compared. This is traditional mandatory labeling and label checking but without a requirement for NCSC or ITSEC evaluatability. Note the contrast with item {P7}. The group decided to postpone a vote on this requirement. 3. DELEGATION 3.1. {D1} Full Delegation REQT: Permit a client to explicitly specify that its current access rights should be transferred to a server, so that the server can access remote resources using the client's rights. Delegation should be available through all authentication mechanisms and APIs, including RPC. It must be possible for the user to control whether or not delegation takes place. In this scheme, the delegate is permitted to fully impersonate the user (for some period of time), and this delegation should be transferable through RPC and any other authentication protocol. For any delegation scheme, there is a strong requirement that the user should be able to specify that delegation must not happen. 3.2. {D2} Delegation with Restrictions REQT: Where delegation is specified by a client, permit the client to restrict delegated rights in some useful fashion to be a subset of those rights currently possessed by the client. This requirement does not necessarily imply extensions to the delegation mechanism. An acceptable implementation is one where the client can restrict its current rights (as in DCE today), and then delegate all of its current rights. Gasser Page 4 DCE-RFC 8.0 DCE SIG Security Requirements July 1992 3.3. {D3} User-to-User Authentication REQT: A server without access to a long term key should be able to authenticate itself. For example, servers that do not have long term keys are those activated on diskless nodes by users who log into them. This requirement is one that permits a user's process to act as a server. 3.4. {D4} Integrity Protection of Requests REQT: Provide a service that permits a client to protect a request in a way that a server can detect if the request was modified by a delegate. One implementation of this would sign (or encrypt) the client's request under a key specified in the PAC, thereby preventing a delegate from modifying the request in an undetectable manner. For the purposes of such "locked" requests, the delegate is performing mostly a routing function. 3.5. {D5} Integrity Protection of Responses REQT: Provide a service that permits a server to protect a response in a way that a client can detect if the request was modified by a delegate. 4. EXTENSIONS TO OTHER APPLICATIONS AND MECHANISMS 4.1. {E1a} Secure Remote Login REQT: Remote login should be secured using DCE mechanisms and offered as part of the DCE package. Candidate applications that fall into this category include telnet, rlogin and terminal emulation. 4.2. {E1b} Secure Remote File Transfer REQT: Remote file copy should be secured using DCE mechanisms and offered as part of the DCE package. This category includes ftp and rcp. 4.3. {E2} Security API Through Protocols Other Than RPC REQT: Applications that choose not to use RPC for communications should have the ability to make use of all the DCE authentication and communications security mechanisms through a portable API. Gasser Page 5 DCE-RFC 8.0 DCE SIG Security Requirements July 1992 This is the GSS API requirement. 4.4. {E3} Other User Authentication Methods REQT: Provide interfaces that permit arbitrary site-selected user authentication methods, including smart cards and biometric devices. 4.5. {E4} More Options for Communications Security REQT: Permit site or application-selectable options for protecting communications such as choice of encryption algorithms. Note that DCE today already contains hooks that to identify alternative encryption algorithms in the protocols. This item refers to items such as the provision of additional algorithms, registration of multiple algorithms, additional flexibility in the choice of algorithms by applications, and negotiation in the handling of multiple algorithms. 4.6. {E5} Application Security Services REQT: Permit an application to gain access to enough of the underlying DCE security infrastructure to provide security services such as digital signatures, data confidentiality and nonrepudiation without the need for the application to implement another user and system registration facility and authentication mechanism. Many application-level security mechanisms, for applications such as privacy enhanced mail and electronic document interchange, require facilities to permit registration of users, installation of user secrets (passwords or private keys), and check of user names in order to make authorization or authentication decisions. These facilities are conceptually similar to those already provided by DCE but differ in most details. This is a requirement to install services in DCE to access the existing DCE mechanisms so that applications will not need to implement their own. It may also require augmenting the DCE facilities to better service varying needs of applications. (See requirements {R3} and {R4} for specific applications to be supported.) 4.7. {E7} Algorithms REQT: Permit independent selection of algorithms for confidentiality and integrity. The requirement is that, in the case where messages are protected with both confidentiality and integrity, there be independent selection of the algorithms used for the two mechanisms. Gasser Page 6 DCE-RFC 8.0 DCE SIG Security Requirements July 1992 5. IDENTITIES AND GROUPS 5.1. {I1} Global Groups REQT: Permit the ability of a group to include members in any cell while retaining the shorthand, accountability and auditing capabilities of current DCE groups. This requirement expresses the sentiment that groups may be defined in the server's cell, or in another cell that is neither the server's nor the client's. 5.2. {I2} Preserve Rights When Principal Changes Cell REQT: It should be possible to set up an environment whereby a user registered in a cell does not necessarily lose access to everything when changing registration to another cell. Given the facts that a user identity consists of a single cell UUID and user UUID, that ACLs contain the client's cell UUID, and that there is no easy way to find and then change all the ACLs in all remote cells on which a given user is listed, a user who moves to a different cell and authenticates himself under that new UUID will lose access to all files protected by DCE ACLs. Satisfying this requirement to retain access requires either the client's PAC to name all the client's old identities, or the server to support or interrogate a facility that maps old names on ACLs to new names. 6. ATTRIBUTES: PERFORMANCE, ROBUSTNESS, EXTENSIBILITY, INTEGRATION, STANDARDS 6.1. {P4} Recovery from Security Compromise REQT: After a detected security compromise, it must be possible to continue operating with an acceptable level of security and functionality. What is considered "acceptable" should be configurable by the security administration. An example of one of the most serious compromises is disclosure of the secret key of a cell's privilege server. A less serious compromise is disclosure of one user's password. DCE must recognize that commercial requirements vary considerably -- some organizations want to shut down completely when a compromise is detected, and others are willing to operate completely insecurely, if necessary to keep the business running. Therefore, a configurable range of emergency modes of operation should be provided. Note that this item does not place any requirement on the ability to detect a security compromise. Gasser Page 7 DCE-RFC 8.0 DCE SIG Security Requirements July 1992 6.2. {P5} Detection of Denial of Service REQT: Maximize the ability to detect and diagnose denial of service attacks. 6.3. {P6} Algorithms for Security Protocol Messages REQT: Retain flexibility in the choice of algorithms and techniques for protecting messages in the security protocol. In contrast to item {E7}, this item refers to the ability to select algorithms to protect the messages within the security protocols as well as algorithms to protect application messages. 6.4. {P7} B1 Portability REQT: DCE must be portable to platforms implementing B1 semantics with minimal effect on the accreditation of those systems. For example, there is some doubt that running DCE on a B1 version of OSF/1 is possible without dismantling some of the B1 security mechanisms. A common type of problem is when multiple processes need read and write access to the same file or other "named object". Under B1 rules, those process would be restricted to running at the same security level, possibly impacting practical use of DCE. Note that this is not a requirement for a B1 version of DCE. The ability to evaluate DCE as a trusted network at B1 or even C2, and the desirability of doing it, are highly controversial, and such requirements were not even offered up for a vote. 6.5. {P8} C2 Portability REQT: DCE must be portable to platforms implementing C2 semantics with minimal effect on the accreditation of those systems. An example of difficulty in running on a C2 system might be the need to remove passwords from /etc/passwd, thereby breaking applications that depend on passwords stored there. This is not a requirement for a C2 version of DCE. 6.6. {P9} ITSEC Evaluation REQT: DCE should not preclude evaluation to ITSEC level E3. A vote for this item expresses a feeling that ITSEC E3 evaluation of DCE is both practical and desirable, though it does not require an evaluation to take place. There is no corresponding requirement for TCSEC or TNI evaluation of DCE. Gasser Page 8 DCE-RFC 8.0 DCE SIG Security Requirements July 1992 6.7. {P10a} OS Integration REQT: Integrate DCE with certification/registration environments of other operating systems. This includes a generic ability to centralize registry databases for multiple systems, to permit flexibility in storing OS-specific user attributes in the registry, and to permit adjusting the frequency of registry updates based on local system needs. This is an extension to DCE to make it more portable to environments supporting other than Unix-based hosts. 6.8. {P10b} Network Interoperation REQT: Interoperate with other network security mechanisms. This expresses a general requirement that there are non-DCE environments with which DCE systems must securely interoperate, but the decision as to specifically which other environments those are is left open. An obvious candidate for interoperability, and one relatively easy to provide, is Athena Kerberos V5. A strong vote for this requirement would likely spawn an effort for an interoperability study. 6.9. {P14} Defaults REQT: Permit establishment of an environment whereby an application not otherwise interested in security can make maximum use of security features as configured by an administrator. In designing APIs to support security, it should be possible for an application to choose (or automatically use) administrator-configured defaults wherever practical, as most applications, especially the client side of applications, have little basis on which to make a rational security-relevant decision. For example, one default configured by an administrator or user might be whether or not to delegate on outbound RPC calls. To enable this capability, the RPC delegation mechanism should allow an application to specify "default" as a delegation option. 7. INFRASTRUCTURE 7.1. {R1} Registry and Naming Convergence REQT: [Definition deferred until we find out the results of the naming working group.] Gasser Page 9 DCE-RFC 8.0 DCE SIG Security Requirements July 1992 7.2. {R2} Trust Relationships REQT: Implement some kind of trust relationship between cells so that it is not necessary for all potentially interacting cells to directly communicate in advance. There should be at least one default implied relationship (e.g., a hierarchy based on names) throughout DCE to minimize the number of explicit trust relationships that a manager of a new cell must specify. In addition, a security manager should have the ability to establish additional explicit trust relationships within a cell that override or augment the default relationships. This requirement was created mostly for management ease in an environment of many cells. It is unlikely that a security manager of a cell can make a rational decision as to which authorities to trust for all possible remote cells with which the users and servers in his cell need to communicate. It is unlikely that security manager will even know, in advance, what those cells are. Therefore, some well- defined (and of course, secure) default relationship needs to be consistently supported throughout the environment. On the other hand, there is also the requirement that security managers cognizant of trust relationships be able to override the default where they have direct pairwise agreements with each other. 7.3. {R3} Privacy-Enhanced Mail Integration REQT: Provide some integration between the DCE registry and the PEM infrastructure for registering users to minimize the additional work system managers and users have to do to participate in both environments, with the caveat that such integration should not be mandatory for those administrations choosing to keep them separate. This item is similar to the generic requirement in {E5}, except it relates to PEM in particular. An example of integration might be the storage of PEM certificates and/or corresponding private keys in the registry, or the automatic initiation of a certificate creation process for PEM as a user is registered in DCE. Desirable points of integration are left to further study. 7.4. {R4} X.400 Security Integration REQT: Ditto for X.400 7.5. {R5a} X.509 Certificates for Users REQT: Make use of X.509 user certificates where available and desired, to minimize the additional work system managers and users have to do to participate in both an X.500 and DCE environment. This may, but does not necessarily, include the Gasser Page 10 DCE-RFC 8.0 DCE SIG Security Requirements July 1992 ability to use X.509 for user authentication. X.509 is used by both PEM and X.500 (and the latter is used in X.400), so this item can be seen as an enabler for the extension of DCE to support of those services. An X.509 capability in DCE, even without PEM or X.400 support, may be useful in that vendors could provide the added value in a manner that is interoperable with other implementations. 7.6. {R5b} X.509 Certificates for Servers REQT: Similarly, permit servers to be registered with X.500 names and X.509 certificates. 7.7. {R6} Permit Use of Offline Security Servers REQT: It should be possible to configure an environment whereby a user can obtain all of the functionality and security of DCE without the need for either the client or server to access an online security server, except for those functions that fundamentally cannot be provided by an offline security mechanism (e.g., instantaneous revocation and nonrepudiation). In an environment not employing online security servers for authentication, the client should have the ability to restrict rights on delegation (see requirement {D2}) without interaction with an online security server. The motivation for this requirement is to increase security and simplify administration by avoiding the need to replicate and distribute (for reliability and availability) security servers such as PasswdEtc that contain all the keys to the cell. Satisfying this requirement requires public key cryptography so that clients and servers can authenticate each other and establish shared traffic keys without access to a trusted key distribution server. 7.8. {R7} Pull Model REQT: Permit an environment where a server can obtain and verify all of the user's security attributes relevant to an authorization decision without action by or cooperation of any of the clients or delegates. A vote for this item is a statement that there will be important cases where the client (more precisely, the user, the workstation or the user's privilege server) does not necessarily know, at the time a PAC is created, all the privileges (especially group memberships) that will be necessary to satisfy a subsequent access request. This requirement becomes much more relevant if DCE is extended to permit groups to name members outside their cell, as there is no way for any system to create a PAC naming all groups of which the user is a member. Since the server knows exactly what attributes are required Gasser Page 11 DCE-RFC 8.0 DCE SIG Security Requirements July 1992 to satisfy a request, a vote for this item permits an option whereby the server can verify the user's attributes even if the user does not supply them. 8. AUDITING 8.1. {T1} Local Auditing REQT: Record security-relevant DCE events on the local system. 8.2. {T2} Remote Auditing REQT: Record security-relevant events on remote centralized audit systems. 9. MISCELLANEOUS 9.1. {X1} Loading and Booting Security REQT: Provide a interfaces and an infrastructure whereby it is possible for a user to have increased confidence that he is interacting with legitimate software on his node, free from Trojan horses and viruses. This includes mechanisms permitting the hardware to verify the booted image on a diskless node, as well as the operating system being able to detect corruption of applications software. To the extent possible, this infrastructure should be integrated with the existing DCE registration infrastructure. Providing secure booting of systems requires both hardware and software cooperation. To boot securely, a workstation (e.g., the boot ROM) must verify the integrity of a software image it receives before being willing to execute it. Similarly, for secure loading of applications (e.g., at the time a Unix process calls exec()), the operating system must be able to verify the integrity of the executable file. While major portions of the solution to this problem are outside the scope of DCE, DCE can provide an important part of the management infrastructure and support tools that allow vendors (or a subsequent OSF offering) to provide the full service in an interoperable way. 9.2. {X2} Limit Password Dictionary Attacks REQT: A site or cell should have the option to configure a mechanism that prevents dictionary attacks on poorly chosen passwords by wiretappers or nodes masquerading as legitimate clients. A tool to avoid picking bad passwords is not by itself an adequate solution. Gasser Page 12 DCE-RFC 8.0 DCE SIG Security Requirements July 1992 The Kerberos protocol used in DCE returns recognizable messages (e.g., the TGT) encrypted only by the user's password, which is subject to capture and analysis. Satisfying this requirement requires a change to the Kerberos protocol or use of an intermediary to communicate with the Kerberos server that is trusted not to guess passwords. Public key techniques are useful in simplifying the solution to this problem. 10. PROPOSED REQUIREMENTS REMOVED FROM LIST The following requirements were initially proposed by at least one individual from the working group, but were since unanimously deleted for the reasons given. 10.1. {A6} Authority Identity (DELETED) REQT: Provide functions that permit authorization to be determined based on the identity of the user's authority or authorities (trusted registry) instead of the user's identity. A vote for this requirement is a vote for a scheme whereby the server has the option of looking only at the authority's identity, plus the attributes that the authority claims for the client, in order to evaluate access. It is similar to {A5} in that the client's individual identity is not relevant to the access control decision, but unlike {A5} does not require the client's identity to be hidden from the server. The group decided not to vote on this as a separate item, as it is viewed to be subsumed by item {R2}. That is, DCE already provides the ability for an ACL to list "any principal in a cell", and if the only types of authorities supported are those for the entire cell, then trusting any principal in a cell is semantically equivalent to trusting the authority for the cell. Therefore, the only new requirement this imposes is a way of deciding who the trusted authority is for the cell. 10.2. {E6} Interoperability with Selected Non-DCE Systems (DELETED) REQT: Consider interoperability with popular non-DCE environments such as PC LANs. This proposed requirement was considered out of scope for DCE. 10.3. {P1} Performance (DELETED) REQT: Authentication and authorization should not significantly degrade access. Performance degradation due to communication security should be minimized. Gasser Page 13 DCE-RFC 8.0 DCE SIG Security Requirements July 1992 This item was deleted because good performance is a generally accepted principal for any software engineering effort and need not be spelled out explicitly. 10.4. {P2} Robustness to Prevent Denial-of-Service (DELETED) REQT: Enabling of security should not result in a significantly increased risk of denial of service, either due to bugs, random environmental events, or malicious attacks. This item was deleted for reasons similar to {P1}. 10.5. {P3} Interoperation with Operating System Security (DELETED) This item is subsumed in {P10a}. 10.6. {P11} Interoperability Among All DCE Variants (DELETED) Deleted because this requirement is not unique to security. 10.7. {P12} Extensibility Mechanisms for Future DCE Versions (DELETED) Deleted because this requirement is not unique to security, and in any case it is good software engineering. 10.8. {P13} Standards (DELETED) REQT: Accommodate security standards, or draft standards, where appropriate. Candidates include those from ISO, ECMA, IETF and POSIX. Deleted because this requirement is not unique to security and is a given OSF goal. APPENDIX A. MEMBER VOTES The following are the individual companies' votes on each item. A separate vote was taken for DCE 1.1 and DCE 2.0. One groundrule was that any company could change its vote prior to the time the requirement was committed. Therefore, at the time of this writing, the 1.1 votes are pretty much cast in concrete while the 2.0 votes can yet change significantly. Note there is a significant difference between a D vote (should not have) as opposed to a "-" vote (don't care). A D vote expresses explicitly the view that the feature is not appropriate for OSF to put into DCE in the specified time frame. A "-" vote, on the other hand, expresses "no opinion" and should be taken as neither favorable nor unfavorable. Gasser Page 14 DCE-RFC 8.0 DCE SIG Security Requirements July 1992 The group initially started to vote for each item separately for 1.1 and 2.0. Part way through the voting (around {D2}) it was decided that many items were not relevant to 1.1. In order to expedite the voting process for 1.1 requirements so that OSF could get quicker results from the group, the group eliminated a number of items from 1.1 consideration. No item was dropped unless there was a consensus that it should not be considered. The votes recorded below are to be interpreted as follows: (a) "A" = must have (b) "B" = should do if time (c) "C" = nice to have (d) "D" = should not have (e) "-" = don't care or don't know (f) "?" = don't understand requirement (g) "." = not voting/not present A.1. The Raw Votes Gasser Page 15 DCE-RFC 8.0 DCE SIG Security Requirements July 1992 DCE Bell- Uni- GM/ Code Rel. DEC UMD IBM USAF HP core BULL SNI ICL MITRE sys Shell EDS DG ---- --- --- --- --- ---- -- ---- ---- --- --- ----- --- ----- --- -- {A1} 1.1 C A B B B D D C D B . . A . {A1} 2.0 A A A A A C B C B A . . A . {A2} 1.1 D D D D D D D D D D . . A . {A2} 2.0 C C C C C B B C D? C . . A . {A3} 1.1 D D D D D D D - D D . . - . {A3} 2.0 C C C C B B C C C C . . - . {A4} 1.1 D D D D D D D - C D . . A . {A4} 2.0 - B B B B B C C B C . . A . {A5} 1.1 D D D D D D D - D D . . C . {A5} 2.0 - B B B B B C C B C . . C . {A8} 1.1 D D D D D D D C C C . . ? . {A8} 2.0 B C B B B B C B B B . . ? . {D1} 1.1 B A A - B A D B D C . . A . {D1} 2.0 A A A - B C D A D B . . A . {D2} 1.1 C A C - B C B B C C . . B . {D2} 2.0 B A A - A A A A A A . . A . {D3} 2.0 - A C C A D - . . C . . ? . {D4} 2.0 C . C . C C B C C . C A C C {D5} 2.0 C . C . C C B C C . C A C C {E1a} 1.1 B B B B B B C B C B . . A . {E1a} 2.0 A A A A A A A A A A . . A . {E1b} 1.1 B B D B B C C B C C . . A . {E1b} 2.0 A A C B B B A A A A . . A . {E2} 1.1 B B A B C B D C C C . . A . {E2} 2.0 A A A A B A A A A A . . A . {E3} 1.1 C C C C C D C A C C . . A . {E3} 2.0 A B A B B A B A B B . . A . {E4} 1.1 C D D C C C C C D C . . C . {E4} 2.0 A C C B C A B B B B . . B . {E5} 1.1 D D D D D D D - D D . . A . {E5} 2.0 C C C C C B D B D? C . . A . {E7} 2.0 - - - - A A A . . - . . D . {I1} 1.1 C B A C C B D D D C . . A . {I1} 2.0 A A A B B A D D C B . . A . {I2} 1.1 D D D D D D D D D D . . C . {I2} 2.0 A A B C C B C D C C . . C . {P4} 2.0 A . C . C A B B C . A A A B {P5} 2.0 . . . . . . . . . . . . A . {P6} 2.0 A . A . A A A A A . A A C A {P7} 2.0 C . C . C C C C C . C C C C {P8} 2.0 B . A . B B A C B . A A C A {P9} 2.0 B . C . B B A A A . B - C - {P10a} 1.1 - B A C - - ? D ? - . . - . {P10a} 2.0 C B A B A - ? D ? - . . - . {P10b} 1.1 D - - - - - ? - ? - . . - . {P10b} 2.0 D - - - - - ? ? ? - . . - . {P14} 1.1 C C A C D A C C C C . . B . {P14} 2.0 A A A B - A B A A B . . A . Gasser Page 16 DCE-RFC 8.0 DCE SIG Security Requirements July 1992 {R1} 2.0 [postponed] {R2} 1.1 C A C C A - D C ? C . . A . {R2} 2.0 A A B B A A B B ? B . . A . {R3} 2.0 B . C . C B C C C . B B C - {R4} 2.0 C . B . C C C A B . B B B - {R5a} 1.1 C C D C C C D C D C . . B . {R5a} 2.0 A B B B B B C B B B . . B . {R5b} 1.1 C C D C C C D C D C . . B . {R5b} 2.0 A B B B B A A B B B . . B . {R6} 1.1 D D D D C D D D D D . . B . {R6} 2.0 A B C C B A D D D C . . A . {R7} 1.1 - D D - - C C D D - . . D . {R7} 2.0 A C C - - C D D D - . . D . {T1} 1.1 B C A B B B B B B B . . B . {T1} 2.0 A B A A A A A A A A . . B . {T2} 1.1 - C B C C C C B C C . . C . {T2} 2.0 - B A B A C B A B B . . C . {X1} 2.0 B . B . C B C B B . B A A B {X2} 1.1 C A A C C A B A B C . . B . {X2} 2.0 A A A B B A B A A A . . B . A.2. Summary of Votes The following is an attempt to summarize the raw votes above. First, numbers were assigned to the priority letters, where A (highest)=3, B=2 and C=1, consistent with the manner in which the DCE SIG computed their votes. In the DCE SIG, there was controversy as to whether a D vote should simply count as zero, or should be considered a stronger negative vote, so the computation was done with both D=0 and D=-2. Note that, even with D=0, the fact that the vote is included in the average gives it more significance than if D votes were simply not counted. Votes of "-" or "?" are not counted in this summary. Simply providing a total would be misleading, because different numbers of vendors voted on different items, depending on who was present at the different meetings. Therefore, an average vote was computed and is shown in the table. The total number of votes included in that average is shown to provide an indication of the relative "weight" of the vote. (Counting only A, B, C or D votes.) If fewer than 5 vendors voted on an item (which would be less than half the representatives), the vote is probably not very valid. If 8 or more vendors voted then the vote should be taken as an accurate reflection of the group consensus. Gasser Page 17 DCE-RFC 8.0 DCE SIG Security Requirements July 1992 A=3, B=2, C=1 --------------------------- DCE V1.1 DCE V2.0 ------------ ------------ D=0 D=-2 D=0 D=-2 Code Title Avg Avg No Avg Avg No ---- ------------------------------------- --- --- -- --- --- -- {A1} Authorization based on delegation 1.5 .9 11 2.5 2.5 11 {A2} Author. based on authentication style .3 -1.5 11 1.4 1.4 10 {A3} Authorization based on capabilities 0 -2.0 9 1.2 1.2 10 {A4} Authorization based on location .4 -1.2 10 1.8 1.8 10 {A5} Anonymous access .1 -1.7 10 1.6 1.6 10 {A8} Other security attributes .3 -1.1 10 1.8 1.8 10 {D1} Full Delegation 1.9 1.5 10 2.0 1.6 10 {D2} Delegation with restrictions 1.6 1.6 10 2.9 2.9 10 {D3} User-to-user authentication 1.5 1.2 6 {D4} Integrity protection of requests 1.3 1.3 11 {D5} Integrity protection of responses 1.3 1.3 11 {E1a} Secure remote login 1.9 1.9 11 3.0 3.0 11 {E1b} Secure file transfer 1.5 1.4 11 2.5 2.5 11 {E2} Security API through non-rpc prots 1.6 1.5 11 2.9 2.9 11 {E3} Other user authentication methods 1.3 1.1 11 2.5 2.5 11 {E4} More options for comm. security .7 .2 11 1.9 1.9 11 {E5} Application security services .3 -1.5 10 1.3 1.1 10 {E7} Algorithms 2.3 1.8 4 {I1} Global groups 1.3 .7 14 2.0 1.5 11 {I2} Preserve rights on cell change .1 -1.8 11 1.5 1.3 11 {P4} Recovery from security compromise 2.2 2.2 11 {P5} Detection of denial of service 3.0 3.0 1 {P6} Algorithms for security messages 2.8 2.8 11 {P7} B1 portability 1.0 1.0 11 {P8} C2 portability 2.3 2.3 11 {P9} ITSEC evaluation 2.1 2.1 9 {P10a} OS integration 1.8 1.4 5 2.2 1.8 6 {P10b} Network interoperation 1.0 1.0 1 2.0 2.0 1 {P14} Defaults 1.4 1.2 11 2.7 2.7 10 {R2} Trust relationships 1.6 1.3 9 2.5 2.5 10 {R3} Privacy-enhanced mail integration 1.4 1.4 10 {R4} X.400 security integration 1.7 1.7 10 {R5a} X.509 certificates for users .8 .3 11 2.0 2.0 11 {R5b} X.509 certificates for servers .8 .3 11 2.3 2.3 11 {R6} Permit offline security servers .3 -1.4 11 1.5 .9 11 {R7} Pull model .3 -1.1 7 .8 -.3 8 {T1} Local auditing 2.0 2.0 11 2.8 2.8 11 {T2} Remote auditing 1.2 1.2 10 2.1 2.1 10 {X1} Loading and booting security 2.0 2.0 11 {X2} Limit password dictionary attacks 2.0 2.0 11 2.6 2.6 11 Gasser Page 18 DCE-RFC 8.0 DCE SIG Security Requirements July 1992 A.3. Analysis of Results The reader is encouraged to draw his/her own conclusions from the results published above. The analysis provided here does not represent group consensus and may be controversial. For DCE 1.1, the following are the top 10 items where 6 or more voted. The single line (-----) represents the 1.1 vote by which items are ranked, and the double line (=====) represents the 2.0 vote for comparison. nice if time must C B A |....|....|....|....| {T1} Local auditing 2.0 ----------- 2.8 =================== {X2} Limit password dictionary attacks 2.0 ----------- 2.6 ================= {E1a} Secure remote login 1.9 ---------- 3.0 ===================== {D1} Full delegation 1.9 ---------- 2.0 =========== {E2} Security API through non-RPC prot. 1.6 ------- 2.9 ==================== {R2} Trust relationships 1.6 ------- 2.5 ================ {D2} Delegation with restrictions 1.6 ------- 2.9 ==================== {E1b} Secure file transfer 1.5 ------ 2.5 ================ {A1} Authorization based on delegation 1.5 ------ 2.5 ================ {P14} Defaults 1.4 ----- 2.7 ================== Note that nothing received greater than a bare minimum "should do if time" vote for DCE 1.1. This probably represents a feeling among vendors that, despite the very high desirability of all of these features in the 2.0 time frame, people are lukewarm to the idea that security improvements should be a major feature of DCE 1.1. No single feature was considered important enough to impact the 1.1 schedule, even slightly. OSF should take this as a fairly strong message because, as evidenced by the large laundry list of items and the 2.0 results, the working group members were not shy about voting nominating security features and voting A's for them. Altogether, a total of 25 out of 40 items were voted below "nice to have" for 1.1, indicating that OSF should barely consider including those features in 1.1 even if they came for free. Gasser Page 19 DCE-RFC 8.0 DCE SIG Security Requirements July 1992 One caveat, however. Most of the members probably voted for 1.1 features based on what they thought was practical in the 1.1 time frame, and this time frame is now at least 6 months later than the working assumptions at the time of the vote. It is possible that, give a chance to take another vote with the new time frame in mind, the priority of some of the items would increase. It is unlikely any would decrease. It is also interesting to note that one feature does not increase in priority very much in 2.0: "{D1} Full delegation". This is probably because "{D2} Delegation with restrictions" satisfies the requirement for delegation in a much more flexible fashion, thereby reducing or eliminating the need for {D1}. {D1} was given a higher vote in 1.1 because it is generally considered much simpler to implement, not because it is considered more desirable than {D2}. Unlike the 1.1 votes, the 2.0 votes indicate a unanimous desire for substantial security improvements. Consider the top 10 items for 2.0 (with 6 or more votes): nice if time must C B A |....|....|....|....| {E1a} Secure remote login 1.9 ---------- 3.0 ===================== {E2} Security API through non-RPC prot. 1.6 ------- 2.9 ==================== {D2} Delegation with restrictions 1.6 ------- 2.9 ==================== {P6} Algorithms for security messages 2.8 =================== {T1} Local auditing 2.0 ----------- 2.8 =================== {P14} Defaults 1.4 ----- 2.7 ================== {X2} Limit password dictionary attacks 2.0 ----------- 2.6 ================= {A1} Authorization based on delegation 1.5 ------ 2.5 ================ {E3} Other user authentication methods 1.3 ---- 2.5 ================ {R2} Trust relationships 1.6 ------- 2.5 ================ All of these are at or near the "must have" level. To a certain extent, one could argue that the group was using 2.0 as a target for all the security features anyone would ever want, as 24 out of the 40 items were voted at least "should do if time". This is also born out by looking at the individual member votes, where there were very few "should not have" votes for 2.0. To be fair, the "2.0 votes" were done at a time when there was only a very fuzzy time frame in mind. It is probably accurate to read these votes as a vote for "all the Gasser Page 20 DCE-RFC 8.0 DCE SIG Security Requirements July 1992 security features that DCE will ever need", rather than a vote specifically to include the features in the 2.0 release. Only one new item appeared in this top 10 list that was not in the 1.1 top 10. "{P6} Algorithms for security messages" was anticipated to be very important in the future but not relevant in the 1.1 time frame. Voting on requirements is not complete, as there are a number of requirements on which sufficient (6 or more) A-D or "no opinion" votes were not received, either because they were not understood and need more definitional work, or because they were explicitly postponed for further study. Lack of a vote does not imply a low priority; in fact several of these items are likely to be high priority. The requirements falling into this category are: (a) {A7} Authorization Based on Security Attributes (b) {A9} Mandatory Access Controls (Labeling) (c) {P5} Detection of Denial of Service (d) {R1} Registry and Naming Convergence AUTHOR'S ADDRESS Morrie Gasser Internet email: gasser@grotto.enet.dec.com Digital Equipment Corporation Telephone: +1-508-486-5817 550 King St. Littleton, MA 01748 USA Gasser Page 21