Projects/Initial creds improvements - Revision history

Ghudson: /* Background */

2017-01-31T04:05:02Z

‎Background

Ghudson: /* Proper scoping of per-request preauth data */

2017-01-31T04:02:20Z

‎Proper scoping of per-request preauth data

Ghudson: /* Stage tracking for clpreauth modules */

2016-12-12T18:36:38Z

‎Stage tracking for clpreauth modules

Ghudson: /* Proper scoping of per-request preauth data */

2016-12-12T16:17:12Z

‎Proper scoping of per-request preauth data

Ghudson at 16:45, 26 May 2016

2016-05-26T16:45:03Z

Ghudson at 16:03, 29 July 2015

2015-07-29T16:03:21Z

Ghudson: /* Background */

2015-07-27T04:16:28Z

‎Background

Ghudson: Projects/Initial creds stage tracking moved to Projects/Initial creds improvements

2015-07-24T15:56:24Z

Projects/Initial creds stage tracking moved to Projects/Initial creds improvements

Ghudson: /* Background */

2015-07-24T15:55:11Z

‎Background

Ghudson: /* clpreauth module control of conversation termination */

2015-06-25T04:11:56Z

‎clpreauth module control of conversation termination

@@ Line 9: / Line 9: @@
 The current code has the following limitations, most of which do not arise in current pre-authentication scenarios:
-* If two krb5_init_creds_step() operations are interleaved using the same krb5_context, they erroneously share per-request per-module data pointers, which may confuse clpreauth modules.  (They also share the "tried" list which tracks previously tried mechanisms, but that list is not currently doing much.)  {{bug|7877}}
+* If two krb5_init_creds_step() operations are interleaved using the same krb5_context, they erroneously share per-request per-module data pointers, which may confuse clpreauth modules.  (They also share the "tried" list which tracks previously tried mechanisms, but that list is not currently doing much.)  {{bug|7877}} [now fixed]
 * Support for optimistic preauth is very limited.  It must be initiated by the calling application, not by configuration, and there is no way to specify salt or s2kparams for producing the reply key.  We currently retry optimistic preauth after realm referrals and other conversation restarts, which may be unnecessarily complicated.

@@ Line 31: / Line 31: @@
 The per-request krb5_clpreauth_modreq pointers for each module should be maintained in an object separate from krb5_preauth_context.  This object should be linked from krb5_init_creds_context.
-The "tried" list is currently unused and should be removed.  A list of preauthentication mechanisms which have failed should be maintained separately from preauth state.
+The "tried" list is currently unused and should be removed.  A list of preauthentication mechanisms which have failed should be maintained in the per-request preauth state.
 ===Optimistic preauth===

← Older revision		Revision as of 18:36, 12 December 2016
Line 62:		Line 62:

	The stage should be made available to clpreauth modules via a callback. During the process method, only stages 1, 3, 4, and 6 will be possible; during the tryagain method, only stage 5 will be possible.		The stage should be made available to clpreauth modules via a callback. During the process method, only stages 1, 3, 4, and 6 will be possible; during the tryagain method, only stage 5 will be possible.
		+
		+	Alternatively, we could create four new clpreauth methods corresponding to the four stages currently served by the process method. These new methods could have shorter signatures if we omit some of the parameters (opt, request, encoded_request_body, encoded_previous_request) and make them available via callbacks. If a module does not supply one of the new methods, preauth2.c would fall back to the process method.

	===clpreauth module control of mechanism termination===		===clpreauth module control of mechanism termination===

@@ Line 29: / Line 29: @@
 ===Proper scoping of per-request preauth data===
-The per-request krb5_clpreauth_modreq pointers for each module should be maintained an object separate from krb5_preauth_context.  This object should be linked from krb5_init_creds_context.
+The per-request krb5_clpreauth_modreq pointers for each module should be maintained in an object separate from krb5_preauth_context.  This object should be linked from krb5_init_creds_context.
 The "tried" list is currently unused and should be removed.  A list of preauthentication mechanisms which have failed should be maintained separately from preauth state.

