Projects/IAKERB - Revision history

TomYu at 22:05, 30 April 2010

2010-04-30T22:05:25Z

2010-04-30T21:37:44Z

2010-04-30T21:37:15Z

2009-11-17T18:55:51Z

‎Open issues

2009-11-17T18:03:41Z

‎TGS

2009-11-17T18:02:32Z

‎krb5_init_creds_init

2009-11-17T18:00:43Z

‎TGS

2009-11-17T17:59:23Z

‎SPNEGO mech

2009-11-17T17:58:30Z

‎Open issues

2009-11-17T17:54:21Z

‎Architecture

← Older revision		Revision as of 22:05, 30 April 2010
Line 1:		Line 1:
−	{{project-~~completed~~}}	+	{{project-rel\|1.9}}
−
−	<includeonly>[[Category: early stage projects]]</includeonly>

	==Background==		==Background==

← Older revision		Revision as of 21:37, 30 April 2010
Line 1:		Line 1:
−	{{project-~~complete~~}}	+	{{project-completed}}

	<includeonly>[[Category: early stage projects]]</includeonly>		<includeonly>[[Category: early stage projects]]</includeonly>

@@ Line 1: / Line 1: @@
-{{project-early}}
+{{project-complete}}
 <includeonly>[[Category: early stage projects]]</includeonly>
@@ Line 261: / Line 261: @@
 ==Open issues==
 ==Status==

@@ Line 261: / Line 261: @@
 ==Open issues==
-The KDC must support referrals for cross-realm operation.
+The KDC must support referrals for cross-realm operation. We probably need to fix this before merging, but the author of the IAKERB implementation is not volunteering to do this.
 ==Status==

@@ Line 140: / Line 140: @@
 ====TGS====
-New APIs are required to acquire credentials asynchronously using a TGT. Equivalent functionality does not exist elsewhere, but they are modelled on the synchronous APIs and on the initial credentials asynchronous APIs. Note the synchronous APIs are not yet factored in terms of these, because of the referrals-only limitation mentioned previously. However the code duplicate is minimal: the entire asynchronous ticket acquisition implementation is about 400 lines of code.
+New APIs are required to acquire credentials asynchronously using a TGT. Equivalent functionality does not exist in Heimdal, but they are modelled on the synchronous APIs and on the initial credentials asynchronous APIs. Note the synchronous APIs are not yet factored in terms of these, because of the referrals-only limitation mentioned previously. However the code duplicate is minimal: the entire asynchronous ticket acquisition implementation is about 400 lines of code.
 ===== krb5_tkt_creds_init=====

@@ Line 101: / Line 101: @@
 </pre>
-Initialise a new context for acquiring initial credentials asynchronously.
+Initialise a new context for acquiring initial credentials asynchronously. Note: the context retains a pointer to ccache; ccache must be valid for the lifetime of the context.
 =====krb5_init_creds_step=====

← Older revision		Revision as of 18:00, 17 November 2009
Line 190:		Line 190:

	Perform the next step of asynchronous credentials acquisition. The in buffer should be empty on the first call; on subsequent calls it must be set to the KDC reply. The out buffer is to be sent by the caller to the KDC, for the indicated realm. Once the credentials have been acquired, the out buffer is empty and flags is set to 1. If the request should be retried with TCP, KRB5KRB_ERR_RESPONSE_TOO_BIG is returned.		Perform the next step of asynchronous credentials acquisition. The in buffer should be empty on the first call; on subsequent calls it must be set to the KDC reply. The out buffer is to be sent by the caller to the KDC, for the indicated realm. Once the credentials have been acquired, the out buffer is empty and flags is set to 1. If the request should be retried with TCP, KRB5KRB_ERR_RESPONSE_TOO_BIG is returned.
		+
		+	=====krb5_tkt_creds_free=====
		+
		+	<pre>
		+	void KRB5_CALLCONV
		+	krb5_tkt_creds_free(krb5_context,
		+	krb5_tkt_creds_context);
		+	</pre>
		+
		+	Free a krb5_tkt_creds_context.

	===GSS===		===GSS===

@@ Line 224: / Line 224: @@
 ====SPNEGO mech====
-The SPNEGO mechanism was modified to handle multiple leg context exchanges. There appeared to be some bugs here.
+The SPNEGO mechanism appeared to have a bug with multiple-leg exchanges, resolved by the following patch:
 ===gss-sample===

← Older revision		Revision as of 17:58, 17 November 2009
Line 231:		Line 231:

	==Open issues==		==Open issues==
		+
		+	The KDC must support referrals for cross-realm operation.

	==Status==		==Status==

@@ Line 13: / Line 13: @@
 IAKERB specifies a mechanism by which a GSS initiator can proxy KDC messages via a GSS acceptor. In order to do this, we must separate the client-side processing of KDC messages from their transmission to the KDC. This requires as asynchronous interface to the credentials acquisition functions, one which does not call sendto_kdc() but instead returns a buffer that can be forwarded to the acceptor.
-The IAKERB exchange consists of the aforementioned KDC exchange, wrapped in a IAKERB token (which contains the realm to which to send the request and an optional cookie). A checksum of the entire IAKERB conversation is included in the GSS checksum. Once the IAKERB exchange is complete, the Kerberos mechanism proceeds as normal. If the client already has credentials for the target service, the IAKERB exchange may be skipped entirely. If the client already has a TGT, then the AS-REQ may be skipped.
+The IAKERB exchange consists of the aforementioned KDC exchange, wrapped in a IAKERB token (which contains a header indicating the realm to which to send the request and an optional cookie). A checksum of the entire IAKERB conversation is included in the GSS checksum. Once the IAKERB exchange is complete, the Kerberos mechanism proceeds as normal. If the client already has credentials for the target service, the IAKERB exchange may be skipped entirely. If the client already has a TGT, then the AS-REQ may be skipped.
 ==Implementation==