Re: Comments on the GGF GSS-API extensions proposal

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

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

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

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.

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

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

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

...

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

Von

 >     I suspect that this will be a significant topic at the KITTEN BoF so
 >     please do attend it!  I don't care to go into the details of what we
 >     might propose in this area yet -- I'd rather spend some time writing
 >     up a proposal instead.
 > 
 > 
 > Comments?
 > 
 > 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]
 > 

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