← Older revision		Revision as of 16:45, 26 May 2016
Line 54:		Line 54:

	We should maintain a list of preauth mechanisms which have failed so that we don't try them again. This list should be separate from the KDC METHOD-DATA and the preauth request state, as we should not retry a failed preauth mechanism after KDC_ERR_PREAUTH_EXPIRED. This list should be discarded on a realm referral, although a realm referral during a preauthentication conversation should be rare. A KDC_ERR_PREAUTH_EXPIRED error should not count as failing. Optimistic preauthentication failure should not count either, as it may only have failed for lack of information from the KDC.		We should maintain a list of preauth mechanisms which have failed so that we don't try them again. This list should be separate from the KDC METHOD-DATA and the preauth request state, as we should not retry a failed preauth mechanism after KDC_ERR_PREAUTH_EXPIRED. This list should be discarded on a realm referral, although a realm referral during a preauthentication conversation should be rare. A KDC_ERR_PREAUTH_EXPIRED error should not count as failing. Optimistic preauthentication failure should not count either, as it may only have failed for lack of information from the KDC.
		+
		+	A preauth mechanism may set the reply key as an output. Currently we store this output in the same state variable as is used to cache the gak_fct result. We will need to use a separate variable to support continuing after a preauth mechanism fails, so that we can clear the reply key used by the previous mechanism without also invalidating the gak_fct cached result (and therefore perhaps asking for the password again).

	===Stage tracking for clpreauth modules===		===Stage tracking for clpreauth modules===

← Older revision		Revision as of 16:03, 29 July 2015
Line 14:		Line 14:

	* If a preauth mechanism fails (even during optimistic preauth), we do not continue on to other mechanisms, unless it failed on the client side during method-data processing.		* If a preauth mechanism fails (even during optimistic preauth), we do not continue on to other mechanisms, unless it failed on the client side during method-data processing.
		+
		+	* If we receive a PREAUTH_FAILED error from the KDC with e-data containing METHOD-DATA (as is recommended for KDCs in RFC 6113), we invoke clpreauth module tryagain methods, which is fruitless and can obscure error messages.

	* clpreauth modules do not get much information about the padata they are processing. It could be from optimistic preauth, from KDC METHOD-DATA in a PREAUTH_REQUIRED error, from KDC METHOD-DATA in a MORE_PREAUTH_DATA_REQUIRED error, or from an AS-REP. (Other KDC errors are handled via the tryagain method, so those are distinguishable.)		* clpreauth modules do not get much information about the padata they are processing. It could be from optimistic preauth, from KDC METHOD-DATA in a PREAUTH_REQUIRED error, from KDC METHOD-DATA in a MORE_PREAUTH_DATA_REQUIRED error, or from an AS-REP. (Other KDC errors are handled via the tryagain method, so those are distinguishable.)

@@ Line 19: / Line 19: @@
 * clpreauth modules cannot indicate that they expect additional padata values before the mechanism is complete.  In the middle of a conversation, a KDC could issue an AS-REP with no padata and the client would try to decrypt it with whatever the reply key currently is.  This limitation has no current security consequences, but could become important in the future.
-* The preferred_preauth_types realm variable is a hack; the order of KDC padata should be the preferred order.  However, it is important to keep trying PKINIT first by default as current KDCs do not always put it before encrypted timestamp when they ought to.
+* The preferred_preauth_types realm variable is a hack; the order of KDC padata should be the preferred order.  However, it is important to keep trying PKINIT first by default as KDCs do not always put it before encrypted timestamp when they ought to.
 ==Improvements==

← Older revision	Revision as of 15:56, 24 July 2015
(No difference)

← Older revision		Revision as of 04:11, 25 June 2015
Line 57:		Line 57:
	The stage should be made available to clpreauth modules via a callback. During the process method, only stages 1, 3, 4, and 6 will be possible; during the tryagain method, only stage 5 will be possible.		The stage should be made available to clpreauth modules via a callback. During the process method, only stages 1, 3, 4, and 6 will be possible; during the tryagain method, only stage 5 will be possible.

−	===clpreauth module control of ~~conversation~~ termination===	+	===clpreauth module control of mechanism termination===

−	TBD
		+	We can add a callback for clpreauth modules to indicate that the mechanism is unfinished; the module would then be responsible for unsetting the flag via the same callback when the mechanism is complete. If the mechanism is incomplete after AS-REP padata processing, the client would abort the exchange.