Comments on the GGF GSS-API extensions proposal

0.  I think that my objections to the GSS_Export_cred() export-to-
    environment-variable proposal are sufficiently documented elsewhere
    that I don't need to repeat them.  Please see recent discussions on
    these same lists if you are new to this discussion.


1.  I do support the notion of exporting credentials to tokens.

    For the Kerberos V mechanism the mechanism-specific part of the
    exported credential token could just be a KRB-CRED with the
    encrypted part "encrypted" using the NULL enctype.

    Also, note that the format of exported credentials tokens needs to
    be specified!  There should be a generic token wrapper/header and a
    mechanism-specific part; for the Kerberos V mechanism a KRB-CRED
    could be used as described above.


2.  I oppose the credential delegation at any time concept.

    Basically, I see no reason not to re-authenticate in order to
    delegate fresh credentials.

    SSHv2 w/ GSS-protected key exchange gets this right since re-keying
    allows for delegation of fresh credentials.

    Presumably delegated credentials generally do not expire prior to
    the expiration of the contexts they are delegated with.  And it
    would not be a good idea, from a security point of view, to delegate
    fresh credentials without re-authenticating the acceptor if the
    context one would do it with is expired.

    Even if/where delegated creds tend to expire earlier than the
    security context with which they are delegated, credential-
    delegation-at-any-time is really just an optimization that I don't
    think we need to make.


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?


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.


5.  I do like the idea of extending GSS_Display_status().

    I think a context input parameter to GSS_Display_status() would help
    produce more context-specific information.

    Changing the prototype of GSS_Display_status() is not possible
    though, so we'll need an extended replacement for it.

    Also, I think we need a dummy mechanism to use with
    GSS_Display_status() when attempting to display _minor_ status codes
    from GSS-API functions that have no mechanism input/output parameter
    that could be used instead but which still output a minor status
    code.  E.g., GSS_Indicate_mechs() can output a minor status code,
    but it cannot be associated with any one mechanism!

    GSS_C_NULL_OID cannot be used for this purpose because of default
    mechanism semantics.

    Also, some functions should be allowed to return GSS_S_COMPLETE but
    non-zero minor status codes.  E.g., GSS_Indicate_mechs() should be
    able to return GSS_S_COMPLETE and a non-zero minor status code that
    could be used to indicate that some mechanism could not be loaded.


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.

    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]