Subject: Comments on the GGF GSS-API extensions proposal

From: Nicolas Williams <[email-masked]>
Date: Wed, 7 Apr 2004 12:28:17 -0500

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

---

From: Sam Hartman <[email-masked]>
Date: Thu, 08 Apr 2004 13:48:40 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> 3.  Can you explain again why the
    Nicolas> GSS_PROTECTION_FAIL_ON_CONTEXT_EXPIRATION option is
    Nicolas> needed, why the per-msg token functions shouldn't always
    Nicolas> fail when the context is expired, period?

I think this basically boils down to making application protocols
simpler.  It's particularly true for SASL that having contexts expire
is mostly unacceptable in practice.

AN argument could be made that the SASL GSSAPI mechanism (or all SASL
applications) should support rekeying.  Honestly, for most
applications I just don't think it is worth the complexity.  ANd the
designers of these protocols tend to agree with me.  Things like FTP,
many proprietary GSSAPI applications, etc do not support rekeying.
There is of course the notable exception of SAP.

Especially as we start talking about AES and 128-bit blocks, the
lifetime of many keys may be significantly longer than the lifetime of
the credentials.  And even for moderate traffic contexts, a DES key
may usefully be used longer than the context credentials last.

--Sam

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 8 Apr 2004 12:59:16 -0500

> There is of course the notable exception of SAP.

Additional exceptions: SSHv2, ONC RPC w/ RPCSEC_GSS.

So what's exceptional here?  SASL and FTP?  Or SAP, SSHv2 and RPCSEC_GSS?

Nico

---

From: Sam Hartman <[email-masked]>
Date: Thu, 08 Apr 2004 14:14:20 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Thu, Apr 08, 2004 at 01:48:40PM -0400, Sam Hartman
    >> 
    >> 
    >> I think this basically boils down to making application
    >> protocols simpler.  It's particularly true for SASL that having
    >> contexts expire is mostly unacceptable in practice.
    >> 
    >> 
    >> AN argument could be made that the SASL GSSAPI mechanism (or
    >> all SASL applications) should support rekeying.  Honestly, for
    >> most applications I just don't think it is worth the
    >> complexity.  ANd the designers of these protocols tend to agree
    >> with me.  Things like FTP, many proprietary GSSAPI
    >> applications, etc do not support rekeying.  There is of course
    >> the notable exception of SAP.

    Nicolas> Additional exceptions: SSHv2, ONC RPC w/ RPCSEC_GSS.

    Nicolas> So what's exceptional here?  SASL and FTP?  Or SAP, SSHv2
    Nicolas> and RPCSEC_GSS?

I don't think sshv2 counts really but don't want to go into why.

The answer to your question is that the protocols that support
rekeying are exceptional both by number and by usage.

But that's not the interesting question.  The interesting question is
whether GSSAPI can justify the complexity of requiring rekeying from a
security standpoint.  I say that this complexity is not justified.

--Sam

---

From: Martin Rex <[email-masked]>
Date: Thu, 8 Apr 2004 21:17:09 +0200 (MET DST)

> There is of course the notable exception of SAP.

Thanks. :)

Reality shows that hardly anyone has implemented security context
expiration.  The larger fraction of Kerberos 5 gssapi mechanisms only
has it because rfc-1964 requires it.  Curiously Microsoft disabled
it in the Microsoft Kerberos SSP after devastating tests with
having it active in W2K3 beta -- little if any of their RPC and application
code was able to cope with it either.

I agree that dealing with gssapi security context expiration requires
an enormous  protocol complexity.  However the worst thing about it
(and about how Kerberos implements it) is would be extremely complex
("expensive) to implement it reliably:

  - the application needs to address the issue that a security context
    may expire at a time when there are still unprocessed protected
    messsages in transit or waiting in network buffers or message queues
    to be processed.  Possible approaches:
     - app-level unprotected retransmission queues
       (=most reliable, most expensive)
     - security context renegotiation with a safety margin prior to
       context expiration so that the likelyhood of protected messages
       expiring "in transit" is very low
       (=reasonable compromise, remaining risk of connection abort)
    I implemented the latter

  - In Kerberos, the security context lifetime is derived from the
    credentials, although independent security contexts have independent
    session keys, and the reasoning for security context expiration was
    that no keys should be valid forever.
    The problem with rfc-1964 is that if you don't think about the
    effect, you might write code that goes into a tight loop trying
    to establish a new security context (expecting longer lifetime
    that for the context one has been using).  If the TGT hasn't been
    refreshed, then the lifetime of the new security context will be
    exactly the same as the lifetime of the old one (if GSS_C_INDEFINITE
    is requested), namely the lifetime of the service ticket in the AP_REQ
    which was copied from the TGTs lifetime.

    Therefore my code currently uses a plausibility check whether the
    credentials lifetime is longer than the security context lifetime
    before it tries to renegotiate a successor security context,
    and there are delays imposed on how often a security context "refresh"
    will be attempted, and when security context refresh fails, the
    message protection will continue on the original security context.

  - it requires a bidirectional message exchange for the security
    context establishment at a time determined by the gssapi mechanism,
    which might be quite unusual for the (legacy) application (protocols),
    e.g. the FTP data channel.

  - it requires a synchronized handshake and switch-over to messages
    protected under the new security context between both peers,
    flushing of message queues on the communication channel

  - only the initiator can initiate a replacement security context,
    so if the acceptor thinks a renegotiation should be performed,
    it needs to request the initiator to actually try it.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 9 Apr 2004 16:23:24 -0500

On Fri, Apr 09, 2004 at 04:14:59PM -0500, Matt Crawford wrote:
> On Apr 7, 2004, at 12:28 PM, Nicolas Williams wrote:
> I know that what the globus people have in mind is the possibility of 
> delegating some credential other than the one that was used to 
> authenticate the sesssion.  For example, to delegate lesser, or 
> different rights to a remote process.

Nothing, I suppose, that couldn't be addressed by the GGF proposal for
credential options, without adding delegation-at-any-time.  But, see
below.

But at least my objections to this are not as strongly held as my
objections to the export-cred-to-env-var thing...

Also, given export-cred-to-token feature and credential options
technically that ought to be enough to implement delegation at any time.
I don't object to the export-cred-to-token feature.  I do object to
addressing authorization data through credentials/context options, but
don't object to other credentials options.

So perhaps I ought not oppose credential-delegation-at-any-time.

Nico

---

From: Matt Crawford <[email-masked]>
Date: Fri, 09 Apr 2004 16:14:59 -0500

---

From: Sam Hartman <[email-masked]>
Date: Fri, 09 Apr 2004 18:10:58 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> But at least my objections to this are not as strongly
    Nicolas> held as my objections to the export-cred-to-env-var
    Nicolas> thing...

My objections to delegate cred at any time are somewhat stronger than
my objections to the export to env var thing.  Both are fairly strong
though.

    Nicolas> Also, given export-cred-to-token feature and credential
    Nicolas> options technically that ought to be enough to implement
    Nicolas> delegation at any time.  I don't object to the
    Nicolas> export-cred-to-token feature.  I do object to addressing
    Nicolas> authorization data through credentials/context options,
    Nicolas> but don't object to other credentials options.

EXport to token is useful only on a single system/implementation as
export context.

I actually think credentials options are the right place for things
actually having to do with negative authorization.  For example, a
time range restriction belongs on a credential.  But really we're getting more into this discussion than I want to have now.

---

From: Von Welch <[email-masked]>
Date: Sat, 10 Apr 2004 15:07:19 -0500

Comments inline.

Nicolas Williams writes (12:28 April 7, 2004):
...
 > 1.  I do support the notion of exporting credentials to tokens.
...

I have to admit I don't have any strong incliation to defend this at
the moment. As I recall this seemed like a possibily useful thing and
got tacked on as it was easy given gss_export_cred().

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

There are several motivations for this function:

 1) It allows a client to delegate after authentication when it has
