Re: Comments on the GGF GSS-API extensions proposal

On Sat, Apr 10, 2004 at 02:50:55PM -0500, Von Welch wrote:
> 
> Comments inline.
> 
> Nicolas Williams writes (12:28 April 7, 2004):
> ...
>  > 1.  I do support the notion of exporting credentials to tokens.
> ...
> 
> I have to admit I don't have any strong incliation to defend this at
> the moment. As I recall this seemed like a possibily useful thing and
> got tacked on as it was easy given gss_export_cred().

I have a use for this, and I think so does Sam.


>  > 2.  I oppose the credential delegation at any time concept.
> ...
> 
> There are several motivations for this function:
> 
>  1) It allows a client to delegate after authentication when it has
> established if the service can actually perform some task on its
> behalf. E.g. Client server authenticate, Client presents description
> of job, server says ok, client then delegates credential.

I've explained my objection to this.

>  2) It allows a client to delegate a credential to express desires
> about the type of credential it does delegate. For example, whether or
> not to delegate a forwardable or unforwardable Kerberos
> credential. (Obviously it has hooks for more complex policies.)

I think this might best be done as extensions to either
GSS_Init_sec_context() or to GSS_Add()/Acquire_cred() similar to the
ones in the GGF proposal.

> 3) It allows for entirely separate credential to be delegated. The use
> case for this is a job broker that is trusted by resources and the
> user is not. A user authenticates to the job broker and delegates, the
> job broker then authorizes the user and decides which resource should
> run the user's job and then authenticates to the resource and
> delegates the user's credentials. In many cases the resources are
> happy to off-load authorization to the job broker so they don't have
> to maintain a list of authorized users.

I object to this but don't have time to commit my objection to bits atm.

>  > 3.  Can you explain again why the GSS_PROTECTION_FAIL_ON_CONTEXT_EXPIRATION
>  >     option is needed, why the per-msg token functions shouldn't always
>  >     fail when the context is expired, period?
> 
> 
> If an application is partially through a long-running data transfer
> (think 20+ hour ftp) when the context expires, I'd argue it is
> reasonable that the application may want to go ahead and finish the
> transfer (especially if it doesn't have the capability to reestablish
> and complete).
> 
> I agree that in the case of an interactive session like SSH, you
> probably want to fail. Hence this behavior should be application
> driven.

Ok, Sam's convinced me that there's a class of apps for this this is a
problem.  I'd agree to a GSS_Set_context_lifetime() function that
initiators and acceptors both must use to set a context's lifetime to
infinity.

>  > 4.  Can you explain again why we need generic token framing for all GSS
>  >     tokens?  In all IETF protocols that use the GSS-API that I can think
>  >     of the lack of generic token framing has never been a problem.
>  > 
>  >     I.e., SASL, RPCSEC_GSS, FTP, SSHv2, none have had any problems with
>  >     the lack of generic token framing for non-initial context and
>  >     per-msg GSS tokens.
> 
> The thought here is that currently applications have to know from the
> state way kind of GSS token to expect and what function to feed it
> to - is it a contact establishment token, a delegation token, a
> wrapped token, or something unrelated to gss. Basically some way to
> demux incoming packets and determine how to handle them.

I can't think of a single application that needs this, and for good
reason too: all GSS applications have had to deal with this by adding
their own framing to GSS tokens.  "What a lot of repetition!" you might
say, but if you look at these apps many (e.g., RPCSEC_GSS, SSHv2) would
have had no use for generic token framing.

That said, if you can show us some examples of protocols that could
be changed to support the GSS-API with much less effort by using such
generic token framing, then I'd support that, though as a separate
document altogether, and with functions that the application is
responsible for calling in order to make/parse the generic frames.

>  > 5.  I do like the idea of extending GSS_Display_status().
> ...
>  >     Changing the prototype of GSS_Display_status() is not possible
>  >     though, so we'll need an extended replacement for it.
> 
> Agreed.

Good.

> ...
> 
>  > 6.  Extensions relating to authorization data are better associated with
>  >     GSS-API names than with GSS-API credentials and contexts.
>  > 
>  >     [Thanks to Sam for this insight.]
>  > 
>  >     This approach will lead to a more consistent interface.  Plus, for
>  >     those who have GSS userok()/name_to_localname() type interfaces
>  >     there is an obvious benefit, namely that said interfaces continue to
>  >     be useful and workable in the face of authorization data.
> 
> Interesting. So the name element basically encapsulates all the
> information about the entity. I see the wisdom in this.

Good.  I preferred your approach of associating authorization data with
initiator creds and with contexts, but when Sam proposed associating it
with names instead I saw the light -- 'tis definitely the way to go.

Some issues have to be ironed out.  For example, do two otherwise equal
names, but associated with different authorization data, compare equal?
I'd say yes (if the authz-data is accessible the app can compare that on
its own, where comparisons of authz-data make sense.).

Nico
-- 
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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 protected]