Subject: Re: comments on draft-ietf-krb-wg-gssapi-cfx-02.txt

From: Martin Rex <[email-masked]>
Date: Wed, 5 Nov 2003 19:47:14 +0100 (MET)

Nicolas Williams wrote:
> 
> On Fri, Oct 31, 2003 at 10:12:20AM -0800, Nicolas Williams wrote:
> > Agreed.  Just because this can't be enforced [without knowledge of the
> > application protocols] doesn't mean that we can't say "MUST."
> > 
> > "MUST" makes the replay cache optimization possible because initiator
> > implementors will [presumably] follow the spec and implement the "MUST."
> 
> I'd like to clarifiy a bit more.  For RPCSEC_GSS (one of the
> applications I most care about) the acceptor-asserted subkey actually
> doesn't make the replay cache optional - the replay cache is already not
> necessary for RPCSEC_GSS with rfc1964, with certain provisions.

I don't know RPCSEC_GSS (nor RPC for that matter),
I have only a vague idea what it is for.

Whether or not the lack of a replay cache is a *real* security problem
with a specific application may depend on the nature of the application
protocol.  What exactly is the protection that RPCSEC_GSS provides
and where/how are replays detected and ignored/rejected?

I would assume that RPCSEC_GSS provides it's own kind of replay cache
with the help of message identifiers that are protected using the
gssapi message protection functions and that the functionality
is tailored to fit the needs of RPCSEC_GSS with low overhead.

If there really is a performance problem with current implementations
of a replay cache, then maybe there is some potential for optimization.
(Maybe it currently stores the full authenticator and not just a hash
 and a timestamp).

> 
> So, whether the use of acceptor-asserted subkeys [in the mutual auth
> case, of course] is a "MUST" or "SHOULD" is not terribly important to
> me.
> 
> In general I'd much rather prefer to have a 1 1/2 round-trip option for
> the new mechanism.  I'd also like to have a way for the acceptor to
> require the use of that option, but, unfortunately there's no req_flags
> input parameter for GSS_Accept_sec_context(), and, in any case,
> req_flags should be generic, not mechanism-specific.  We still have to
> support a 1-round-trip default for mutual auth and 1/2 round-trip for
> non-mutual auth.
> 
> Perhaps Martin can show us a way to generically negotiate the use of a
> 1 1/2 round-trip option (or, to put it more generally, an option to not
> require replay caches on the acceptor side).  That would be ideal.

Well, in the 1-token security context establishments you're out of luck,
there simply isn't any possibility for negotiation between the two peers.

A security context establishment with at least 2 token exchanges may
perform some negotiation, but one must be careful not to break any
current users and usages of the protocol when it is extended.

Additional token exchanges are backwards incompatible with rfc-1964
as far as the application is concerned.  There are application that
can handle it and there are some that cannot.

Possible approaches:

1 make behaviour selectable at the API.  However GSS-API has only
  the context attributes, and they can only be specified by the
  initiator, so it might be insufficient for some scenarios.
  In any case, the default behaviour must be the original protocol
  spec whenenver it is required for full interoperability with
  an installed base (of both gss-api mechanism and applications).
  This would preclude an automatic upgrade of old applications
  that are dynamically linked (in a plug-n-play fashion) to
  backwards incompatible protocol extensions.
  Making the backward incompatible behaviour the default would be an
  extremely bad idea -- the purpose of a standard is *interoperability*.

2 make the behaviour configurable per identity/principal,
  this way you could still run an installed base of applications
  that requires the old behaviour with specifically configured
  (service) principals.

(2) requires extensions to the initiator<->KDC exchange and
to the principal database and admin tools, and it probably
affects whether and which service principals may be shared
among different services.  If you had shared the host principal
on a machine among applications using different versions or
even different implementations of Kerberos 5 this may be
particularly difficult to sort out.

I think that both (1) and (2) should be done.
(1) for applications that know their requirements so that
they can explicitly request the features they desire so they
don't constantly need additional administrative actions of (2)
to make them work.

Microsoft has been shipping a lot of (2), but they have an
extremely bad track record of providing sufficient (1),
providing sensible defaults for (2) and providing clear
and readily accessible documentation about the ramifications
of (2) and their chosen defaults...

The user2user authentication in Windows 2003 (which ignites
as soon as a Windows 2003 domain is switched from mixed mode
to native mode) is an example of (2), entirely lacks (1),
and besides violating rfc-1964 and the GSS-API/SSPI architecture
(contrary to what Q266080 suggests) the ramifications
and how to administratively configure the behavious is neither
documented nor clear nor obvious...

-Martin