Subject: 
            Re: SecDir Review: draft-engert-ggf-gss-extensions-00
       Date: 
            Fri, 09 Apr 2004 17:25:17 -0400
      From: 
            Sam Hartman <hartmans@mit.edu>
        To: 
            Russ Housley <housley@vigilsec.com>
        CC: 
            smb@research.att.com, brc@zurich.ibm.com, hartmans@mit.edu
 References: 
            1




I have reviewed draft-engert-ggf-gssapi-extensions-00, a now expired
internet draft from the GGF describing extensions to RFC 2743 and RFC
2744.


                          Executive Summary

This draft correctly identifies several areas in which extensions to
the GSSAPI would be useful.  However there is a reasonable probability
that this extension will conflict with future work within the IETF.
Extensions to credential export rely on specific features of the
platforms used by the authors and are not generally applicable even
though they are presented as general extensions to the GSSAPI.    The
credential delegation extension provides a general API in a space
where no general solution is possible.  Even for the subsets of the
problem  where a solution is possible, the extension is not well
specified enough to construct interoperable implementations.  No
thought has been given to interoperability concerns between this
extended GSSAPI and the IETF's standards-track GSSAPI either at the
API or protocol level.  For these reasons, the document is not
suitable for publication as a standard.

                           General Overview

GSSAPI is an API for requesting security services at a very abstract
level.    This document provides the following extensions to GSSAPI:

1) Credential export so that credentials can be moved from one process
   to another on the same machine  (Section 1.2)

2) Credential delegation at any time, allowing credentials to be
   transported over an existing security context to a remote peer
   (Section 1.3)

3) Options to add extra data to credentials (Sections 1.3, 1.4)

4) Options to relax context expiration (Section 1.5,1.8-10)


                          Credentials Export

The document introduces two new functions: gss_export_cred and
gss_import_cred.  They can operate in two modes depending on the value
of the option_req parameter.  

With option_req set to 0, the credential is exported to an opaque
token.  This works similar to gss_export_sec_context.  In principle,
this mode is sound.  I'm concerned that the current text does not
adequately consider challenges for multi-mechanism implementations.
For example if I export a SPNEGO credential, what happens?  Any such
deficiencies could be corrected reasonably quickly.

The other mode, with option_req set to 1 is intended to allow
exporting credentials to non-GSSAPI applications.  For example when
you ssh into a machine you would like your GSSAPI-delegated
credentials to be available to your session.  Without some extension
in this space, ssh and other similar applications would need to call a
mechanism-specific function depending on the particular mechanism used
to authenticate your ssh session.  It's not clear that when properly
used this extension is any better.  The application gets a string back
whose format and usage is mechanism specific.  In practice, what
happens is that the application passes the string to putenv.  This
works for non-native Kerberos and GSI on Windows and Unix.  It's not
very general and for example would not work for the Kerberos
implementation shipped with Apple's operating system.  The string ends
up not being mechanism-specific, but actually mechanism implementation
specific.  The choice of exposing an environment variable for GSI and
Kerberos is particularly problematic; not all GSSAPI platforms that
support these mechanisms even have an environment.

A better approach to the option_req 1 mode is provided by
draft-williams-gssapi-store-deleg-creds-01.txt.  This draft defines a
function  that stores the credential for the current session.

Both...