Subject: RE: IAKERB draft

From: David Margrave <[email-masked]>
Date: Wed, 19 Nov 1997 19:43:38 -0800

>> 
>> - 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. 

I was thinking it would keep things simpler to have a single Kerberos 5
mechanism while taking care to extend it in such a way that it is
completely backward compatible with older implementations, since there have
been some remarks about putting these features into an RFC-1964 revision
anyhow.  

The only time these extensions would really be used, it's an all-or-nothing
prospect anyhow (just like without negotiation).  If the context initiator
can't reach the KDC, and the context acceptor doesnt support IAKERB, then
negotiating normal kerb 5 is not an option.

So it depends on how a context acceptor indicates it can't take an IAKERB
context establishment token.  If we implement it as a separate mechanism,
it would return GSS_S_BAD_MECH.  If we extend the existing mechanism, then
the context acceptor returns GSS_S_DEFECTIVE_TOKEN.  Then the problem is,
does the GSS_S_DEFECTIVE_TOKEN unambiguously indicate that the acceptor
doesn't support IAKERB extensions?  Not necessarily.  Do any other problem
scenarios come to mind?

>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. 

Okay, that's a bad idea.  How about this, gss_init_sec_context can make the
token itself, and we can suggest that implementors get what they need to
generate it (client principal, server principal, password or key) into
gss_init_sec_context using the claimant_cred, where they pretty much have
free reign.  So then the initial call to gss_init_sec_context would have
GSS_C_NULL_BUFFER for input_token, and the claimant_cred containing cname,
sname, and password, and would return an encapsulated AS-REQ as
output_token.  Then, as Mike suggests, we figure out some other way of
telling gss_init_sec_context to generate an AS-REQ for the krbtgt service
or an AS-REQ for an end-service.

Dave

---

From: [email-masked]
Date: Mon, 24 Nov 1997 19:16:08 -0500

Date: Wed, 19 Nov 1997 19:43:38 -0800
   From: David Margrave <[email-masked]>

The major problem I see is how does the context acceptor indicate to the
*initiator* that it doesn't support the IAKERB extention?  I don't think
letting the initiator time out after 15 minutes is the nicest way to do
this.  :-)

That's why I think we really need to have a separate OID to indicate at
the SPNEGO stage whether or not the other side supports the extention.

That's basically what I suggested.  Note that whatever the gss
credential handle points to is under the control of the mechanism, so
what's stored there is really a mechanism-specific thing.  For the krb5
mechanism, it currently contains the credentials cache handle, etc., but
it's simple enough to extend that to include a username and a password.
The sname wouldn't be stored in the claimant_cred, though --- that
should be passed into gss_init_sec_context as the target name. 

The hint to the mechanism implementation as to whether to get a TGT
first, or simply get the client credential directly, would probably go
into the same API call where you stash the username and password in the
claimant_cred.  You'll probably also need to stash a hint as to where
the TGT should be stored if you get one (i.e., the name of the
credentials cache).

						- Ted