Subject: RE: IAKERB draft

From: "Linn, John" <[email-masked]>
Date: Wed, 19 Nov 1997 12:25:03 -0500

David Margrave writes, excerpting:

> To summarize and expand on what's been discussed up to now (my
> additions/remarks noted with *** instead of - ): 
> 
> - The proposed extensions for initial authentication will be
> implemented within the existing mechanism with the OID {iso(1)
> member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
> krb5(2)}. 
> 
I believe that this is a different (superset) protocol from RFC-1964 and
should be identifiably distinguished from it with a different OID. 

> - The AS and TGS exchanges are optional.  Implementations supporting
> the IAKERB extensions shall be backward compatible with applications
> written to Kerberos V5 GSS-API implementations which do not attempt to
> make use of IAKERB extensions. 
> 
> *** Kerberos V5 GSS-API implementations which do not support IAKERB
> should return an appropriate error message (GSS_S_CALL_BAD_STRUCTURE,
> GSS_S_DEFECTIVE_TOKEN, or GSS_S_FAILURE) when gss_init_sec_context or
> gss_accept_sec_context() is called with an IAKERB credential retrieval
> token as input_token.  
> 
> *** The caller shall be responsible for supplying a properly formatted
> IAKERB credential retrieval token as input_token on the initial call
> to gss_init_sec_context(), or optionally to specify
> GSS_C_NULL_CREDENTIAL for claimant_cred and GSS_C_NULL_BUFFER for
> input_token to use the default credentials.  If input_token is
> supplied, gss_init_sec_context() will perform consistency checks on
> input_token and on success, return the identical token in output_token
> and return GSS_S_CONTINUE_NEEDED.  If the token is valid, the initial
> call to gss_init_sec_context will essentially be a no-op, but it
> should be structured this way to preserve the logic of looping while
> GSS_S_CONTINUE_NEEDED is returned. 
> 
The proposed behavior of passing an input_token to the initial call to
gss_init_sec_context() conflicts with RFC-2078, which states that
gss_init's input_token argument is significant only on a continuation
call, and that the input_token argument, when used, carries a token
received from the target.  Existing implementations, therefore, might
not behave predictably if presented with an input_token on an initial
call. 

> 	*** If the initiator has no TGT and no service ticket for the
> context acceptor in the same realm, then the caller then the caller
> shall be required to supply a valid IAKERB credential retrieval token
> as input_token, containing an AS-REQ message for the krbtgt/REALM
> service, OR containing an AS-REQ message for the context acceptor's
> service principal.  How the caller chooses to generate the input_token
> shall be implementation specific. On success, output_token will return
> the same token as input_token (an embedded AS-REQ message for the
> krbtgt/REALM service , OR an AS-REQ message for the end-service) and
> gss_init_sec_context() will return GSS_CONTINUE_NEEDED. 
> 
If the caller needs to generate/supply mechanism-specific info, I'd
recommend that this be accomplished via a mechanism-specific extension
routine rather than by having the caller construct a token to be passed
to gss_init; it seems anomalous to me to declare a special,
mechanism-specific exception to the general premise that tokens are
generated and processed within GSS mechanisms and that their content is
opaque to callers. 

--jl

---

From: [email-masked]
Date: Thu, 20 Nov 1997 02:04:05 -0500

From: "Linn, John" <[email-masked]>
   Date: Wed, 19 Nov 1997 12:25:03 -0500

I agree; we need to use a different OID so that we can distinguish
implementations that supports this new protocol from those that don't.

   > gss_accept_sec_context() is called with an IAKERB credential retrieval
	...

When I looked at this section, it seemed to me that this was all taken
from some kind of implementation spec, and had a lot of
implementation-specific details that weren't really relevant to a
protocol specification.  

I agree with you that the practice of passing an input_token to the
initial call to gss_init_sec_context() is probably a really bad idea.

The way I'd suggest doing this is to create a Krb5 specific call that
stashed the username/realm (i.e., krb5 principal) and password into a
GSSAPI credential.  When the gss_cred_handle_t is passed into
gss_init_sec_context, a side effect of the call would be to convert the
gss_cred_handle_t into a "normal" krb5 GSSAPI Credential.  

In practice, I'd implement this by adding a password field into the
internal krb5 gssapi credential (the internal krb5 gssapi credential
contains a krb5 principal already).  In the course of the
gss_init_sec_context(), the call would create a krb5 credentials cache,
and place the krb5 tickets into the rkb5 credentials cache.

The advantage of such a scheme is that it makes minimal changes to the
calling conventions of gss_init_sec_context, and places the
"credentials" information in the place which harmonizes with the
original GSSAPI design as much as possible.

... and as I complete this reply, I see that John Linn has already
anticipated me.  :-)

						- Ted