OSF DCE SIG J. Linn (DEC) Request For Comments: 5.0 June 1992 GSS-API EXTENSIONS FOR DCE 1. INTRODUCTION AND CONTEXT Several standards activities based on the Generic Security Service Application Program Interface (GSS-API) are currently underway or under consideration: (a) Advancement of specification, as submitted to IETF Internet- Drafts in June, 1991 and updated June, 1992, under Common Authentication Technology (CAT) working group jurisdiction, to Proposed Standard RFC. (b) Derived UK Expert contribution ("GSAI") by Nick Pope, consultant to ICL, to ISO SC21/WG6. (c) Possible adoption by X/Open Security working group, and possible liaison between that group and IETF-CAT. (d) Consideration by POSIX Distributed Security committee. In addition to the above, DIGITAL is in discussion with the SESAME consortium (members: ICL, Bull, and Siemens/Nixdorf) to develop a joint architecture aimed at a future release of DCE. There appears to be relatively general acceptance of GSS-API within its present scope of establishing security contexts, performing peer-entity authentication, and yielding shared keys for use in integrity and confidentiality protection of data messages. Many of the activities listed above desire extensions to support authorization features (e.g., indication of group affiliations or other attributes) over and above pure authentication of principal names. We expect to proceed with standards advancement of the current specification, and to position added authorization features as optional extensions for certain environments. 2. DCE EXTENSION PROPOSAL This section defines a specific GSS-API[1] extension being proposed Linn Page 1 DCE-RFC 5.0 GSS-API Extensions for DCE June 1992 to OSF for implementation and incorporation within DCE V1.1. Specific issues to be resolved in the course of implementing GSS-API over the DCE security mechanism are also identified. The proposal is oriented to the current DCE operational paradigm in which Privilege Attribute Certificates (PACs) are opaque objects from the viewpoint of applications, and their contents are interpreted within ACL managers which embody (through use of id_base.idl) knowledge of PAC structure. Generic features for extraction of tagged attributes from PACs, extensible beyond the realm, principal, and group identifiers which are currently represented therein, are being considered for subsequent proposal after the V1.1 timeframe but are not addressed by this document. The proposal's goal is to provide non-RPC applications operating within a DCE environment the ability to use the DCE Shared-Secret authentication protocol (and, in future, other authentication protocols) via the GSS-API, and to make use of the DCE Authorization protocol in addition to Name-Based Authorization as supported through the existing GSS-API. This support is intended to afford such applications security features and integration paradigms which are analogous to those which DCE currently affords to RPC-based applications. No assumption is made that DCE RPC runtimes will be restructured so as to layer atop GSS-API. Applications making use of the proposed extension will not be portable to non-DCE authorization support environments; received DCE PACs are not assumed to be interpretable by arbitrary non-DCE ACL managers. This proposal does not extend the scope of GSS-API to incorporate login functions; existing DCE "sec_login_*" primitives remain unchanged. This group of DCE primitives includes functions which create a login context, allow a variant login context to be created designating a subset of group memberships, and to import and export login contexts among processes. DCE login contexts correspond to GSS-API credentials, and should not be confused with GSS-API security contexts which are pairwise security associations between peers. Conceptually, credentials structures are paired with corresponding login contexts, so that, e.g., a modification to a DCE login context will affect subsequent references to the associated GSS-API credentials. Caller references to default GSS-API credentials will correspond to the current DCE login context; a GSSDCE_LoginContext_To_Cred() call is defined for __________ 1. The proposal is defined relative to the document "Generic Security Service Application Program Interface", Internet-Draft draft-ietf-cat- genericsec-01.ps, June 1992. Linn Page 2 DCE-RFC 5.0 GSS-API Extensions for DCE June 1992 use by those callers (probably to be in the minority) which need to select among alternative credentials sets. As noted previously, DCE login contexts correspond functionally to GSS-API credentials. The current proposal relies on use of these DCE primitives to modulate group affiliations rather than defining GSS- API extensions to support this function. If and when other (non- group) attributes are introduced into future versions of DCE, it will likely become appropriate to define additional extensions allowing control of a variety of tagged attributes within GSS-API credentials in a generic manner. The existing GSS-API GSS_Accept_sec_context() primitive provides (and will continue to provide) a client's name, which is suitable as a basis for name-based authorization policies. Further, already- defined GSS-API per-message primitives can enable applications to protect their transferred data with integrity and confidentiality services. 2.1. Extension Definition This subsection defines the extension GSS-API primitives to be added for DCE support. 2.1.1. GSSDCE_Extract_PAC_From_SecContext call Inputs: (a) context_handle INTEGER, -- GSS-API security context handle Outputs: (a) major_status INTEGER, (b) minor_status INTEGER, (c) output_PAC OCTET STRING Return major_status codes: (a) GSS_COMPLETE indicates that the returned output_PAC result carries a Privilege Attribute Certificate (PAC), suitable as input to the DCE sec_acl_test_access_on_behalf() primitive. (b) GSS_PAC_NOTAVAIL, a new exception status, indicates that the specified context is valid but that no PAC is available for the specified security context's peer. (c) GSS_NO_CONTEXT indicates that no valid context was recognized for the input context_handle provided. Linn Page 3 DCE-RFC 5.0 GSS-API Extensions for DCE June 1992 (d) GSS_FAILURE indicates that the PAC extraction operation failed for reasons unspecified at the GSS-API level. Used by a context peer to extract the PAC (if any) representing the privilege attributes of the security context's other peer. PACs will be transferred as elements of the context establishment tokens; the GSSDCE_Extract_PAC() primitive should not be invoked until context establishment is complete. 2.1.2. GSSDCE_Extract_PAC_From_Cred call Inputs: (a) cred_handle OCTET STRING, -- GSS-API credential handle, NULL specifies default credentials Outputs: (a) major_status INTEGER, (b) minor_status INTEGER, (c) output_PAC OCTET STRING Return major_status codes: (a) GSS_COMPLETE indicates that the returned output_PAC result carries a Privilege Attribute Certificate (PAC), suitable as input to the DCE sec_acl_test_access_on_behalf() primitive. (b) GSS_PAC_NOTAVAIL, a new exception status, indicates that the specified credential structure is valid but bears no associated and/or available PAC (c) GSS_NO_CRED indicates that it was not possible to determine or indicate whether or not a PAC was associated with the specified credential structure, either because the input cred_handle was invalid or because the caller lacks authorization to access the referenced credentials. (d) GSS_FAILURE indicates that the PAC extraction operation failed for reasons unspecified at the GSS-API level. Used by a context peer to extract the PAC (if any) representing the privilege attributes associated with a credentials structure. Linn Page 4 DCE-RFC 5.0 GSS-API Extensions for DCE June 1992 2.1.3. GSSDCE_LoginContext_To_Cred call Inputs: (a) login_context OCTET STRING, (b) lifetime_req INTEGER, -- in seconds; 0 requests default (c) desired_mechs SET OF OBJECT IDENTIFIER, -- empty set requests default (d) cred_usage INTEGER -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY, 2=ACCEPT-ONLY Outputs: (a) major_status INTEGER, (b) minor_status INTEGER, (c) output_cred_handle OCTET STRING, (d) lifetime_rec INTEGER -- in seconds, or reserved value for INDEFINITE Return major_status codes: (a) GSS_COMPLETE indicates that requested credentials were successfully established, for the duration indicated in lifetime_rec, suitable for the usage requested in cred_usage, and for all or a subset of the requested mech_types, and that those credentials can be referenced for subsequent use with the handle returned in output_cred_handle. (b) GSS_BAD_MECH indicates that a mech_type unsupported by the GSS-API implementation was requested, causing the credential establishment operation to fail. (c) GSS_FAILURE indicates that credential establishment failed for other reasons not distinguished at the GSS-API level. This call, a variant of the GSS-API GSS_Acquire_cred() call, is provided for use by those callers who need, through an explicit GSS- API credential handle, to make use of GSS-API credentials sets corresponding to other than their current DCE login context. The desired_mechs input parameter allows, e.g., callers to request credentials suitable for use with a Kerberos V5 mechanism as well as with the DCE Security mechanism. Linn Page 5 DCE-RFC 5.0 GSS-API Extensions for DCE June 1992 2.1.4. GSSDCE_Cred_To_LoginContext call Inputs: (a) input_cred_handle OCTET STRING Outputs: (a) major_status INTEGER, (b) minor_status INTEGER, (c) login_context OCTET STRING Return major_status codes: (a) GSS_COMPLETE indicates that the requested login context was successfully established base on the input credentials. (b) GSS_FAILURE indicates that no login context could be established, for other reasons undistinguished at the GSS-API level. This call makes it possible to reference a DCE login context with contents based on the input GSS-API credentials. The primary use of this call will be to enable the recipients of delegations via GSS-API to make use of the delegated rights in subsequent operations (e.g., DCE RPC) which are based on login contexts rather than credential handles. 3. IMPLEMENTATION COMMENTARY This subsection summarizes and comments on some of the technical issues and actions which must be addressed in order to implement the extended GSS-API atop the DCE Security mechanism. It should not be regarded as a comprehensive issue list or complete work plan. 3.1. Actions (a) A GSS-API mechanism type OID must be assigned to represent the DCE security mechanism. (b) A GSS-API name type must be assigned to represent the DCE printable name type. Implementation of GSS-API atop DCE security technology will require that one (or more) types of names be supported by the DCE-based implementation, functionally analogous to the value returned by the DCE rpc_binding_inq_auth_client() primitive for the case of authz_svc==rpc_authz_name or the optional printstring value in a sec_id_t. These DCE data elements incorporate string names Linn Page 6 DCE-RFC 5.0 GSS-API Extensions for DCE June 1992 which are syntactically distinguishable as either untyped names in Internet-DNS form or printable representations of X.500 typed DNs. For consistency with the GSS-API paradigm and other portions of DCE (e.g., name service API), I suggest that XOM- formatted names, as further interpreted by DCE, be used as the internal representation input to gss_init_sec_context() and output from gss_accept_sec_context(), with gss_import_name() and gss_export_name() translating to and from the DCE printable form. (c) Token formats for transfer of authentication and authorization data (including PACs) must be defined for the DCE security mechanism type; use of the token framing structure defined in the GSS-API specification is recommended. (d) Coordination will be required with development of any DCE delegation features which may be incorporated into DCE V1.1. REFERENCES [GSSAPI] J. Linn, "Generic Security Service Application Program Interface", Internet-Draft draft-ietf-cat-genericsec-01, June 1992. [This Internet-Draft, like all other Internet-Drafts, is not an archival document and is subject to change or deletion. It is available at the time of this writing (June 1992) by anonymous ftp from nnsc.nsf.net, directory internet-drafts. Would-be readers should check for successor Internet-Draft versions or Internet RFCs before relying on this document.] AUTHOR'S ADDRESS John Linn Internet email: linn@erlang.enet.dec.com Digital Equipment Corporation Telephone: +1-508-486-7384 550 King Street, LKG1-2/A19 Littleton, MA 01460 USA Linn Page 7