Authentication and credentials

The first step, before any secure communications can take place, is for the principals involved to properly authenticate themselves. Once authenticated credentials needed for further interactions can be obtained. Credentials are used by a principal when initiating GSS-API-based services. However, GSS does not deal with, and is not intended to deal with, how a principal obtains credentials.

In our architecture, the basis for all security services is the framework specified in ECMA-219 [ECM96].

Figure 3.2 shows the components involved for establishing a set of credentials for a principal. Within the figure a number of trusted objects are indicated. The objects are trusted in the sense that we assume that a principal cannot disrupt their operation or otherwise access them other than through an interface devised for that purpose.

Furthermore, prudent security policies would mandate that the server objects implementing security services within the framework of ECMA-219 should be further protected by being placed on a machine that is physically secured, and that does not allow ordinary principals any access, except through the server interfaces.

  
Figure 3.2: Entities involved in establishing a principal's credentials.

In the figure, a user wishes to be authenticated and then wants to invoke an application that will interact with a remote server. We will return to the object labeled GSS-API proxy in section 3.4. For now, it is sufficient to know that it is this object that provides an interface to GSS-API services to applications on the local machine. The exchanges and events illustrated by the figure are as follows:

1. A human user initiates operations by authenticating herself to the system. The object responsible for interactions with the user is called user sponsor. The user sponsor determines what information is needed for proper identification according to the current security policy and requests this information from the user. In many cases this is a password known by the user. In more sensitive environments, the user might also be required to present a smart card or perform some kind of biometric identification.

   The user sponsor is a trusted application that does not divulge or unnecessarily store passwords and other sensitive information.

2. The user sponsor serves as a front end to the ECMA-219-compliant services provided by the local APA-client (APA stands for Authentication and Privilege Attributes). The APA-client maintains per user security information and is responsible for initiating a local session as well. Through a local session, an authenticated user can interact with the system, using acquired credentials to invoke other services.

   The design of the user/local session interface is system dependent. If APA-services have been integrated with operating system security, a user perceives little difference from interacting with an ordinary workstation. In other implementations, the user typically interacts with a specially tailored shell program. This program makes sure that credentials obtained through authentication with APA-services are not directly available to someone who can impersonate the user's identity.

3. The APA-client uses the information supplied by the user through the user sponsor to contact the APA authentication server. This exchange takes place according to some established authentication protocol, such as Kerberos (see section 7.6).

4. Upon successful authentication, the authentication server sends an Authentication Certificate, AUC, back to the APA-client. The AUC contains proof of the principal's identity. The AUC is protected by applying cryptographic protection methods. This is done in such a way that the AUC
   
   is usable only
   
   for someone who possesses a key derived from the information supplied by the user sponsor. Thus, only the APA-client with which the user sponsor has communicated can successfully use the AUC.

5. Having obtained the AUC, the APA-client can initiate a session for the user.

6. When the user, through the session, invokes a client application that wants to establish secure communications, the application requests from the APA-client a set of privilege attributes. The client application needs credentials that allows it to access the GSS-API proxy.

7. The APA-client uses the AUC associated with the session that invoked the application to request from the APA Privilege Attribute Server, PAS, the necessary attributes.

8. Having verified the AUC, the PAS returns a Privilege Attribute Certificate, PAC, to the APA-client.

9. The PAC is passed on to the client application ...

10. ... that uses the PAC when it calls the GSS-API proxy to request that a Security Context is established between itself and the remote party.

As we can see, the key security-related objects on the client machine are:

The user sponsor

that is the object acting as an intermediary between the user and the local security object.

The APA-client

which is a collective name given to the local security object. The APA-client is responsible for interacting with central APA servers. The APA-client is also responsible for maintaining security-related information. In our design, the APA-client is responsible for instantiating session objects as well.

The sessions

which are the objects that provide users with secure access to resources.

The GSS-API proxy

which is the object that provides an interface that gives local applications access to GSS-API security services.

The services provided by the APA-client and the APA-servers are specified in ECMA-219. The standard also describes in more detail what information flows between these objects.