Re: GSS-APIv2 Extension for Storing Delegated Credentials

[Nicolas Williams <Nicolas.Williams%sun.com@localhost>]

On Thu, Sep 11, 2003 at 04:28:02PM +0200, Martin Rex wrote:
> 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:

Thanks, I very much appreciate the fedback.

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

Right, the GSS-API does not distinguish between credential stores - it
merely expects that there is a single credential store available when
GSS_Acquire/Add_cred() are invoked or when GSS_C_NO_CREDENTIAL is
referenced.

But for multi-user platforms there have to be multiple credential
stores, even if only one can be currently available for any given call
to GSS_Acquire/Add_cred() or reference to GSS_C_NO_CREDENTIAL.

The problem is that delegated credentials are not obtained from any
store and so are not available for acquisition by GSS_Acquire/Add_cred()
or use through references to GSS_C_NO_CREDENTIAL.

Making GSS_Accept_sec_context() store delegated credentials in some
store would be inappropriate for multi-user platforms - the credential
store context for storing delegated credentials should be selected by
the application.

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

Using secret keys is not the same as revealing them.

I.e., it is perfectly possible to implement SPKM w/ smartcards by
proxying the relevant encryption/decryption or signature/verification
operations to the smartcard.

> - Since every single gssapi-level authentication requires access to
>   the longterm credentials, the use of SmartCards in Single Sign-On

Not true for user-2-user situations.

>   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

See above about proxying crypto operations to smartcards.

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

PKI credential delegation could be performed by passing a contact
address and secret session key where the receipient of the delegated
credential would have to proxy uses of the credential to a service at
the contact address and use the session key to derive sub-session keys
and to authenticate itself.

I've described a similar system for Kerberos V credential forwarding in
the past either here or at the MIT Kerberos lists (or both - I forget).

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

I can't speak to this.  I really don't see the relevance of the
smartcard issues to my proposal for GSS_Store_cred().

[...]

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

The GSS_Store_cred() interface does not imply that "physical"
credentials (i.e., longterm secrets) are actually stored, nor does it
imply that the store is a file, a smartcard or punched cards - not
anymore than the GSS-API implies the same.

Cheers,

Nico
--