logo_kerberos.gif

Projects/GSS-API preauth

From K5Wiki
< Projects
Revision as of 03:51, 3 August 2012 by Aperez (talk | contribs) (New page: {{project-early}} == 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-a...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
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.


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, the partially established security context is exported from the GSS-API and included into the PA-FX-COOKIE element.

For security reasons, this PA-FX-COOKIE should be encrypted and should contain a timestamp to reduce the chance of replay attacks. --Aperez 08:51, 3 August 2012 (UTC): Do all the KDCs of the same realm share a static key that can be used to encrypt and HMAC this information?


Reply key generation

Federated users

Allowed GSS-API mechanism