Subject: Re: GSSAPI Conversation function proposal

From: Martin Rex <[email-masked]>
Date: Wed, 2 Jun 1999 15:51:57 +0200 (METDST)

Hi Ted,

Theodore Y. Ts'o wrote:
> 
> 3.  GSSAPI Conversation API
> 
>  3.1  The gss_acquire_cred_conv function
> 
>           OM_uint32 gss_acquire_cred_conv (
>                   OM_uint32         *minor_status,
>                   const gss_name_t  desired_name,
>                   OM_uint32         time_req,
>                   const gss_OID_set desired_mechs,
>                   gss_cred_usage_t  cred_usage,
>                   gss_cred_conv_t   conversation_info,
>                   gss_cred_id_t     *output_cred_handle,
>                   gss_OID_set       *actual_mechs,
>                   OM_uint32         *time_rec)
> 
> This function is an extended version of the gss_acquire_cred function
> defined in the GSSAPI C-bindings specification, with the addition of a
> new parameter, conversation_info.  If the conversation_info parameter is
> NULL, then the behavior of gss_acquire_cred_conv will be identical to
> gss_acquire_cred.
> 
> If a conversation function is registered via the conversation_info
> parameter, then the GSSAPI mechanism may call the conversation function
> during the execution of the gss_acquire_cred_conv() function, and the
> returned GSSAPI credentials will have a reference to the conversation
> function.  If GSSAPI credential containing a conversation function is
> passed to gss_init_sec_context(), gss_accept_sec_context(), or
> gss_add_cred(), the GSSAPI mechanism may also call the conversation
> function during the course of execution of those GSSAPI functions.

What about the callback during gss_inquire_cred()?

I think the idea of such and extension of GSS-API is really good,
however as an application programmer I want to control when exactly
the user is prompted, so I don't like the idea of the gssapi mechanism
memorizing the callback and being able to use it during
gss_init_sec_context() and gss_accept_sec_context().

What I would like to see is at least an option that forces the
gssapi mechanism to use the callback immediately during the
call to gss_acquire_cred_conv() and never during context establishment.
Without this option, I certainly will not use this extension.

Actually, why do we need to allow the callback outside of
gss_acquire_cred_conv() at all?

(When limiting the callback to the duration of the call, we probably
 should add gss_add_cred_conv().)

-Martin 
==========================================================================
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: [email-masked]
Date: Fri, 4 Jun 1999 11:56:12 -0400

From: Martin Rex <[email-masked]>
   Date: Wed, 2 Jun 1999 15:51:57 +0200 (METDST)

I didn't think it would ever be needed during gss_inquire_cred().  If
someone can come up with a scenario where that would be useful, that
might be something to consider, but if not, I also have your concern
about being able to control when the callback function would be used, so
I wanted to keep the number places where the mechanism could call the
callback function to a minimum.  

My original thought was that allowing the callback during either (a) the
initial credentials establishment, or (b) the initial context
establishment was well enough controlled that application writers would
mind.  And, if they really did mind, the callback function is passed an
application-provided state pointer, and the application could always set
a flag in the state pointer after the initial credentials establishment
that caused the callback function to return an error if it is called at
any other time.  This would make the application useless for a number of
different mechanisms (see below), but that's up to the application
programmer.

The reason why we need to allow the callback during the initial context
establishment is to allow the use of handheld hardware tokens --- for
example, secure ID cards or the "DES calculators".  The latter are
devices you the mechanism would send a challenge to the user at the time
of context establishment, the user would have to type the challenge into
their DES calculator, type the response to the user application, which
would then send the response back to the context acceptor.  

I don't think there is any reason why a credential which has a
user-input callback would need to call the UIO callback function just
because someone was adding another credential to the existing set of
credentials.

The only reason why this might be justified would be if you wanted to
add a new credential for a mechanism that required user IO to an
existing credential, and in that case we should have a new version of
gss_add_cred_conv which takes a callback function for that particular
mechanism.  

One we start wading into the cesspool of issues surrounding
multimechanism operation, we probably want to add other limitations as
well; for example, that a mechanism can only call a callback function if
one was registered during the course of credentials acquisition for that
mechanism.  

							- Ted