Subject: RE: GSSAPI Conversation function proposal

From: "Linn, John" <[email-masked]>
Date: Wed, 13 Jan 1999 09:08:58 -0500

Thanks, Ted, for opening discussion in this area, which is particularly
relevant to the low-infrastructure discussion.  I believe that this topic
should be considered, but suggest that it should be treated as a separate
item from the "core" GSS-API specifications at this time.  Based on working
group discussion through Orlando, we're currently pending on a one-sentence
edit to the GSS C bindings spec, at which point the pair of GSSV2 documents
are due to be handed off to the IESG.  Rather than delaying their
advancement further, I propose that approaches within this additional scope
be considered as candidates for a separate document, rather than being
targeted into the existing documents at this point.    

--jl

> ----------
> From: 	[email-masked][SMTP:[email-masked]]
> Sent: 	Wednesday, January 13, 1999 2:44 AM
> To: 	[email-masked]
> Subject: 	GSSAPI Conversation function proposal
> 
> 
> At the Orlando IETF, in some private discussions with a number of CAT
> working group members, I volunteer to write up a straw-man proposal for
> a new interface to the GSSAPI library to allow mechanisms to perform I/O
> with the user.  This would allow certain low-infrastructre-requiring
> mechanisms to prompt the user for a username, password, SecureID
> response, etc.  It might also be used by mechanisms such as kerberos
> when the GSSAPI library wishs to obtain initial credentials itself,
> instead of assuming that they are already present in the process.
> 
> Traditionally, this was ruled out of scope for the GSSAPI, but I think
> we can make a strong case for this functionality, especially as we start
> considering mechanisms that can't assume pre-existing cryptographic
> credentials which were establishd at login time.
> 
> I'm told that Cybersafe has developd its own API for doing precisely
> this.  If Cybersafe is willing to post its proposal, it should
> definitely be considered, since my understanding is that they have
> implemented it and are trying to use it.
> 
> Comments?
> 
> 						- Ted
> 
> 
> 
> GSSAPI Conversation Function API
> 
> (Many ideas liberally stolen from the PAM specification, although things
> have been changd to use the GSS "API style".)
> 
> OM_uint32
> gss_register_conv_function(OM_uint32 *minor_status, struct gss_conv
> *conv);
> 
> This function registers a conversation function with the GSSAPI
> library.  Once a conversation function has been registered, the GSSAPI
> function calls gss_init_sec_context(), gss_acquire_cred(), and
> gss_add_cred() may initiate a callback to the application-supplied
> conversation function.
> 
> XXX This is does mean that we are tieing state to the GSSAPI library,
> which isn't wonderful.  However, in practice, most GSSAPI
> implementation have to have static state anyway.  An alternative is to
> tie the converstaion function to the GSSAPI credentials --- but this
> would require a new version of gss_acquire_cred (say,
> gss_acquire_cred2) which included a new parameter for the gss_conv
> structure, or other solutions which are even more awkward.
> 
> 
> The gss_conv function shall have the following definition:
> 
> struct gss_conv {
> 	int (*conv)(OM_uint32 gss_num_msg,
> 		    const struct gss_conv_message *gss_msg,
> 		    struct gss_conv_message *gss_resp,
> 		    void *gss_appdata_ptr);
> 	void *gss_appdata_ptr;
> };
> 
> The conversation function shall be passed two arrays of struct
> gss_conv_message, which shall have the following type definition:
> 
> struct gss_conv_message {
> 	OMuint32     gss_msg_code;
> 	gss_buffer_t *gss_msg;
> };
> 
> The first parameter, gss_num_msg specifies the number of messages to
> be processed by the conversation function.  The GSSAPI library will
> pass in two arrays of size gss_num_msg.  The first array, gss_msg,
> contains a list of text messages which can be prompts or informational
> text to be displayed to the user.  The second array, gss_resp, is
> filled in by the conversation function.  For each entry in the gss_msg
> which requires user input (i.e., GSS_CONV_ECHO_OFF or GSS_CONV_ECHO_ON
> --- see below), the conversation function should fill in the user's
> response in the corresponding gss_resp entry.
> 
> The first array, gss_msg, shall consist of the prompts and informational
> text which should be displayed to the user.  The gss_msg_code field
> shall have the following definitions in the gss_msg array:
> 
> #define GSS_CONV_ECHO_OFF	1
> 	/* Obtain a string without echoing any text */
> 
> #define GSS_CONV_ECHO_ON	2
> 	/* Obtain a string whilst echoing text */
> 
> #define GSS_CONV_ERROR_MSG	3
> 	/* Display an error */
> 
> #define GSS_CONV_TEXT_INFO	4
> 	/* Display some informational text. */
> 
> In the gss_resp array, the gss_msg_code field is reserved, and should
> be set to zero by the conversation function.  
> 
> The conversation function returns the following integer codes to its
> caller (the GSSAPI library):
> 
> #define GSS_CONV_SUCCESS	0	/* The user filled in the reqested
> 					   fields and all is well */
> #define GSS_CONV_ABORT		1	/* The user requested an
> abort */
> 
> 
> ==========================================================================
> 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]
> 
==========================================================================
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: "Theodore Y. Ts'o" <[email-masked]>
Date: Wed, 13 Jan 1999 14:56:02 -0500

From: "Linn, John" <[email-masked]>
   Date: Wed, 13 Jan 1999 09:08:58 -0500

Yes, absolutely.  My intention was that this interface would be an
addendum to GSSAPI V2, and not as something to be added to the existing
specifications, which I'm sure most of us are very eager to see
advanced.

						- Ted