Difference between revisions of "Projects/GSS-API preauth"

Revision as of 12:18, 9 August 2012

Background

The purpose of this Project is to implement the functionality described in draft-perez-krb-wg-gss-preauth-01, where GSS-API is used to carry out a pre-authentication process between the client and the KDC. That is, this would alow making use of any GSS-API mechanism (with some restrictions) to allow the client to authenticate with the KDC and to obtain a valid TGT.

The main motivation behind this pre-authentication functionality is to allow the use of the GSS-EAP mechanism (draft-ietf-abfab-gss-eap) to allow federated users accessing to resources protected by Kerberos making use of the AAA infrastructure. Nevertheless, this pre-authentication mechanism does not preclude any other GSS-API mechanism to be used, as long as it provides the required security services (see below).

Requirements

In order to implement the required functionality, the current KDC implementation needs to be modified to support multi-round trip pre-authentication mechanism. This can be easily achieved by just modifying a couple of lines in the base code (version 1.10.2):

File: kdc/kdc_preauth.c
@@ -1019,6 +1019,7 @@
     case KRB5KDC_ERR_DISCARD:
         /* pkinit alg-agility */
     case KRB5KDC_ERR_NO_ACCEPTABLE_KDF:
+    case KRB5KDC_ERR_MORE_PREAUTH_DATA_REQUIRED: /* Multi-round trip preauthentication */
         (*oldrespond)(oldarg, code);
         return;
     default:

File: lib/krb5/error_tables/krb5_err.et
@@ -132,7 +132,7 @@
 error_code KRB5PLACEHOLD_88,	"KRB5 error code 88"
 error_code KRB5PLACEHOLD_89,	"KRB5 error code 89"
 error_code KRB5PLACEHOLD_90,	"KRB5 error code 90"
-error_code KRB5PLACEHOLD_91,	"KRB5 error code 91"
+error_code KRB5KDC_ERR_MORE_PREAUTH_DATA_REQUIRED,	"More preauthentication data required"
 error_code KRB5PLACEHOLD_92,	"KRB5 error code 92"
 error_code KRB5KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTION, "An unsupported critical FAST option was requested"
 error_code KRB5PLACEHOLD_94,	"KRB5 error code 94"

Statelessness

In order to assure statelessness, and due how MIT Kerberos and MIT GSS-API are designed, the second approach described in draft-perez-krb-wg-gss-preauth-01 should be followed. That is, if the GSS mechanism requires more than one round-trip to be completed, the partially established security context is exported from the GSS-API and included into the pre-authentication element (PA-GSS).

The resulting PA-GSS would be something similar to this (ASN1 provided by Nico):

PA-GSS ::= {
    timestamp [0] KerberosTime,
    sec-ctx-token [1] OCTET STRING,
    state-kvno [2] Int32 OPTIONAL,
    state-cookie [3] OCTET STRING OPTIONAL
}
 

state-kvno and state-cookie would be absent on first AS_REQ and last AS_REP messages. Both timestamp and state-cookie fields would be encrypted first krbtgt key and a key usage in the 512-1023 range.

Reply key generation

Reply key is derived using the gss_pseudo_random call, obtaining enough material to completely replace the previously existing key. If gss_pseudo_random is not available by the current GSS mechanism, gss_get_mic could be used with that purpose (following a PRF+ procedure).

GSS-API credentials

The cname provided by the client in the kinit call is directly used to acquire the initial GSS credentials. However, some special considerations are required at this point:

1. Some GSS-API mechanism allow a federated authentication (e.g. GSS-EAP). This means that the cname introduced by the client is not present into the KDC database. In this situations, draft-perez-abfab-eap-gss-preauth-01 defines the use of WELLKNOWN:FEDERATED as the cname value. This way, the KDC knows that the client name will be provided by the GSS-preauth plugin at the end of the authentication. To implement this:
   1. In the KDC side we propose to just insert the principal WELLKNOW:FEDERATED with a random password (as the actual reply key will be derived from the gss_pseudo_random function), in a similar way as done with the WELLKNOWN:ANONYMOUS.
   2. In the client side, a new pre-auth option (e.g. -X federated) is used to indicate that client is in a federated environment, and that the provided cname MUST be replaced with WELLKNOWN:FEDERATED, while the actual cname is still used to acquire the credentials.
2. If the client wanted to use the default credentials for the GSS mechanism, he could use another pre-auth option (e.g. -X gss_default_cred) to indicated that NULL MUST be used as client name to acquire the initial credentials. Note that in this case, the provided cname will be still being used as the cname in the AS_REQ message.

For instance, to execute a GSS-EAP authentication with default credentials (for example, to lauch the moonshot's identity selector), both options should be indicated.

Allowed GSS-API mechanisms

Due to the previous restrictions, GSS-preauth can only work with those GSS-mechanism that:

1. Require only one round-trip to be compled, or support the exporting of partially established security contexts if more than one round-trip are required.
2. Implement gss_pseudo_random or provide the GSS_C_INTEG_FLAG service.
3. Are not able to trigger an additional AS_REQ exchange (as it may lead the pre-authentication process to get into an infinite loop).