established if the service can actually perform some task on its
behalf. E.g. Client server authenticate, Client presents description
of job, server says ok, client then delegates credential.

 2) It allows a client to delegate a credential to express desires
about the type of credential it does delegate. For example, whether or
not to delegate a forwardable or unforwardable Kerberos
credential. (Obviously it has hooks for more complex policies.)

3) It allows for entirely separate credential to be delegated. The use
case for this is a job broker that is trusted by resources and the
user is not. A user authenticates to the job broker and delegates, the
job broker then authorizes the user and decides which resource should
run the user's job and then authenticates to the resource and
delegates the user's credentials. In many cases the resources are
happy to off-load authorization to the job broker so they don't have
to maintain a list of authorized users.

 >     fail when the context is expired, period?

If an application is partially through a long-running data transfer
(think 20+ hour ftp) when the context expires, I'd argue it is
reasonable that the application may want to go ahead and finish the
transfer (especially if it doesn't have the capability to reestablish
and complete).

I agree that in the case of an interactive session like SSH, you
probably want to fail. Hence this behavior should be application
driven.

 >     the lack of generic token framing for non-initial context and

The thought here is that currently applications have to know from the
state way kind of GSS token to expect and what function to feed it
to - is it a contact establishment token, a delegation token, a
wrapped token, or something unrelated to gss. Basically some way to
demux incoming packets and determine how to handle them.

 > 5.  I do like the idea of extending GSS_Display_status().
...
 >     though, so we'll need an extended replacement for it.

Agreed.

...

 >     be useful and workable in the face of authorization data.

Interesting. So the name element basically encapsulates all the
information about the entity. I see the wisdom in this.

Von

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 12 Apr 2004 10:58:21 -0500

> got tacked on as it was easy given gss_export_cred().

I have a use for this, and I think so does Sam.

> of job, server says ok, client then delegates credential.

I've explained my objection to this.

> credential. (Obviously it has hooks for more complex policies.)

I think this might best be done as extensions to either
GSS_Init_sec_context() or to GSS_Add()/Acquire_cred() similar to the
ones in the GGF proposal.

> to maintain a list of authorized users.

I object to this but don't have time to commit my objection to bits atm.

> probably want to fail. Hence this behavior should be application

Ok, Sam's convinced me that there's a class of apps for this this is a
problem.  I'd agree to a GSS_Set_context_lifetime() function that
initiators and acceptors both must use to set a context's lifetime to
infinity.

> demux incoming packets and determine how to handle them.

I can't think of a single application that needs this, and for good
reason too: all GSS applications have had to deal with this by adding
their own framing to GSS tokens.  "What a lot of repetition!" you might
say, but if you look at these apps many (e.g., RPCSEC_GSS, SSHv2) would
have had no use for generic token framing.

That said, if you can show us some examples of protocols that could
be changed to support the GSS-API with much less effort by using such
generic token framing, then I'd support that, though as a separate
document altogether, and with functions that the application is
responsible for calling in order to make/parse the generic frames.

>  >     though, so we'll need an extended replacement for it.

Good.

> information about the entity. I see the wisdom in this.

Good.  I preferred your approach of associating authorization data with
initiator creds and with contexts, but when Sam proposed associating it
with names instead I saw the light -- 'tis definitely the way to go.

Some issues have to be ironed out.  For example, do two otherwise equal
names, but associated with different authorization data, compare equal?
I'd say yes (if the authz-data is accessible the app can compare that on
its own, where comparisons of authz-data make sense.).

Nico