Difference between revisions of "Projects/GSS-API preauth"
(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...) |
(→Reply key generation) |
||
| Line 40: | Line 40: | ||
== Reply key generation == |
== 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). |
||
== Federated users == |
== Federated users == |
||
Revision as of 03:58, 3 August 2012
Contents
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
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).
