- Email: [email protected]
Generic interface to security services
Generic interface to security services John Linn
This paper describes the features of a Generic Security Service Application Program Interface (GSS-API), examines its underlying assumptions, and evaluates lessons learned during its evolution. The GSS-API is designed to support architects of distributed protocols by providing them with a 'toolkit' for integration of security features (peer entity authentication, data origin authentication, data integrity and data confidentiality) into those protocols. It has been implemented atop a variety of technologies, including both secret-key and publickey approaches.
Keywords: security, interface, GSS-API
The Generic Security Service Application Program Interface (GSS-API) definition provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. This strategy provides leverage for the efforts of security developers by allowing a single security implementation to be integrated with, and used by, multiple caller protocols. Further, it allows protocol implementors to focus on the functions that their protocols provide rather than on characteristics of particular security mechanisms. The security services available through GSS-API in this fashion are implementable (and have been implemented) over a range of underlying mechanisms based on secret-key and public-key cryptographic technologies. GSS-API's typical callers are distributed protocol modules, generally though not necessarily at the application layer. These callers invoke GSS-API primitives to integrate security features (authentication, integrity and confidentiality) into their protocols and assume responsibility for transferring GSS-API token data elements within those protocols. Authorization (access control decision-making) functions are not included within the GSS-API scope, as alternative and OpenVision Technologies, Security Business Unit, One Main Street. Cambridge, MA 02142, USA
conflicting models unsuited to encapsulation in a generic framework are in use and emerging. Environment-specific extensions to GSS-API are evolving in various forums to support specific authorization technologies. Although the GSS-API's primary scope is that of an interface and service definition, the fact that its intended purpose is integration with caller protocols motivates the associated definition of a small but significant element of message format definition. This element frames an initial GSS-API context establishment token in a mechanism-independent and interoperable fashion, identifying the mechanism type to be employed in the context. While inclusion of this definition within the GSS-API specification has proven somewhat controversial, its availability to protocol integrators and mechanism designers is important. A base, language-independent specification is currently complemented by a separate document specifying C language bindings; analogous bindings for other languages may follow in future. Companion mechanism-oriented documents define token formats, protocols and procedures to be implemented to realize GSS-API services atop particular security mechanisms. The interface's design assumes and addresses several basic goals, including: •
•
Mechanism independence: the GSS-AP1 defines an interface to cryptographically implemented strong authentication and other security services at a generic level which is independent of particular underlying mechanisms. For example, GSS-APlprovided services can be implemented by secret-key technologies (e.g. Kerberos*) or public-key approaches (e.g.X.509/ISO 9594-81). Protocol environment independence: the GSS-API is independent of the communications protocol suites with which it is employed, permitting use in a broad range of protocol environments. Where
*Kerberos is a trademark of the Massachusetts Institute of Technology (MIT). No commercial use of this trademark may be made without prior written permission of"MIT.
0140-3664/94/07/0483-09 :~{~'1994 B u t t e r w o r t h - H e i n e m a n n Ltd c o m p u t e r c o m m u n i c a t i o n s v o l u m e 17 n u m b e r 7 j u l y 1994
483
Generic interface to security services: J Linn
appropriate, an intermediate implementation 'veneer' which is oriented to a particular communication protocol (e.g. Remote Procedure Call (RPC)) may be interposed between applications which call that protocol and the GSS-API, thereby invoking GSS-API facilities in conjunction with that protocol's communications invocations. Protocol association independence: the GSS-API's security context construct is independent of communications protocol association constructs. This characteristic allows a single GSS-AP! implementation to be utilized by a variety of invoking protocol modules on behalf of those modules' calling applications. GSS-API services can also be invoked directly by applications, wholly independent of protocol associations. Suitability to a range of implementation placements: GSS-API clients are not constrained to reside within any Trusted Computing Base (TCB) perimeter defined on a system where the GSS-API is implemented; security services are specified in a manner suitable to both intra-TCB and extra-TCB callers.
Operational paradigm The GSS-API's operational role is illustrated in Figure 1. A GSS-API caller accepts tokens provided to it by its local GSS-API implementation and transfers the tokens to a peer on a remote system; that peer passes the received tokens to its local GSS-API implementation for processing. The GSS-API is independent of underlying protocols and addressing structure, and depends upon its callers to transport GSS-API-provided data elements. As a result of these factors, callers must parse communicated messages, so as to separate GSS-API data elements from caller-provided data. The GSS-API is independent of connection versus connectionless orientation of the underlying communications service. The GSS-API separates the operations of initializing a security context between peers, achieving peer entity authentication (GSS_Init sec context() and GSS_Accept sec context() calls), from the operations of providing per-message data origin authentication and data integrity protection (GSS_Sign0 and GSS_Verify0 calls) for messages subsequently transferred in conjuncCaller Protocol
]~
GSS-API Service Interface
v[
Caller Protocol
GSS-API Service Interface
222 Figure 1 GSS-API paradigm
484
]
tion with that context. Per-message GSS_Seal0 and GSS_Unseal() calls provide the data origin authentication and data integrity services which GSS_Sign() and GSS_Verify() offer, and also support the selection of confidentiality services as a caller option. Additional calls provide supportive functions to the GSS-API's users. Figure 2, discussed below, provides an example illustrating the dataflows involved in the use of the GSS-API by a client and server in a mechanismindependent fashion, establishing a security context and transferring a protected message. The example assumes that credential acquisition has already been completed. The example also assumes that the underlying authentication technology is capable of authenticating a client to a server using elements carried within a single token, and of authenticating the server to the client (mutual authentication) with a single returned token. The client calls GSS_Init sec context() to establish a security context to the server identified by targ_name, and elects to set the mutual_req_flag so that mutual authentication is performed in the course of context establishment. GSS_Init sec context() returns an output_token to be passed to the server, and indicates G S S _ C O N T I N U E _ N E E D E D status pending completion of the mutual authentication sequence. Had mutual_req_flag not been set, the initial call to GSS_Init sec context() would have returned GSS C O M P L E T E status. The client sends the output_token to the server. The server passes the received token to GSS_Accept_sec_context0. GSS_Accept_sec_context indicates G S S _ C O M P L E T E status, provides the client's authenticated identity, and provides an output_token to be passed to the client. The server sends the output_token to the client. The client passes the received token to a successor call to GSS_Init sec context(), which processes data included in the token to achieve mutual authentication from the client's viewpoint. This call to GSS_Init sec context() returns a G S S _ C O M P L E T E status, indicating successful mutual authentication and the completion of context establishment for this example. The client generates a data message and passes it to GSS_Seal0. GSS_Seal0 performs data origin authentication, data integrity and (optionally) confidentiality processing on the message and encapsulates the result into output_message, indicating a G S S _ C O M P L E T E status. The client sends the output_message to the server. The server passes the received message to GSS_Unseal0. GSS_Unseal inverts the encapsulation performed by GSS_Seal(), deciphers the message if the optional confidentiality feature was applied, and validates the data origin authentication and data integrity checking quantities. GSS_Unseal() indicates successful validation by returning G S S _ C O M P L E T E status along with the resultant output_message.
c o m p u t e r c o m m u n i c a t i o n s v o l u m e 17 number 7 july 1994
Generic interface to security services: J Linn Server G S S - A P I
Server
Client
Client G S S - A P I
_. targ_name, mutual_req~flag GS S_Ini t_sec_contextO output_token token
GSS_CONTINUE_NEEDED
inputtoken r
4
GSS Accept_sec_contextO output_token, src_name
token
GSS COMPLETE
GS S_Init_sec_contextO r
GSS_COMPLETE inputmessage GS S_SeaIO output_message
GSS_COMPLETE
message
input_message y
input_contexttoken
41
context token
GSS_UnsealO output_message
GSS COMPLETE
GS S_Process_context_tokenO
GSS_COMPLETE Figure 2 Example GSS-API dataflow
Recognizing that the example application's requirement for use of the security context is now complete, the server next calls GSS_Delete sec context() to flush context-level information. GSS_Delete sec context() returns a context_token for the server to pass to the client. The client passes the returned context_token to GSS_Process_context_token0, which returns G S S _ C O M P L E T E status after deleting context-level information at the client system.
GSS-API
constructs
This section describes the basic elements comprising the GSS-API. Credentials
Credentials structures provide the prerequisites enabling peers to establish security contexts with each other. The credential elements defined by a particular mechanism may contain multiple cryptographic keys, e.g. to enable authentication and message encryption to be performed with different algorithms. A single credential structure may accommodate credential information associated with multiple underlying mechanisms (mech_types); a credential structure's contents will vary depending upon the set of mech_types supported by a particular GSSAPI implementation. Underlying system-specific mechanisms and OS functions below the GSS-API must ensure that the ability to acquire and use credentials associated with a given identity is constrained to appropriate processes within a system. Implementors should take this respon-
sibility seriously, as the ability for an entity to utilize a principal's credentials is equivalent to the entity's ability to successfully assert that principal's identity. Once a set of GSS-API credentials is established, their transferability within a system is a local matter, not defined by the GSS-API. An example local policy would be one in which any credentials generated based on login to a given user account, or of delegation of rights to that account, are accessible by, or transferable to only processes running under that account. The credential establishment process (particularly when performed on behalf of users rather than server processes) is likely to require access to passwords or other quantities which should be protected locally and exposed for the shortest time possible. As a result, it will often be appropriate for preliminary credential establishment to be performed through local means at user login time, with the result(s) cached for subsequent reference. These preliminary credentials would be set aside (in a system-specific fashion) for subsequent use, either to be accessed by an invocation of the GSS-API GSS_Acquire_cred0 call, returning an explicit handle to reference that credential or as the default credentials installed on behalf of a process. Tokens
Tokens are data elements transferred between GSS-API callers, and are divided into two classes. Context-level tokens are exchanged to establish and manage a security context between peers. Per-message tokens are exchanged in conjunction with an established context to provide protective security services for corresponding data messages. Tokens' internal structures are defined by particular security mechanisms underlying GSS-API.
computer communications volume 17 number 7 july 1994
485
Generic interface to security services: J Linn
Tokens are opaque from the viewpoint of GSS-API callers. They are generated within the GSS-API implementation at an end system, provided to a GSS-API caller to be transferred to the peer GSS-API caller at a remote end system, and processed by the GSS-API implementation at that remote end system. Token transfer may take place in an in-band manner, integrated into the same protocol stream used by the GSSAPI callers for other data transfers, or in an out-ofband manner across a logically separate channel.
Security contexts Security contexts are established between peers, using credentials established locally for each peer or received by peers as a result of delegation. Multiple contexts may exist simultaneously between a pair of peers, using the same or different sets of credentials. Coexistence of multiple contexts using different credentials allows graceful rollover when credentials expire. Distinction among multiple contexts based on the same credentials serves applications by distinguishing different message streams in a security sense. No correlation between security context and communications protocol association is dictated. (An optional channel binding facility, discussed later in this paper, represents an intentional exception to this rule, supporting additional protection features within GSSAPI supporting mechanisms.) This separation allows the GSS-API to be used in a wide range of communications environments, and also simplifies the calling sequences of the individual calls. In many cases (depending upon the underlying security protocol, associated mechanism and availability of cached information), the state information required for context setup can be sent concurrently with initial signed user data, without interposing additional message exchanges.
Mechanism types To successfully establish a security context with a target peer, it is necessary to identify an appropriate underlying mechanism type (mech_type) which both initiator and target peers support. Mechanisms are identified, across the service interface and within transferred tokens, using Object Identifiers (OLD). It is recommended that callers initiating contexts specify the 'default' mech_type value, allowing system-specific functions within or invoked by the GSS-API implementation to select the appropriate mech_type, but callers may direct that a particular mech_type be employed when necessary. The means for identifying a shared mech_type to establish a security context with a peer will vary in different environments and circumstances; examples include (but are not limited to): •
486
use of a fixed mech_type, defined by configuration, within an environment
• •
•
syntactic convention on a target-specific basis, through examination of a target's name lookup of a target's name in a naming service or other database in order to identify mech_types supported by that target explicit negotiation between GSS-API callers in advance of security context setup
Naming The GSS-API avoids prescribing naming structures, treating the names transferred across the interface for context establishment as opaque objects. This approach supports the goal of implementation atop a range of underlying security mechanisms, and recognizes the fact that different mechanisms process and authenticate names which are presented in different forms. Primitives are defined to support a level of naming environment independence for certain calling applications, comparing internal-form names and translating them to and from printable representations for acceptance from and presentation to users.
Channel bindings The GSS-API accommodates the concept of callerprovided channel binding ('chan_binding') information, optionally used by GSS-API callers to bind the establishment of a security context to relevant characteristics (e.g. addresses, transformed representations of encryption keys) of the underlying communications channel and of protection mechanisms applied to that communications channel. Verification by one peer of chan_binding information provided by the other peer to a context serves to protect against various active attacks.
GSS-API features and issues This section describes aspects of GSS-API operations, of the security services which the GSS-API provides, and provides commentary on design issues.
Status reporting Each GSS-API call provides two status return values. Major_status values, defined in the GSS-API specification, provide a mechanism-independent indication of call status (e.g. GSS_COMPLETE, G S S _ F A I L U R E , G S S _ C O N T I N U E _ N E E D E D ) , sufficient to drive normal control flow within the caller in a generic fashion. Minor_status codes provide more detailed status information which may include status codes specific to the underlying security mechanism; their values are therefore defined in mechanism-level specifications. G S S _ C O N T I N U E _ N E E D E D major_status returns, and optional message outputs, are provided in GSS_Init sec context() and GSS_Accept sec context() calls so that different mechanisms' use of different
computer communications volume 17 number 7 july 1994
Generic interface to security services: J Linn
numbers of messages within their authentication sequences need not be reflected in separate code paths within calling applications. Instead, such cases are accommodated with sequences of continuation calls to GSS_Init sec context() and GSS_Accept_sec_context0.
across different mechanisms. Meaningful use of nondefault QoP values demands that callers be familiar with the QoP definitions of an underlying mechanism or mechanisms, and is therefore a non-portable construct.
Per-message security service availability
Contents of mechanism specifications
When a context is established, two flags are returned to indicate the set of per-message protection security services which will be available in the context: the integ_avail flag indicates whether per-message integrity and data origin authentication services are available, and the conf_avail flag indicates whether per-message confidentiality services are available. Certain underlying mech_types offer support for replay detection and/or sequencing of messages transferred on the contexts they support. These optionallyselectable protection features are distinct from replay detection and sequencing features applied to the context establishment operation itself; the presence or absence of context-level replay or sequencing features is wholly a function of the underlying mech_type's capabilities, and is not selected or omitted as a caller option. The caller initiating a context provides flags (replay_det_req_flag and sequence_req_flag) to specify whether the use of per-message replay detection ano sequencing features is desired on the context being established. The GSS-AP! implementation at the initiator system can determine whether these features are supported and optionally selectable as a function of mech_type, without the need for bilateral negotiation with the target. When enabled, these features provide indicators as a result of GSS-API processing of incoming messages, identifying whether those messages were detected as duplicates or out-of-sequence. Detection of such events does not prevent a suspect message from being provided to a recipient; the appropriate course of action on a suspect message is a matter of caller policy.
Development of GSS-API support primitives based on a particular underlying cryptographic technique and protocol does not necessarily imply that GSS-API callers invoking that GSS-API mechanism type will be able to interoperate with peers invoking the same technique and protocol outside the GSS-API paradigm. For example, the format of GSS-API tokens defined in conjunction with a particular mechanism, and the techniques used to integrate those tokens into callers' protocols, may not be the same as those used by nonGSS-API callers of the same underlying technique. To achieve interoperability between separately developed implementations of a mechanism, token formats and the semantics of token exchanges must be fully specified and conformantly implemented. To achieve caller portability across separately developed implementations, the set of supported name types and mechanism-level exception status codes must be fully specified and conformantly implemented. These values are defined in a GSS-API mechanism's specification. conformance to which is signified through use of the Object Identifier assigned in the specification.
Quality of protection Some mech_types provide their users with fine granularity control over the means used to provide permessage protection, allowing callers to trade off" security processing overhead dynamically against the protection requirements of particular messages. A permessage quality-of-protection parameter (analogous to quality-of-service - QoS) selects among different QoP options supported by that mechanism. On context establishment for a multi-QoP mech_type, context-level data provides the prerequisite data for a range of protection qualities. It is expected that the majority of callers will not wish to exert explicit mechanism-specific QoP control and will therefore request selection of a default QoP. Definitions of, and choices among, non-default QoP values are mechanism-specific, and no ordered sequences of QoP values can be assumed equivalent
INTERFACE ELEMENTS This section describes the GSS-API's service interface, dividing the set of calls offered into four groups. Credential management call.s" are related to the acquisition and release of credentials by principals. Contextlevel calla" are related to the management of security contexts between principals. Per-message calls are related to the protection of individual messages on established security contexts. Support calls provide ancillary functions useful to GSS-API callers.
Credential management calls These GSS-API calls provide functions related to the management of credentials. The GSS_Acquire_cred0 call is defined within the GSS-API in support of application portability, with a particular orientation towards support of portable server applications. [t is recognized that (for certain systems and mechanisms) credentials for interactive users may be managed differently from credentials for server processes; in such environments, it is the GSS-API implementation's responsibility to distinguish these cases, and the procedures for making this distinction are a local matter. The GSS_Release_credO call provides a means for callers to
computer communications volume 17 number 7 july 1994
487
Generic interface to security services: J Linn
indicate to the GSS-API that use of a credentials structure is no longer required. The GSS_Inquire_cred 0 call allows callers to determine information about a credentials structure.
required) with validation of data items related to authentication and integrity.
Support calls Context-level calls This group of calls is devoted to the establishment and management of security contexts between peers. A context's initiator calls GSS_Init sec context(), resulting in the generation of a token which the caller passes to the target. At the target, that token is passed to GSS_Accept_sec_context0. Depending upon the underlying mech_type and specified options, additional token exchanges may be performed in the course of context establishment; such exchanges are accommodated by GSS C O N T I N U E N E E D E D status returns from GSS_Init sec context() and GSS_Accept_sec_context0. Either party to an established context may invoke GSS_Delete sec context() to flush context information when a context is no longer required. GSS_Process_context_token 0 is used to process received tokens carrying context-level control information. GSS_Context_time() allows a caller to determine the length of time for which an established context will remain valid.
Per-message calls This group of calls is used to perform per-message protection processing on an established security context. These calls may be invoked by a context's initiator or by the context's target. The four members of this group should be considered as two pairs; the output from GSS_Sign 0 is properly input to GSS_Verify0, and the output from GSS_Seal0 is properly input to GSS_Unseal0. GSS_Sign 0 and GSS_Verify 0 support data origin authentication and data integrity services. When GSS_Sign0 is invoked on an input message, it yields a per-message token containing data items which allow underlying mechanisms to provide the specified security services. The original message, along with the generated per-message token, is passed to the remote peer; these two data elements are processed by GSS_Verify0, which validates the message in conjunction with the separate token. GSS_Seal0 and GSS_Unseal0 support callerrequested confidentiality in addition to the data origin authentication and data integrity services offered by GSS_Sign0 and GSS_Verify 0. GSS_Seal 0 outputs a single data element, encapsulating optionally enciphered user data as well as associated token data items. The data element output from GSS_Seal0 is passed to the remote peer and processed by GSS_Unseal() at that system. GSS_Unseal 0 combines decipherment (as 488
This group of calls provides support functions useful to GSS-API callers, independent of the state of established contexts. GSS_Display_status0 provides a means for callers to translate GSS-API-returned major and minor status codes into printable string representations. GSS_Indicate_mechs0 allows callers to determine the set of mechanism types available on the local system. GSS_Compare_name0 enables callers to compare two internal name representations for equality. GSS_Display_name0 enables callers to translate an internal name representation into a printable form with associated namespace type descriptor. GSS_Import_name0 allows callers to provide a printable name representation, designate the type of namespace in conjunction with which it should be parsed, and convert that printable representation to an internal form suitable for input to other GSS-API routines. GSS_Release_name0, GSS_Release_buffer0, and GSS_Release oid set() are used to release the internal storage associated with various GSS-API data elements.
MECHANISM-SPECIFIC SCENARIOS
EXAMPLE
This section provides illustrative overviews of the use of various candidate mechanism types to support the GSSAPI. These discussions are intended primarily for readers familiar with specific security technologies, demonstrating how GSS-API functions can be used and implemented by candidate underlying mechanisms. They should not be regarded as constrictive to implementations or as defining the only means through which GSS-API functions can be realized with a particular underlying technology, and do not demonstrate all GSS-API features with each technology.
Kerberos V5, single-TGT Login functions yield a Ticket-Granting Ticket (TGT) to the local realm Kerberos server, and the T G T is placed in a credentials structure for the client. The client calls GSS_Acquire_cred0 to acquire a cred_handle so as to reference the credentials for use in establishing security contexts. The client calls GSS_Init sec context(). If the requested service is located in a different realm, GSS_Init sec context() gets the necessary T G T and key pairs needed to traverse the path from local to target realm; these data are placed in the owner's T G T
computer communications volume 17 number 7 july 1994
Generic interface to security services: J Linn
cache. After any needed remote realm resolution, the GSS-API code supporting GSS_Init sec context() contacts the Kerberos ticket granting service, yielding a service ticket to the requested target service and a corresponding session key. These data are stored in conjunction with the context. GSS_Init sec context() constructs a Kerberos-formatted client- server message, and returns it to the caller in output_token. The client sends the output_token to the service. The service passes the received token as the input_token argument to GSS_Accept_sec_context0, which verifies the authenticator, provides the service with the client's authenticated name, and returns an output_context_handle. Both parties now hold the session key associated with the service ticket, and can use this key in subsequent GSS_Sign0, GSS_Verify0, GSS_SeaI0 and GSS_Unseal() operations.
X.509 authentication framework This example illustrates use of the GSS-API in conjunction with public-key mechanisms, consistent with the Directory Authentication Framework (X.509). In this environment, the GSS_Acquire_cred0 call establishes a credentials structure which makes the client's private key accessible for use on behalf of the client. The client calls GSS_Init sec context(), which interrogates the Directory to acquire (and validate) a chain of public-key certificates, thereby collecting the public key of the service. The certificate validation operation determines that suitable signatures were applied by trusted authorities and that those certificates have not expired. GSS_Init sec context() generates a secret key for use in per-message protection operations on the context, and enciphers that secret key under the service's public key. The enciphered secret key, along with an authenticator quantity signed with the client's private key, is included in the output_token from GSS_Init sec context(). The output_token also carries a certification path, consisting of a certificate chain leading from the service to the client: a variant approach would defer this path resolution to be performed by the service instead of being asserted by the client. The client application sends the output_token to the service. The service passes the received token as the input_token argument to GSS_Accept_sec_context0. GSS_Accept sec context() validates the certification path, and as a result determines a certified binding between the client's distinguished name and the client's public key. Given that public key, GSS_Accept sec context() can process the input_token's authenticator quantity and verify that the client's private key was used to sign the input_token. At this point, the client is authenticated to the service. The service uses its private key to
decipher the enciphered secret key provided to it for per-message protection operations on the context. The client calls GSS_Sign 0 or GSS_Seal0 on a data message, which causes per-message authentication, integrity and (optional) confidentiality facilities to be applied to that message. The service uses the context's shared secret key to perform corresponding GSS_Verify0 and GSS_Unseal() calls.
ISSUES AND LESSONS LEARNED
Evolutionary background The Internet Engineering Task Force (IETF) Common Authentication Technology (CAT) Working Group (WG) was chartered to pursue standardization of the GSS-API specifications and specifications for supporting mechanisms. When this working group was chartered, the fact was recognized that API definition is an unusual activity within a forum which has traditionally been oriented to specification of protocols rather than interfaces. Concurrent IETF interest in security mechanism development and in use of that development within Internet protocols provided rationale supporting this charter. When the CAT WG was chartered, two security technologies were under active development and targeted for the lnternet protocol standards track: Kerberos 2, based wholly on secret-key cryptography, and DASS 3, employing a hybrid of secret-key and public-key cryptography, including X.509 certificates. The GSS-API was conceived to support application portability between these underlying technologies as initial examples, with prospects open for later integration of other mechanisms under the GSS-API framework. Discussions were undertaken between the architects of Kerberos and DASS mechanisms refining approaches for a hybrid mechanism which would combine Kerberos and DASS features, enabling interoperability between secret-key and public-key domains. This activity yielded a perception that such integration would be technically feasible, but detailed specification or implementation of this concept has not yet been pursued.
Authorization support and delegation controls The current GSS-API does not include authorization decision-making facilities, given a recognition of the diverse set of models existing and planned in this functional area. A natural relationship exists, however, between the authentication function which is accomplished within GSS-API security context establishment and authorization decisions; it is natural to consider extensions which would make such decisions based on GSS-API contexts and/or authenticated names.
c o m p u t e r c o m m u n i c a t i o n s v o l u m e 17 number 7 july 1994
489
Generic interface to security services: J Linn
In a distributed computing environment, authentication must span different systems; the need for such authentication provides motivation for GSS-API definition and usage. Heterogeneous systems in a network can intercommunicate, with globally authenticated names comprising the common bond between locally defined access control policies. Access control policies to which authentication provides inputs are often local, or specific to particular operating systems or environments. If the GSS-API made particular authorization models visible across its service interface, its scope of application would become less general. The current GSS-API paradigm is consistent with the precedent set by Kerberos, neither defining the interpretation of authorization-related data nor enforcing access controls based on such data. Privilege Attribute Certificates (PAC), transferred along with authentication data to represent attributes of an authenticated principal, are a basic element of the authorization model used in the ECMA security model 4'5 and the OSF Distributed Computing Environment. In the GSS-API paradigm, such PACs could appropriately be transferred within context establishment tokens. Representation of PACs as mandatory elements at the level of the generic interface would, however, restrict the set of candidate GSS-API mechanisms, thereby reducing GSS-API's utility to integrators. Additional primitives have been defined for use in conjunction with the basic GSS-API in environments where PACs are supported. Delegation controls constitute another relevant area for GSS-API extension in support of authorization models. At the level of the basic GSS-API, visibility of delegation (the transfer of rights by a context initiator, enabling the target to act on the initiator's behalf) is limited to a Boolean, enabling or disabling the delegation facility. Definition of suitable and useful delegation constraints is an active work area at this time; lacking a current consensus on this topic, the interface definition does not attempt to model delegation controls in a mechanism-independent fashion. Any refinements to restrict the sets of group affiliations, other privileges to be delegated, or the sets of entities to which the results of a delegation are transferable, must be accomplished outside the interface through additional operations to be performed on credentials or contexts, and work is evolving on definitions for such operations.
S T A T U S AND ONGOING A C T I V I T I E S At the time of writing (October 1993), the GSS-API 6, its C bindings 7 and the Kerberos mechanism have reached the status of Internet Proposed Standard RFCs. The RFCs have formed the basis for a liaison with the Security Working Group of the X/Open Company Ltd, and their technical content is currently under considera490
tion for publication as an X/Open specification. Further work on usage and extension of GSS-API has been undertaken within Project SESAME 8. A number of prototype-level single-mechanism GSSAPI implementations have been developed, including the Massachusetts Institute of Technology (MIT) Kerberos Version 5 distribution and Digital Equipment Corporation's SPX public-key authentication system 9, based on the DASS architecture. A production-quality dual-mechanism implementation is being developed for inclusion in the Open Software Foundation (OSF) Distributed Computing Environment (DCE) l°, supporting DCE-specific security protocols (incorporating the Privilege Attribute Certificates (PAC) on which DCE's authorization model is based), as well as interoperability with the Kerberos V5 implementation. Other implementations are anticipated from a number of sources. Work is progressing in the IETF and other forums to use the GSS-API as a means to integrate security into applications. Current Internet work to secure File Transfer Protocol (FTP) and virtual terminal (Telnet) traffic, for example, incorporates provisions for the use of GSS-API. The current GSS-API specification reflects experience with single-mechanism implementations, and embodies a model which anticipates support for multiple mechanisms within an end system. Several multi-mechanism implementations are under development at the time of writing, yielding experience which will be reflected in subsequent interface refinements and extensions. Particular identified activities include: •
•
consideration of a 'negotiated' mechanism type, in which tokens are exchanged to identify a specific authentication technology shared between a pair of end systems; consideration of a lower-layer service provider interface residing beneath GSS-API to support modular development and incorporation of mechanism support facilities for integration within end systems.
ACKNOWLEDGEMENTS The evolution of the GSS-API has been the result of a collaborative effort involving numerous contributing individuals and organizations. It has been my privilege to be involved in this evolution within the Internet Engineering Task Force's Security Area Advisory Group (SAAG), its Common Authentication Technology (CAT) Working Group, in the X/Open Security Working Group, forums of the Open Software Foundation (OSF), and within Digital Equipment Corporation and OpenVision Technologies. I gratefully acknowledge all participants who have contributed to the GSS-API within these forums.
computer communications volume 17 number 7 july 1994
Generic interface to security services: J Linn
REFERENCES 6 l 2 3 4 5
ISO 9594-8, Information Processing Systems Open Systems Interconnection The Director), Authentication Framework, International Standard 9594-8, ISO, Geneva, Switzerland Kobl, J and Neuman, C The Kerberos Network Authentication Service (V5), RFC 1510, Digital Equipment Corporation, USC/ Information Sciences Institute (September 1993) Kaufman, C Distributed Authentication Security Service, RFC 1507, Digital Equipment Corporation (September 1993) European Computer Manufacturers Association, Securi O" in Open Systems: A Securit)' Framework, ECMA Technical Report TR/46 (July 1988) European Computer Manufacturers Association, Security in
7 8
9 10
Open Systems: Data Elements and Service Definitions, ECMA Standard ECMA-138 (December 1989) Linn, J Generic Security Service Application Program Interface, RFC 1508, Geer Zolot Associates (September 1993) Wray, J Generic Security Service API: C-bindings, RFC 1509, Digital Equipment Corporation (September 1993) McMahon, P V An Extended Generic Security Service API, ITAEGV Report NI61, Information Technology Advisory Group for Information Security, Rue de Stassart 36, 1050 Brussels. Belgium (May 1993) Tardo, J and Alagappan, K 'SPX: Global authentication using public key certificates', Proc. IEEE Symposium on Research h7 Security & Privacy, Los Amitos, CA (1991) pp 232 244 Open Software Foundation OSF DCE Application Development Guide: Revision 1.0, PTR Prentice Hall. Englewood Cliffs, NJ (1993)
c o m p u t e r c o m m u n i c a t i o n s v o l u m e 17 number 7 july 1994
491
This paper describes the features of a Generic Security Service Application Program Interface (GSS-API), examines its underlying assumptions, and evaluates lessons learned during its evolution. The GSS-API is designed to support architects of distributed protocols by providing them with a 'toolkit' for integration of security features (peer entity authentication, data origin authentication, data integrity and data confidentiality) into those protocols. It has been implemented atop a variety of technologies, including both secret-key and publickey approaches.
Keywords: security, interface, GSS-API
The Generic Security Service Application Program Interface (GSS-API) definition provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. This strategy provides leverage for the efforts of security developers by allowing a single security implementation to be integrated with, and used by, multiple caller protocols. Further, it allows protocol implementors to focus on the functions that their protocols provide rather than on characteristics of particular security mechanisms. The security services available through GSS-API in this fashion are implementable (and have been implemented) over a range of underlying mechanisms based on secret-key and public-key cryptographic technologies. GSS-API's typical callers are distributed protocol modules, generally though not necessarily at the application layer. These callers invoke GSS-API primitives to integrate security features (authentication, integrity and confidentiality) into their protocols and assume responsibility for transferring GSS-API token data elements within those protocols. Authorization (access control decision-making) functions are not included within the GSS-API scope, as alternative and OpenVision Technologies, Security Business Unit, One Main Street. Cambridge, MA 02142, USA
conflicting models unsuited to encapsulation in a generic framework are in use and emerging. Environment-specific extensions to GSS-API are evolving in various forums to support specific authorization technologies. Although the GSS-API's primary scope is that of an interface and service definition, the fact that its intended purpose is integration with caller protocols motivates the associated definition of a small but significant element of message format definition. This element frames an initial GSS-API context establishment token in a mechanism-independent and interoperable fashion, identifying the mechanism type to be employed in the context. While inclusion of this definition within the GSS-API specification has proven somewhat controversial, its availability to protocol integrators and mechanism designers is important. A base, language-independent specification is currently complemented by a separate document specifying C language bindings; analogous bindings for other languages may follow in future. Companion mechanism-oriented documents define token formats, protocols and procedures to be implemented to realize GSS-API services atop particular security mechanisms. The interface's design assumes and addresses several basic goals, including: •
•
Mechanism independence: the GSS-AP1 defines an interface to cryptographically implemented strong authentication and other security services at a generic level which is independent of particular underlying mechanisms. For example, GSS-APlprovided services can be implemented by secret-key technologies (e.g. Kerberos*) or public-key approaches (e.g.X.509/ISO 9594-81). Protocol environment independence: the GSS-API is independent of the communications protocol suites with which it is employed, permitting use in a broad range of protocol environments. Where
*Kerberos is a trademark of the Massachusetts Institute of Technology (MIT). No commercial use of this trademark may be made without prior written permission of"MIT.
0140-3664/94/07/0483-09 :~{~'1994 B u t t e r w o r t h - H e i n e m a n n Ltd c o m p u t e r c o m m u n i c a t i o n s v o l u m e 17 n u m b e r 7 j u l y 1994
483
Generic interface to security services: J Linn
appropriate, an intermediate implementation 'veneer' which is oriented to a particular communication protocol (e.g. Remote Procedure Call (RPC)) may be interposed between applications which call that protocol and the GSS-API, thereby invoking GSS-API facilities in conjunction with that protocol's communications invocations. Protocol association independence: the GSS-API's security context construct is independent of communications protocol association constructs. This characteristic allows a single GSS-AP! implementation to be utilized by a variety of invoking protocol modules on behalf of those modules' calling applications. GSS-API services can also be invoked directly by applications, wholly independent of protocol associations. Suitability to a range of implementation placements: GSS-API clients are not constrained to reside within any Trusted Computing Base (TCB) perimeter defined on a system where the GSS-API is implemented; security services are specified in a manner suitable to both intra-TCB and extra-TCB callers.
Operational paradigm The GSS-API's operational role is illustrated in Figure 1. A GSS-API caller accepts tokens provided to it by its local GSS-API implementation and transfers the tokens to a peer on a remote system; that peer passes the received tokens to its local GSS-API implementation for processing. The GSS-API is independent of underlying protocols and addressing structure, and depends upon its callers to transport GSS-API-provided data elements. As a result of these factors, callers must parse communicated messages, so as to separate GSS-API data elements from caller-provided data. The GSS-API is independent of connection versus connectionless orientation of the underlying communications service. The GSS-API separates the operations of initializing a security context between peers, achieving peer entity authentication (GSS_Init sec context() and GSS_Accept sec context() calls), from the operations of providing per-message data origin authentication and data integrity protection (GSS_Sign0 and GSS_Verify0 calls) for messages subsequently transferred in conjuncCaller Protocol
]~
GSS-API Service Interface
v[
Caller Protocol
GSS-API Service Interface
222 Figure 1 GSS-API paradigm
484
]
tion with that context. Per-message GSS_Seal0 and GSS_Unseal() calls provide the data origin authentication and data integrity services which GSS_Sign() and GSS_Verify() offer, and also support the selection of confidentiality services as a caller option. Additional calls provide supportive functions to the GSS-API's users. Figure 2, discussed below, provides an example illustrating the dataflows involved in the use of the GSS-API by a client and server in a mechanismindependent fashion, establishing a security context and transferring a protected message. The example assumes that credential acquisition has already been completed. The example also assumes that the underlying authentication technology is capable of authenticating a client to a server using elements carried within a single token, and of authenticating the server to the client (mutual authentication) with a single returned token. The client calls GSS_Init sec context() to establish a security context to the server identified by targ_name, and elects to set the mutual_req_flag so that mutual authentication is performed in the course of context establishment. GSS_Init sec context() returns an output_token to be passed to the server, and indicates G S S _ C O N T I N U E _ N E E D E D status pending completion of the mutual authentication sequence. Had mutual_req_flag not been set, the initial call to GSS_Init sec context() would have returned GSS C O M P L E T E status. The client sends the output_token to the server. The server passes the received token to GSS_Accept_sec_context0. GSS_Accept_sec_context indicates G S S _ C O M P L E T E status, provides the client's authenticated identity, and provides an output_token to be passed to the client. The server sends the output_token to the client. The client passes the received token to a successor call to GSS_Init sec context(), which processes data included in the token to achieve mutual authentication from the client's viewpoint. This call to GSS_Init sec context() returns a G S S _ C O M P L E T E status, indicating successful mutual authentication and the completion of context establishment for this example. The client generates a data message and passes it to GSS_Seal0. GSS_Seal0 performs data origin authentication, data integrity and (optionally) confidentiality processing on the message and encapsulates the result into output_message, indicating a G S S _ C O M P L E T E status. The client sends the output_message to the server. The server passes the received message to GSS_Unseal0. GSS_Unseal inverts the encapsulation performed by GSS_Seal(), deciphers the message if the optional confidentiality feature was applied, and validates the data origin authentication and data integrity checking quantities. GSS_Unseal() indicates successful validation by returning G S S _ C O M P L E T E status along with the resultant output_message.
c o m p u t e r c o m m u n i c a t i o n s v o l u m e 17 number 7 july 1994
Generic interface to security services: J Linn Server G S S - A P I
Server
Client
Client G S S - A P I
_. targ_name, mutual_req~flag GS S_Ini t_sec_contextO output_token token
GSS_CONTINUE_NEEDED
inputtoken r
4
GSS Accept_sec_contextO output_token, src_name
token
GSS COMPLETE
GS S_Init_sec_contextO r
GSS_COMPLETE inputmessage GS S_SeaIO output_message
GSS_COMPLETE
message
input_message y
input_contexttoken
41
context token
GSS_UnsealO output_message
GSS COMPLETE
GS S_Process_context_tokenO
GSS_COMPLETE Figure 2 Example GSS-API dataflow
Recognizing that the example application's requirement for use of the security context is now complete, the server next calls GSS_Delete sec context() to flush context-level information. GSS_Delete sec context() returns a context_token for the server to pass to the client. The client passes the returned context_token to GSS_Process_context_token0, which returns G S S _ C O M P L E T E status after deleting context-level information at the client system.
GSS-API
constructs
This section describes the basic elements comprising the GSS-API. Credentials
Credentials structures provide the prerequisites enabling peers to establish security contexts with each other. The credential elements defined by a particular mechanism may contain multiple cryptographic keys, e.g. to enable authentication and message encryption to be performed with different algorithms. A single credential structure may accommodate credential information associated with multiple underlying mechanisms (mech_types); a credential structure's contents will vary depending upon the set of mech_types supported by a particular GSSAPI implementation. Underlying system-specific mechanisms and OS functions below the GSS-API must ensure that the ability to acquire and use credentials associated with a given identity is constrained to appropriate processes within a system. Implementors should take this respon-
sibility seriously, as the ability for an entity to utilize a principal's credentials is equivalent to the entity's ability to successfully assert that principal's identity. Once a set of GSS-API credentials is established, their transferability within a system is a local matter, not defined by the GSS-API. An example local policy would be one in which any credentials generated based on login to a given user account, or of delegation of rights to that account, are accessible by, or transferable to only processes running under that account. The credential establishment process (particularly when performed on behalf of users rather than server processes) is likely to require access to passwords or other quantities which should be protected locally and exposed for the shortest time possible. As a result, it will often be appropriate for preliminary credential establishment to be performed through local means at user login time, with the result(s) cached for subsequent reference. These preliminary credentials would be set aside (in a system-specific fashion) for subsequent use, either to be accessed by an invocation of the GSS-API GSS_Acquire_cred0 call, returning an explicit handle to reference that credential or as the default credentials installed on behalf of a process. Tokens
Tokens are data elements transferred between GSS-API callers, and are divided into two classes. Context-level tokens are exchanged to establish and manage a security context between peers. Per-message tokens are exchanged in conjunction with an established context to provide protective security services for corresponding data messages. Tokens' internal structures are defined by particular security mechanisms underlying GSS-API.
computer communications volume 17 number 7 july 1994
485
Generic interface to security services: J Linn
Tokens are opaque from the viewpoint of GSS-API callers. They are generated within the GSS-API implementation at an end system, provided to a GSS-API caller to be transferred to the peer GSS-API caller at a remote end system, and processed by the GSS-API implementation at that remote end system. Token transfer may take place in an in-band manner, integrated into the same protocol stream used by the GSSAPI callers for other data transfers, or in an out-ofband manner across a logically separate channel.
Security contexts Security contexts are established between peers, using credentials established locally for each peer or received by peers as a result of delegation. Multiple contexts may exist simultaneously between a pair of peers, using the same or different sets of credentials. Coexistence of multiple contexts using different credentials allows graceful rollover when credentials expire. Distinction among multiple contexts based on the same credentials serves applications by distinguishing different message streams in a security sense. No correlation between security context and communications protocol association is dictated. (An optional channel binding facility, discussed later in this paper, represents an intentional exception to this rule, supporting additional protection features within GSSAPI supporting mechanisms.) This separation allows the GSS-API to be used in a wide range of communications environments, and also simplifies the calling sequences of the individual calls. In many cases (depending upon the underlying security protocol, associated mechanism and availability of cached information), the state information required for context setup can be sent concurrently with initial signed user data, without interposing additional message exchanges.
Mechanism types To successfully establish a security context with a target peer, it is necessary to identify an appropriate underlying mechanism type (mech_type) which both initiator and target peers support. Mechanisms are identified, across the service interface and within transferred tokens, using Object Identifiers (OLD). It is recommended that callers initiating contexts specify the 'default' mech_type value, allowing system-specific functions within or invoked by the GSS-API implementation to select the appropriate mech_type, but callers may direct that a particular mech_type be employed when necessary. The means for identifying a shared mech_type to establish a security context with a peer will vary in different environments and circumstances; examples include (but are not limited to): •
486
use of a fixed mech_type, defined by configuration, within an environment
• •
•
syntactic convention on a target-specific basis, through examination of a target's name lookup of a target's name in a naming service or other database in order to identify mech_types supported by that target explicit negotiation between GSS-API callers in advance of security context setup
Naming The GSS-API avoids prescribing naming structures, treating the names transferred across the interface for context establishment as opaque objects. This approach supports the goal of implementation atop a range of underlying security mechanisms, and recognizes the fact that different mechanisms process and authenticate names which are presented in different forms. Primitives are defined to support a level of naming environment independence for certain calling applications, comparing internal-form names and translating them to and from printable representations for acceptance from and presentation to users.
Channel bindings The GSS-API accommodates the concept of callerprovided channel binding ('chan_binding') information, optionally used by GSS-API callers to bind the establishment of a security context to relevant characteristics (e.g. addresses, transformed representations of encryption keys) of the underlying communications channel and of protection mechanisms applied to that communications channel. Verification by one peer of chan_binding information provided by the other peer to a context serves to protect against various active attacks.
GSS-API features and issues This section describes aspects of GSS-API operations, of the security services which the GSS-API provides, and provides commentary on design issues.
Status reporting Each GSS-API call provides two status return values. Major_status values, defined in the GSS-API specification, provide a mechanism-independent indication of call status (e.g. GSS_COMPLETE, G S S _ F A I L U R E , G S S _ C O N T I N U E _ N E E D E D ) , sufficient to drive normal control flow within the caller in a generic fashion. Minor_status codes provide more detailed status information which may include status codes specific to the underlying security mechanism; their values are therefore defined in mechanism-level specifications. G S S _ C O N T I N U E _ N E E D E D major_status returns, and optional message outputs, are provided in GSS_Init sec context() and GSS_Accept sec context() calls so that different mechanisms' use of different
computer communications volume 17 number 7 july 1994
Generic interface to security services: J Linn
numbers of messages within their authentication sequences need not be reflected in separate code paths within calling applications. Instead, such cases are accommodated with sequences of continuation calls to GSS_Init sec context() and GSS_Accept_sec_context0.
across different mechanisms. Meaningful use of nondefault QoP values demands that callers be familiar with the QoP definitions of an underlying mechanism or mechanisms, and is therefore a non-portable construct.
Per-message security service availability
Contents of mechanism specifications
When a context is established, two flags are returned to indicate the set of per-message protection security services which will be available in the context: the integ_avail flag indicates whether per-message integrity and data origin authentication services are available, and the conf_avail flag indicates whether per-message confidentiality services are available. Certain underlying mech_types offer support for replay detection and/or sequencing of messages transferred on the contexts they support. These optionallyselectable protection features are distinct from replay detection and sequencing features applied to the context establishment operation itself; the presence or absence of context-level replay or sequencing features is wholly a function of the underlying mech_type's capabilities, and is not selected or omitted as a caller option. The caller initiating a context provides flags (replay_det_req_flag and sequence_req_flag) to specify whether the use of per-message replay detection ano sequencing features is desired on the context being established. The GSS-AP! implementation at the initiator system can determine whether these features are supported and optionally selectable as a function of mech_type, without the need for bilateral negotiation with the target. When enabled, these features provide indicators as a result of GSS-API processing of incoming messages, identifying whether those messages were detected as duplicates or out-of-sequence. Detection of such events does not prevent a suspect message from being provided to a recipient; the appropriate course of action on a suspect message is a matter of caller policy.
Development of GSS-API support primitives based on a particular underlying cryptographic technique and protocol does not necessarily imply that GSS-API callers invoking that GSS-API mechanism type will be able to interoperate with peers invoking the same technique and protocol outside the GSS-API paradigm. For example, the format of GSS-API tokens defined in conjunction with a particular mechanism, and the techniques used to integrate those tokens into callers' protocols, may not be the same as those used by nonGSS-API callers of the same underlying technique. To achieve interoperability between separately developed implementations of a mechanism, token formats and the semantics of token exchanges must be fully specified and conformantly implemented. To achieve caller portability across separately developed implementations, the set of supported name types and mechanism-level exception status codes must be fully specified and conformantly implemented. These values are defined in a GSS-API mechanism's specification. conformance to which is signified through use of the Object Identifier assigned in the specification.
Quality of protection Some mech_types provide their users with fine granularity control over the means used to provide permessage protection, allowing callers to trade off" security processing overhead dynamically against the protection requirements of particular messages. A permessage quality-of-protection parameter (analogous to quality-of-service - QoS) selects among different QoP options supported by that mechanism. On context establishment for a multi-QoP mech_type, context-level data provides the prerequisite data for a range of protection qualities. It is expected that the majority of callers will not wish to exert explicit mechanism-specific QoP control and will therefore request selection of a default QoP. Definitions of, and choices among, non-default QoP values are mechanism-specific, and no ordered sequences of QoP values can be assumed equivalent
INTERFACE ELEMENTS This section describes the GSS-API's service interface, dividing the set of calls offered into four groups. Credential management call.s" are related to the acquisition and release of credentials by principals. Contextlevel calla" are related to the management of security contexts between principals. Per-message calls are related to the protection of individual messages on established security contexts. Support calls provide ancillary functions useful to GSS-API callers.
Credential management calls These GSS-API calls provide functions related to the management of credentials. The GSS_Acquire_cred0 call is defined within the GSS-API in support of application portability, with a particular orientation towards support of portable server applications. [t is recognized that (for certain systems and mechanisms) credentials for interactive users may be managed differently from credentials for server processes; in such environments, it is the GSS-API implementation's responsibility to distinguish these cases, and the procedures for making this distinction are a local matter. The GSS_Release_credO call provides a means for callers to
computer communications volume 17 number 7 july 1994
487
Generic interface to security services: J Linn
indicate to the GSS-API that use of a credentials structure is no longer required. The GSS_Inquire_cred 0 call allows callers to determine information about a credentials structure.
required) with validation of data items related to authentication and integrity.
Support calls Context-level calls This group of calls is devoted to the establishment and management of security contexts between peers. A context's initiator calls GSS_Init sec context(), resulting in the generation of a token which the caller passes to the target. At the target, that token is passed to GSS_Accept_sec_context0. Depending upon the underlying mech_type and specified options, additional token exchanges may be performed in the course of context establishment; such exchanges are accommodated by GSS C O N T I N U E N E E D E D status returns from GSS_Init sec context() and GSS_Accept_sec_context0. Either party to an established context may invoke GSS_Delete sec context() to flush context information when a context is no longer required. GSS_Process_context_token 0 is used to process received tokens carrying context-level control information. GSS_Context_time() allows a caller to determine the length of time for which an established context will remain valid.
Per-message calls This group of calls is used to perform per-message protection processing on an established security context. These calls may be invoked by a context's initiator or by the context's target. The four members of this group should be considered as two pairs; the output from GSS_Sign 0 is properly input to GSS_Verify0, and the output from GSS_Seal0 is properly input to GSS_Unseal0. GSS_Sign 0 and GSS_Verify 0 support data origin authentication and data integrity services. When GSS_Sign0 is invoked on an input message, it yields a per-message token containing data items which allow underlying mechanisms to provide the specified security services. The original message, along with the generated per-message token, is passed to the remote peer; these two data elements are processed by GSS_Verify0, which validates the message in conjunction with the separate token. GSS_Seal0 and GSS_Unseal0 support callerrequested confidentiality in addition to the data origin authentication and data integrity services offered by GSS_Sign0 and GSS_Verify 0. GSS_Seal 0 outputs a single data element, encapsulating optionally enciphered user data as well as associated token data items. The data element output from GSS_Seal0 is passed to the remote peer and processed by GSS_Unseal() at that system. GSS_Unseal 0 combines decipherment (as 488
This group of calls provides support functions useful to GSS-API callers, independent of the state of established contexts. GSS_Display_status0 provides a means for callers to translate GSS-API-returned major and minor status codes into printable string representations. GSS_Indicate_mechs0 allows callers to determine the set of mechanism types available on the local system. GSS_Compare_name0 enables callers to compare two internal name representations for equality. GSS_Display_name0 enables callers to translate an internal name representation into a printable form with associated namespace type descriptor. GSS_Import_name0 allows callers to provide a printable name representation, designate the type of namespace in conjunction with which it should be parsed, and convert that printable representation to an internal form suitable for input to other GSS-API routines. GSS_Release_name0, GSS_Release_buffer0, and GSS_Release oid set() are used to release the internal storage associated with various GSS-API data elements.
MECHANISM-SPECIFIC SCENARIOS
EXAMPLE
This section provides illustrative overviews of the use of various candidate mechanism types to support the GSSAPI. These discussions are intended primarily for readers familiar with specific security technologies, demonstrating how GSS-API functions can be used and implemented by candidate underlying mechanisms. They should not be regarded as constrictive to implementations or as defining the only means through which GSS-API functions can be realized with a particular underlying technology, and do not demonstrate all GSS-API features with each technology.
Kerberos V5, single-TGT Login functions yield a Ticket-Granting Ticket (TGT) to the local realm Kerberos server, and the T G T is placed in a credentials structure for the client. The client calls GSS_Acquire_cred0 to acquire a cred_handle so as to reference the credentials for use in establishing security contexts. The client calls GSS_Init sec context(). If the requested service is located in a different realm, GSS_Init sec context() gets the necessary T G T and key pairs needed to traverse the path from local to target realm; these data are placed in the owner's T G T
computer communications volume 17 number 7 july 1994
Generic interface to security services: J Linn
cache. After any needed remote realm resolution, the GSS-API code supporting GSS_Init sec context() contacts the Kerberos ticket granting service, yielding a service ticket to the requested target service and a corresponding session key. These data are stored in conjunction with the context. GSS_Init sec context() constructs a Kerberos-formatted client- server message, and returns it to the caller in output_token. The client sends the output_token to the service. The service passes the received token as the input_token argument to GSS_Accept_sec_context0, which verifies the authenticator, provides the service with the client's authenticated name, and returns an output_context_handle. Both parties now hold the session key associated with the service ticket, and can use this key in subsequent GSS_Sign0, GSS_Verify0, GSS_SeaI0 and GSS_Unseal() operations.
X.509 authentication framework This example illustrates use of the GSS-API in conjunction with public-key mechanisms, consistent with the Directory Authentication Framework (X.509). In this environment, the GSS_Acquire_cred0 call establishes a credentials structure which makes the client's private key accessible for use on behalf of the client. The client calls GSS_Init sec context(), which interrogates the Directory to acquire (and validate) a chain of public-key certificates, thereby collecting the public key of the service. The certificate validation operation determines that suitable signatures were applied by trusted authorities and that those certificates have not expired. GSS_Init sec context() generates a secret key for use in per-message protection operations on the context, and enciphers that secret key under the service's public key. The enciphered secret key, along with an authenticator quantity signed with the client's private key, is included in the output_token from GSS_Init sec context(). The output_token also carries a certification path, consisting of a certificate chain leading from the service to the client: a variant approach would defer this path resolution to be performed by the service instead of being asserted by the client. The client application sends the output_token to the service. The service passes the received token as the input_token argument to GSS_Accept_sec_context0. GSS_Accept sec context() validates the certification path, and as a result determines a certified binding between the client's distinguished name and the client's public key. Given that public key, GSS_Accept sec context() can process the input_token's authenticator quantity and verify that the client's private key was used to sign the input_token. At this point, the client is authenticated to the service. The service uses its private key to
decipher the enciphered secret key provided to it for per-message protection operations on the context. The client calls GSS_Sign 0 or GSS_Seal0 on a data message, which causes per-message authentication, integrity and (optional) confidentiality facilities to be applied to that message. The service uses the context's shared secret key to perform corresponding GSS_Verify0 and GSS_Unseal() calls.
ISSUES AND LESSONS LEARNED
Evolutionary background The Internet Engineering Task Force (IETF) Common Authentication Technology (CAT) Working Group (WG) was chartered to pursue standardization of the GSS-API specifications and specifications for supporting mechanisms. When this working group was chartered, the fact was recognized that API definition is an unusual activity within a forum which has traditionally been oriented to specification of protocols rather than interfaces. Concurrent IETF interest in security mechanism development and in use of that development within Internet protocols provided rationale supporting this charter. When the CAT WG was chartered, two security technologies were under active development and targeted for the lnternet protocol standards track: Kerberos 2, based wholly on secret-key cryptography, and DASS 3, employing a hybrid of secret-key and public-key cryptography, including X.509 certificates. The GSS-API was conceived to support application portability between these underlying technologies as initial examples, with prospects open for later integration of other mechanisms under the GSS-API framework. Discussions were undertaken between the architects of Kerberos and DASS mechanisms refining approaches for a hybrid mechanism which would combine Kerberos and DASS features, enabling interoperability between secret-key and public-key domains. This activity yielded a perception that such integration would be technically feasible, but detailed specification or implementation of this concept has not yet been pursued.
Authorization support and delegation controls The current GSS-API does not include authorization decision-making facilities, given a recognition of the diverse set of models existing and planned in this functional area. A natural relationship exists, however, between the authentication function which is accomplished within GSS-API security context establishment and authorization decisions; it is natural to consider extensions which would make such decisions based on GSS-API contexts and/or authenticated names.
c o m p u t e r c o m m u n i c a t i o n s v o l u m e 17 number 7 july 1994
489
Generic interface to security services: J Linn
In a distributed computing environment, authentication must span different systems; the need for such authentication provides motivation for GSS-API definition and usage. Heterogeneous systems in a network can intercommunicate, with globally authenticated names comprising the common bond between locally defined access control policies. Access control policies to which authentication provides inputs are often local, or specific to particular operating systems or environments. If the GSS-API made particular authorization models visible across its service interface, its scope of application would become less general. The current GSS-API paradigm is consistent with the precedent set by Kerberos, neither defining the interpretation of authorization-related data nor enforcing access controls based on such data. Privilege Attribute Certificates (PAC), transferred along with authentication data to represent attributes of an authenticated principal, are a basic element of the authorization model used in the ECMA security model 4'5 and the OSF Distributed Computing Environment. In the GSS-API paradigm, such PACs could appropriately be transferred within context establishment tokens. Representation of PACs as mandatory elements at the level of the generic interface would, however, restrict the set of candidate GSS-API mechanisms, thereby reducing GSS-API's utility to integrators. Additional primitives have been defined for use in conjunction with the basic GSS-API in environments where PACs are supported. Delegation controls constitute another relevant area for GSS-API extension in support of authorization models. At the level of the basic GSS-API, visibility of delegation (the transfer of rights by a context initiator, enabling the target to act on the initiator's behalf) is limited to a Boolean, enabling or disabling the delegation facility. Definition of suitable and useful delegation constraints is an active work area at this time; lacking a current consensus on this topic, the interface definition does not attempt to model delegation controls in a mechanism-independent fashion. Any refinements to restrict the sets of group affiliations, other privileges to be delegated, or the sets of entities to which the results of a delegation are transferable, must be accomplished outside the interface through additional operations to be performed on credentials or contexts, and work is evolving on definitions for such operations.
S T A T U S AND ONGOING A C T I V I T I E S At the time of writing (October 1993), the GSS-API 6, its C bindings 7 and the Kerberos mechanism have reached the status of Internet Proposed Standard RFCs. The RFCs have formed the basis for a liaison with the Security Working Group of the X/Open Company Ltd, and their technical content is currently under considera490
tion for publication as an X/Open specification. Further work on usage and extension of GSS-API has been undertaken within Project SESAME 8. A number of prototype-level single-mechanism GSSAPI implementations have been developed, including the Massachusetts Institute of Technology (MIT) Kerberos Version 5 distribution and Digital Equipment Corporation's SPX public-key authentication system 9, based on the DASS architecture. A production-quality dual-mechanism implementation is being developed for inclusion in the Open Software Foundation (OSF) Distributed Computing Environment (DCE) l°, supporting DCE-specific security protocols (incorporating the Privilege Attribute Certificates (PAC) on which DCE's authorization model is based), as well as interoperability with the Kerberos V5 implementation. Other implementations are anticipated from a number of sources. Work is progressing in the IETF and other forums to use the GSS-API as a means to integrate security into applications. Current Internet work to secure File Transfer Protocol (FTP) and virtual terminal (Telnet) traffic, for example, incorporates provisions for the use of GSS-API. The current GSS-API specification reflects experience with single-mechanism implementations, and embodies a model which anticipates support for multiple mechanisms within an end system. Several multi-mechanism implementations are under development at the time of writing, yielding experience which will be reflected in subsequent interface refinements and extensions. Particular identified activities include: •
•
consideration of a 'negotiated' mechanism type, in which tokens are exchanged to identify a specific authentication technology shared between a pair of end systems; consideration of a lower-layer service provider interface residing beneath GSS-API to support modular development and incorporation of mechanism support facilities for integration within end systems.
ACKNOWLEDGEMENTS The evolution of the GSS-API has been the result of a collaborative effort involving numerous contributing individuals and organizations. It has been my privilege to be involved in this evolution within the Internet Engineering Task Force's Security Area Advisory Group (SAAG), its Common Authentication Technology (CAT) Working Group, in the X/Open Security Working Group, forums of the Open Software Foundation (OSF), and within Digital Equipment Corporation and OpenVision Technologies. I gratefully acknowledge all participants who have contributed to the GSS-API within these forums.
computer communications volume 17 number 7 july 1994
Generic interface to security services: J Linn
REFERENCES 6 l 2 3 4 5
ISO 9594-8, Information Processing Systems Open Systems Interconnection The Director), Authentication Framework, International Standard 9594-8, ISO, Geneva, Switzerland Kobl, J and Neuman, C The Kerberos Network Authentication Service (V5), RFC 1510, Digital Equipment Corporation, USC/ Information Sciences Institute (September 1993) Kaufman, C Distributed Authentication Security Service, RFC 1507, Digital Equipment Corporation (September 1993) European Computer Manufacturers Association, Securi O" in Open Systems: A Securit)' Framework, ECMA Technical Report TR/46 (July 1988) European Computer Manufacturers Association, Security in
7 8
9 10
Open Systems: Data Elements and Service Definitions, ECMA Standard ECMA-138 (December 1989) Linn, J Generic Security Service Application Program Interface, RFC 1508, Geer Zolot Associates (September 1993) Wray, J Generic Security Service API: C-bindings, RFC 1509, Digital Equipment Corporation (September 1993) McMahon, P V An Extended Generic Security Service API, ITAEGV Report NI61, Information Technology Advisory Group for Information Security, Rue de Stassart 36, 1050 Brussels. Belgium (May 1993) Tardo, J and Alagappan, K 'SPX: Global authentication using public key certificates', Proc. IEEE Symposium on Research h7 Security & Privacy, Los Amitos, CA (1991) pp 232 244 Open Software Foundation OSF DCE Application Development Guide: Revision 1.0, PTR Prentice Hall. Englewood Cliffs, NJ (1993)
c o m p u t e r c o m m u n i c a t i o n s v o l u m e 17 number 7 july 1994
491