Subject: GSS-APIv2 Extension for Storing Delegated Credentials

From: Nicolas Williams <[email-masked]>
Date: Mon, 8 Sep 2003 08:07:03 -0700

I just posted the following I-D, which I think the KRB WG and
implementors of draft-ietf-secsh-gsskeyex may find interesting:

http://www.ietf.org/internet-drafts/draft-williams-gssapi-store-deleg-creds-00.txt

"
Abstract

   This document defines a new function for the GSS-API which allows
   applications to store delegated (and other) credentials in the
   implicit GSS-API credential store.  This is needed for GSS-API
   applications to use delegated credentials as they would use other
   credentials.
"

Currently, any implementation of SSHv2 w/ gssapi userauth or keyex has
to have some trouble dealing with delegated credentials, or the platform
it runs on must make some annoying assumptions.

For example, Simon Wilkinson's patches to OpenSSH require the use of
interfaces that are internal to Heimdal, MIT krb5 or GSI in order to do
anything useful with delegated credentials.

The only ways, that I can see, to remove this use of internal interfaces
are:

 - don't use delegated creds

 - have the GSS-API make the creds available only for the user account
   that is primariliy associated with the principal name of the
   delegated creds (but this means that the deleg creds won't be
   available when logging in to a different user account)

 - extend the GSS-API to correct the delegated credentials uselessness
   wrinkle

This I-D proposes a simple extension to the GSS-API that allows acceptor
applications to make delegated credentials available for acquisition and
use to other processes sharing a given "credential store."

[Note that the notion of "credential store" is implicit, as described in
 the I-D, in rfcs 2743 and 2744.]

Cheers,

Nico
--

---

From: Daniel Kouril <[email-masked]>
Date: Wed, 10 Sep 2003 17:34:16 +0200

>    applications to use delegated credentials as they would use other

I'm without Internet connectivity just now, so I can't read it, but according
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?

Cheers,

--
Daniel

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 10 Sep 2003 13:40:53 -0700

> I'm without Internet connectivity just now, so I can't read it, but according

I'll e-mail it to you separately.

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

In private exchanges with one of the GGF proposal's co-authors it's also
become clear that the GGF's proposal implicitly deals with creation of
credential stores as well and I think they convinced me that it would be
nice to have a generic interface for acquiring handles to credential
stores and setting the "current" credential store[*] so that
applications can avoid knowledge of mechanism-specific details of how to
create a credential store or set the current credential store.  But I
think such an interface should be described separately from the
GSS_Store_cred() described in my I-D , primarily on account of the
addition of the concept of credential store management to the GSS-API,
which GSS_Store_cred() (and the GSS-APIv2 as it stands) does not
require.

So, as you can see I've had some exchanges with one co-author of the GGF
proposal, some of which was copied to what I think is a GGF mailing
list.

[*]  There's no credential store handle input argument to
     gss_acquire/add_cred() or gss_init/accept_sec_context(), so there
     has to be a current credential store context for their use (it
     could be thread-local, global to a process, global to a login
     session, global to a host - those being platform-specific details).

Cheers,

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Thu, 11 Sep 2003 16:28:02 +0200 (MET DST)

> the method for referencing credentials stores, as well as the "current"

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

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 11 Sep 2003 08:34:44 -0700

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

Thanks, I very much appreciate the fedback.

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

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

>   the longterm credentials, the use of SmartCards in Single Sign-On

Not true for user-2-user situations.

>   legally relevant digital signature operations

See above about proxying crypto operations to smartcards.

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

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

[...]

> a generic concept for GSS-API fitting the level of the abstraction

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