logo_kerberos.gif

Difference between revisions of "Projects/Credential Store extensions"

From K5Wiki
Jump to: navigation, search
m (New APIs)
Line 5: Line 5:
 
== Background ==
 
== Background ==
   
During the development of the [https://fedorahosted.org/gss-proxy GSS-Proxy project] in connection with the [[Projects/ProxyGSSAPI]] project it became evident that the application implementing the proxy needs to be able to be configured to use different credentials depending on what application is connecting to the proxy.
+
During the development of the [https://fedorahosted.org/gss-proxy GSS-Proxy project] in connection with the [[Projects/ProxyGSSAPI]] project it became evident that the application implementing the proxy needs to be able to be configured to use different credentials depending on what application is connecting to the proxy. Using the normal defaults of GSSAPI is not possible because the proxy application does not run in the same process environment as the proxied application, and may run multiple concurrent tasks on behalf of different applications with different trust/credentials.
Using the normal defaults of GSSAPI is not possible because the proxy application does not run in the same security context as the proxied application and it may run multiple concurrent tasks on behalf of different applications with different trust/credentials.
 
   
A method to pass a set of default credentials to use on behalf of these application is necessary. This method should not be mechanism specific, as the proxy tries to be mechanism agnostic as much as possible.
+
A method to pass a set of default credentials to use on behalf of these application is necessary. This method should not be mechanism-specific, as the proxy tries to be mechanism-agnostic as much as possible.
   
 
In this light a 'Credential Stores' Extension has been [http://www.ietf.org/mail-archive/web/kitten/current/msg03013.html proposed] on the Kitten IETF Mailing list.
 
In this light a 'Credential Stores' Extension has been [http://www.ietf.org/mail-archive/web/kitten/current/msg03013.html proposed] on the Kitten IETF Mailing list.
Line 14: Line 14:
   
 
* Abstract interface to pass credential store configuration to GSSAPI mechanisms.
 
* Abstract interface to pass credential store configuration to GSSAPI mechanisms.
* The credentials need to be specified in configuration files so no security sensitive information (like passwords) must be exposed there.
+
* The credentials need to be specified in configuration files, so security sensitive information (like passwords) must not be exposed there.
* Mechanisms can define their own key/value pairs
+
* Mechanisms can define their own key/value pairs.
* New Key/Value pairs can be easily added in future
+
* New Key/Value pairs can be easily added in future.
* The actual API need not to know how to interpret Key/Value pairs, they are passed directly to mechanisms
+
* The mechglue need not to know how to interpret key/value pairs; they are interpreted only by mechanisms.
   
 
== Architecture ==
 
== Architecture ==
   
The exposed public functions are paired with an analogous one in the mechglue SPI to give mechanisms access to the Credentials Store.
+
The exposed public functions are paired with analogous functions in the mechglue SPI to give mechanisms access to the Credentials Store.
The implementation provides functions only for mechanisms for which it makes sense, initially krb5 but not SPNEGO
+
The implementation provides functions only for mechanisms for which it makes sense--initially krb5 but not SPNEGO.
   
 
== New APIs ==
 
== New APIs ==
Line 35: Line 35:
 
* gss_cred_store_struct
 
* gss_cred_store_struct
   
If the cred store structure does not contain a mechanism specific configuration for the mechanism at hand, the usual defaults are applied.
+
If the cred store structure does not contain a mechanism-specific configuration for the mechanism at hand, the usual defaults are applied.
   
   
=== gss_aqcuire_cred_from() ===
+
=== gss_acquire_cred_from() ===
   
Acquires new credentials using the provided store. The store can specify both the actual credentials and/or the credential cache.
+
Acquires new credentials using the provided store. The store can specify both the actual credentials and/or the credential cache.
In the Krb5 mechanism case it could specify a keytab and a ccache location.
+
In the krb5 mechanism case it could specify a keytab and a ccache location.
   
 
=== gss_add_cred_from() ===
 
=== gss_add_cred_from() ===
   
Same as above but can target a specific mechanism. The credential store need not be mechanism specific and re mains abstract.
+
Same as above, but can target a specific mechanism. The credential store need not be mechanism-specific and remains abstract.
   
 
=== gss_strore_cred_into() ===
 
=== gss_strore_cred_into() ===
   
This is analogous to gss_cred_store() except that a specific credential store can be specified (In the krb5 case generally a ccache file).
+
This is analogous to gss_cred_store() except that a specific credential store can be specified (in the krb5 case, generally a ccache file).
   
 
=== gss_cred_store_element_struct ===
 
=== gss_cred_store_element_struct ===

Revision as of 15:19, 4 May 2012

This is an early stage project for MIT Kerberos. It is being fleshed out by its proponents. Feel free to help flesh out the details of this project. After the project is ready, it will be presented for review and approval.


This project is about adding a set of extensions to GSSAPI to more easily handle credentials in a mechanism agnostic way.

Background

During the development of the GSS-Proxy project in connection with the Projects/ProxyGSSAPI project it became evident that the application implementing the proxy needs to be able to be configured to use different credentials depending on what application is connecting to the proxy. Using the normal defaults of GSSAPI is not possible because the proxy application does not run in the same process environment as the proxied application, and may run multiple concurrent tasks on behalf of different applications with different trust/credentials.

A method to pass a set of default credentials to use on behalf of these application is necessary. This method should not be mechanism-specific, as the proxy tries to be mechanism-agnostic as much as possible.

In this light a 'Credential Stores' Extension has been proposed on the Kitten IETF Mailing list.

Requirements

  • Abstract interface to pass credential store configuration to GSSAPI mechanisms.
  • The credentials need to be specified in configuration files, so security sensitive information (like passwords) must not be exposed there.
  • Mechanisms can define their own key/value pairs.
  • New Key/Value pairs can be easily added in future.
  • The mechglue need not to know how to interpret key/value pairs; they are interpreted only by mechanisms.

Architecture

The exposed public functions are paired with analogous functions in the mechglue SPI to give mechanisms access to the Credentials Store. The implementation provides functions only for mechanisms for which it makes sense--initially krb5 but not SPNEGO.

New APIs

Functions:

  • GSS_Acquire_cred_from()
  • GSS_Add_cred_from()
  • GSS_Store_cred_into()

Structures:

  • gss_cred_store_element_struct
  • gss_cred_store_struct

If the cred store structure does not contain a mechanism-specific configuration for the mechanism at hand, the usual defaults are applied.


gss_acquire_cred_from()

Acquires new credentials using the provided store. The store can specify both the actual credentials and/or the credential cache. In the krb5 mechanism case it could specify a keytab and a ccache location.

gss_add_cred_from()

Same as above, but can target a specific mechanism. The credential store need not be mechanism-specific and remains abstract.

gss_strore_cred_into()

This is analogous to gss_cred_store() except that a specific credential store can be specified (in the krb5 case, generally a ccache file).

gss_cred_store_element_struct

A urn/value pair. Example: URN = 'ccache' Value = 'FILE:/tmp/somecc'

gss_cred_store_struct

A counter and an array of elements.

C bindings

/* Extension for credential stores */
typedef struct gss_cred_store_element_struct {
    const char *urn;
    const char *value;
} gss_cred_store_element, *gss_cred_store_element_t;
typedef const struct gss_cred_store_element gss_const_cred_store_element_t;

typedef struct gss_cred_store_struct {
    OM_uint32 count;
    gss_const_cred_store_element_t *elements;
} gss_cred_store, *gss_cred_store_t;
typedef const struct gss_cred_store_struct *gss_const_cred_store_t;
#define GSS_C_NO_CRED_STORE ((gss_const_cred_store_t) 0)
OM_uint32 gss_acquire_cred_from(
            OM_uint32 *minor_status,
            const gss_name_t desired_name,
            OM_uint32 time_req,
            const gss_OID_set desired_mechs,
            gss_cred_usage_t cred_usage,
            gss_const_cred_store_t cred_store,
            gss_cred_id_t *output_cred_handle,
            gss_OID_set *actual_mechs,
            OM_uint32 *time_rec);
OM_uint32 gss_add_cred_from (
            OM_uint32 *minor_status,
            const gss_cred_id_t input_cred_handle,
            const gss_name_t desired_name,
            const gss_OID desired_mech,
            gss_cred_usage_t cred_usage,
            OM_uint32 initiator_time_req,
            OM_uint32 acceptor_time_req,
            gss_const_cred_store_t cred_store,
            gss_cred_id_t *output_cred_handle,
            gss_OID_set *actual_mechs,
            OM_uint32 *initiator_time_rec,
            OM_uint32 *acceptor_time_rec);
OM_uint32 gss_store_cred_into(
              OM_uint32         *minor_status,
              gss_cred_id_t     input_cred_handle,
              gss_cred_usage_t  cred_usage,
              const gss_OID     desired_mech,
              OM_uint32         overwrite_cred,
              OM_uint32         default_cred,
              gss_const_cred_store_t cred_store,
              gss_OID_set       *elements_stored,
              gss_cred_usage_t  *cred_usage_stored);