Re: GSS-APIv2 Extension for Storing Delegated Credentials

[Martin Rex <martin.rex%sap.com@localhost>]

Nicolas Williams wrote:
> 
> > to the abstract it seems to address similar area as the "GSS-API Extensions"
> > draft by GGF (available from
> > http://www.ietf.org/internet-drafts/draft-engert-ggf-gss-extensions-00.txt).
> > Perhaps it would make sense to coordinate the effort with GGF?
> 
> Unfortunately, the GGF's export-credential-to-environment-variable
> proposal has a problem: it imposes the use of environment variables as
> the method for referencing credentials stores, as well as the "current"
> credential store.

I would very much like to give some feedback on the proposal,
however I completely underwater these days. :(

Here are a few quick problems that come to my mind:

GSS-API doesn't distinguish different credential stores, although
the new I-D claims that it would.  With GSS-API a mechanism is
free to use an arbitrary number of different credential stores
and employ whatever implementation-specific magic it desires
to decide individually which credential stores to use each time 
an application asks to acquire a credentials handle.

My biggest criticism about the SPKM design was that it uses
the keypair of the longterm credentials to perform each
GSS-API level authentication.  This causes some problems when
an implementation wants to use RSA-SmartCards for credential
storage and crypto-operations:

- "Smart"Cards that deserve their name do not ever reveal the private
  RSA key that they hold.  So it is completely impossible to copy
  credentials that are stored on such smartcards.

- Since every single gssapi-level authentication requires access to
  the longterm credentials, the use of SmartCards in Single Sign-On
  environments that perform a large amount of gssapi-level security
  context establishments require unrestricted access to the cards
  signing/encryption capabilities without additional user intervention,
  rendering the contained keypair utterly useless for any kind of
  legally relevant digital signature operations

- SPKM 1/2 (rfc2025) doesn't support credential delegation, and
  when smartcards are used it is physically impossible

- Common PC SmartCard (TCos 1.2 and 2.0) readers and SmartCard interfaces
  use a serial communication interface with 9600 or 19200 baud, which
  makes all operations involving the SmartCard *EXTREMELY* slow,
  and the software has to solve the issue of multiple concurrent
  access from different processes in a Single Sign-On environment
  (a mutual authentication involving two smartcards with 1024-bit
   RSA keys take about 20 Seconds...)

- when an SPKM-implementation is stupid enough to use RSA digital
  signatures for Message Integrity Protection of each individual
  message of application data, then the problem gets exponentially worse.
  - message protection operations become extremely slow due to PK-operations
  - it's a real PITA when a SmartCard is involved, in particular the
    contention with parallel access becomes a nightmare in busy
    Single Sign-On environments
  - security context transfer at the GSS-API level must somehow pass
    along credentials access with the exported context token,
    the session key(s) alone as in all reasonable GSS-API mechanisms
    is not sufficient -- again this is particularly "entertaining"
    problem to solve if credentials are on a SmartCard.


Also keep in mind that GSS-API was designed to cover GSS-API mechanisms
that live entirely in a TCB and do not reveal krypto keys or credentials
(in whatever shape or form and for whatever (political) reason),
so both, credential delegation and copying credentials can never be
a generic concept for GSS-API fitting the level of the abstraction
of the current spec.

-Martin