Subject: Re: What do we want from sshv2?

From: Martin Rex <[email-masked]>
Date: Thu, 02 Nov 2000 19:35:01 +0100

Nico,

I have only very limited time for participating these
IETF mailing lists these days.  I'm willing to offer
hints and advice based on my GSS-API experience from the
ietf-cat working group, but I'm not into evangelism.

Your proposal:

> The question I was raising was wether it was worthwhile to have SPNEGO
> itself perform a DH exchange and also support different mechanisms for
> key exchange, authentication and session encryption.
>
> So, use GSS-API->SPNEGO->DH for key exchange,
> GSS-API->SPNEGO->auth_mech, where "auth_mech" is any authentication
> mechanism you choose and GSS-API->SPNEGO->sess_mech where "sess_mech"
> is whatever session integrity/privacy mechanism of your choice.

is not compatible with the GSS-API / SPNEGO architecture.

You can define your own new gssapi mechanism with PFS and negotiate
with your communication peers a list of mechanisms that includes
your new gssapi mechanism, but you cannot split and recombine
the services "authentication", "message integrity" and "message
privacy" of individual existing gssapi mechanisms at the SPNEGO level.

The GSS-API spec (rfc-2743 and rfc-2744) does *NOT* specify anything
like key exchange and encryption.  This is what the individual
mechanism specifications are for (rfc1507, rfc1964, rfc2025, rfc2847).

The GSS-API spec specifies the three services "authentication",
"message integrity" and "message confidentiality", and they are
made available in exactly one of the following three sets:

 EITHER 1.  authentication ONLY
 OR     2.  authentication AND msg integrity
 OR     3.  authentication AND msg integrity AND msg confidentiality

from _exactly_one_gssapi_mechanism_ that is determined during
context establishment.  The selected gssapi mechanism is
indicated at the end of the security context establishment
by the output parameter "mech_type" from both calls
gss_init_sec_context() and gss_accept_sec_context().
The notion of a multi-mechanism existed in the GSS-API spec
before S(P)NEGO was proposed.  However, there are no provisions
to perform a negotiation of a common mechanism during context
establishment in the base GSS-API spec.

SPNEGO is not a gssapi mechanism, it is a negotiation mechanism.
It is made to look like a gssapi mechanism (and therefore the
spec calls it "pseudo-mechanism") so that the operational
paradigm of GSS-API remains unchanged.

Simple applications designs use defaults for most gssapi parameters,
so this allows the developer (or even the user/administrator) to run
the application on top of SPNEGO instead of a particular gssapi
mechanism and have SPNEGO negotiate which gssapi mechanism
gets actually used.

More complex application design (e.g. distributed applications)
are more often guiding the credential acquisition and mechanism
selection, so the SPNEGO spec defined new calls for such
applications so that they can configure their own particular
mechanism selection policies (preferences and feature availability).

Microsoft uses SPNEGO in Windows2000; at least on the wire
-- they have their own proprietary variant of GSS-API
called SSPI "Security Service Provider Interface" at
the API level.  They use it to negotiate whether W2K Kerberos
or the NT4/9x NTLM gets used, because a fall-back is much
cleaner than a fail-back behaviour.  When used as connection
initiators, (unpatched) NT4/9x will use the plain NTLM
mechanism and not understand SNEGO or Kerberos5.
The compatibility/interoperability/migration issue is
more interesting when using an W2K initiator and
NT4/9x acceptor.  As long as NT4/9x is not upgraded
with SPNEGO, dirty fail-backs or hard-coded NTLM are
the only options.

Bull (France), where the proposal for S(P)NEGO originated
may be using it as well.  (I think they even offered
an example implementation of SNEGO for download.)

Now on the issue of "key exchange":

There are not only (perfectly valid) authentication-only GSS-API
mechanisms based on challenge-response schemes which do not
necessarily establish/exchange a key.  Imagine
a RSA-based gssapi mechanism that uses unique but public signed values
(e.g. timestamps) for authentication and each peer's public key for
message confidentiality and each peer's private key for message
integrity.  This would be a completely valid gssapi mechanism
with message protection services that does not establish a shared
"session" key.

Nicolas Williams wrote:
>
> Now, add a flag to GSS-API and SPNEGO for requesting Perfect Forward
> Security (PFS), add one mechanism that supports PFS (Diffie-Hellmann)
> and suddenly GSS-API, by itself, can support all or most of what has
> been discussed on this list that SSHv2 should support.
>
> The distinction between key exchange, authentication and integrity/
> confidentiality mechanisms can only be done within SPNEGO since GSS-API
> without SPNEGO only supports the use of one mechanism.

The use of SPNEGO still only supports the use of ONE SINGLE mechanism.
SPNEGO only allows to select *WHICH* one from a list gets used.
The additional calls and flags in SPNEGO only set preferences for
the negotiation, they don't change any characteristics.
SPNEGO only encapsulates context establishment, it is *NOT* allowed
to change the message protection tokens, because these must comply
with the mechanism spec of the underlying real gssapi mechanism.

>
> As I just stated in another reply, a GSS-SPI C Bindings RFC would be
> very useful in promoting the development of GSS mechanism providers that
> work with multiple GSS-API implementations... This would be the place to
> make the mechanism type distinction I suggest above.

*DANGER* ahead.  Designing secure protocols is not for the
average programmer.  A gssapi mechanism should be designed as
one piece with all of its three services "authentication",
"message integrity" and "message privacy".  And it should
then be carefully reviewed and scrutinized in one piece by
*real* cryptographers.  

Building each service seperately and letting mere mortals
mix and match them together will open security holes.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 6 Nov 2000 10:45:40 -0500

I was away last week, so I was unable to answer this until today.

> ietf-cat working group, but I'm not into evangelism.

Same here.

> is not compatible with the GSS-API / SPNEGO architecture.

Arguably SPNEGO is not compatible with GSS-API.

We're talking about the future, not the present.

> privacy" of individual existing gssapi mechanisms at the SPNEGO level.

Sure you can. See below.

> paradigm of GSS-API remains unchanged.

SPNEGO is a pseudo-mechanism with a GSS-API mechanism OID. It is useless
by itself but provides something that GSS-API was not designed to do,
namely mechanism negotiation.

Extending the mechanism context so multiple mechanisms can be used to
provide different sets of services to GSS-API applications is not a big
deal, not once the leap of adding SPNEGO is made.

Yes, the GSS-API language bindings will need updating so applications
that wish to enquire as to what went on under the hood can get the data
they need.

> with message protection services that does not establish a shared

I understand this. Your argument does not prove that it is too late to
conceptually split the GSS-API mechanisms into authentication, key
exchange, integrity, confidentiality and credential forwarding
sub-mechanisms.

In fact, because GSS-API hides mechanism details from applications it
should be fairly painless to split the mechanisms into various parts.

> with the mechanism spec of the underlying real gssapi mechanism.

So? Add a new SPNEGO mech OID, and a new SPNEGO spec. It wouldn't be
compatible with existing implementations, but that's ok because you can
always fallback (the new SPNEGO could be negotiated within the framework
of the old SPNEGO if desired).

> then be carefully reviewed and scrutinized in one piece by

Ok, so forget SSHv2.

I mean, SSHv2 does this, or will do this. Would you care to tell the
SSHv2 crowd that they shouldn't mix mechanisms?

> mix and match them together will open security holes.

Modular architectures allow you to shoot yourself in the foot. They also
allow you to fix your foot by replacing shoddy modules or shoddy module
mixtures. A monolythic system would be far worse.

> -Martin

Nico
--