Subject: RE: What do we want from sshv2?

From: Joe Salowey <[email-masked]>
Date: Mon, 30 Oct 2000 10:31:26 -0800

> -----Original Message-----
> From: Jeffrey Hutzelman [mailto:[email-masked]]
> Sent: Monday, October 23, 2000 1:41 PM
> To: Joe Salowey
> Cc: [email-masked]; [email-masked]
> Subject: RE: What do we want from sshv2? 
> 
> Hm.  We seem to have a case of parallel invention.  The key exchange
> method you describe in section 1 
> (kerberos-diffie-hellman-group1-sha1)  is
> pretty much exactly what Sam Hartman and I discussed the week of the
> August IETF meeting.  The only significant problem I see with 
> that section
> is that it does not clearly require the AP_REQ generated in 
> the first step
> to have the mutual-required flag set.  It should be obvious 
> that such a
> requirement is necessary in order to authenticate the host. 
>

True, this is an omission that needs to be corrected.

> 
> The kerberos-sha1 method described in section 2 is workable, 
> but it lacks
> a couple of features that I suspect the ssh community 
> considers to be very
> important.  First, it lacks the property that neither client 
> nor server
> has complete control over the session key.  Second, and perhaps more
> important, it does not provide perfect forward secrecy.  An 
> attacker who
> obtains the service key after the fact can then decrypt the 
> contents of
> a previously-recorded session.  I would suggest dropping this method
> entirely.
> 

The only advantage I can see for this method is a performance gain.  If this
is not a concern then we should probably drop it (unless someone sees
another benefit to it).

> 
> As before, the external-keyx user auth method described in 
> section 4 is
> pretty much exactly the sort of thing we were considering.  I 
> do have a
> couple of comments...
> 
> There appears to be an error in the generic description of the message
> format used when additional credentials are provided.  The 
> format shown
> has a boolean with value FALSE; I think you meant TRUE in 
> this case.  In

I'll take a look at this.

> any case, I'm not sure this feature belongs here.  The way I 
> see it, there
> are three possibile uses for the extra credentials, and none of them
> really belongs here:
> 
> - Extra credentials may be provided for further 
> authentication.  If this
>   is the case, then the client should be using some other appropriate
>   user authentication method instead of external-keyx.
> 
> - Extra credentials may be provided for authorization, 
> without additional
>   authentication information.  Kerberos already provides 
> support for this
>   using proxy tickets, so a Kerberos-specific solution isn't 
> needed here.
>   Generic support for additional authorization data may be 
> interesting to
>   someone, but I don't think it should require the use of 
> external-keyx.
>   Instead, if this is important, there should be some sort of generic
>   support.
> 
> - Finally, extra credentials may be provided for the purpose 
> of credential
>   delegation, such as forwarded TGT's or proxy tickets 
> allowing the server
>   to do things on behalf of the user.  I believe this is 
> important, but
>   again, it shouldn't require the use of external-keyx.  
> Instead, I would
>   suggest either including it in the keyx and user auth methods, or
>   (better) defining some generic credential delegation 
> mechanism that does
>   not depend on which user auth method is being used.
>

My motivation here is to eventually allow service specific credentials to be
passed independant of the keyexchange.  In this case the additional
credentials are associated with the kerberos identity autneticated in the
key exchange.  The additional credentials may not be kerberos tickets, they
may be authorization certificates.  

Perhaps a more generic credential delegation mechanism may eventually be a
better solution.

> 
> Finally, this may seem like a nit, but the title of section 7 uses a
> character not in the 7-bit US-ASCII character set.
> 
> 
> I also have some thoughts on a family of GSSAPI-based key 
> exchange methods
> similar in spirit to the kerberos-diffie-hellman-group1-sha1 method
> described in this draft.  I'll follow up with those in a 
> separate message. 

I look forward to it.

> -- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
>    Sr. Research Systems Programmer
>    School of Computer Science - Research Computing Facility
>    Carnegie Mellon University - Pittsburgh, PA
>

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 30 Oct 2000 15:38:50 -0500

> > described in this draft.  I'll follow up with those in a 

Myself I think it may be a good idea to extend SPNEGO so it supports
separate mechanisms for key exchange, authentication and session
encryption; a new GSS-API flag could be used to request PFS and which
would cause SPNEGO to use, say, a DH mechanism for the key exchange, if
it were available.

Thus GSS-API with SPNEGO + a Diffie-Hellmann mechanism + a Kerberos
mechanism would buy you all that's been asked for in this thread:

Kerberos authentication + perfect forward security.

This would be pretty much equivalent to SSHv2 specifying a DH key
exchange with a pluggable module system for authentication as has been
discussed.

> >    Carnegie Mellon University - Pittsburgh, PA

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Tue, 31 Oct 2000 11:44:31 +0100 (MET)

> exchange with a pluggable module system for authentication as has been

Use the GSS-API token exchange for mutual authentication,
implement a key exchange protocol with the native cryptographic functions 
of SSH, don't dig into Kerberos for keying material.
Using the GSS-API message integrity service to authenticate
the DH key exchange would be a portable integration of a
GSS-API authentication and a SSH-based key exchange.

> mechanism would buy you all that's been asked for in this thread:

*Sigh*.

The only reason why it would be preferable to have GSS-API support
in SSH instead of using the native Kerberos API is that it could
allow to use any GSS-API mechanism, not just the Kerberos GSS-API mech.

GSS-API is a (very good) abstraction of a security service, and it
(purposely) hides the characteristics of the underlying security
mechanism as good as possible.  The reason why applications should
chose GSS-API instead of native APIs is that if a mechanism
proves to have defects or lacks certain features, it can be
replaced.

Now you are looking at particular features of the particular
Kerberos 5 gssapi mechanism, and you're proposing to add features
to this mechanism by adding cryptographic functionality on top
and to the sides of the GSS-API interface.  This is not really
what the GSS-API was designed for, and it very likely not be
"portable" accross different and independent GSS-API mechanisms.

I think you really should not go that way.  If you think that
there is a problem with the GSS-API mechanism, fix the mechanism,
not the API.  GSS-API offers the three services: authentication,
message integrity and message confidentiality.  The abstraction
does not give you access to any cryptographic details of the
underlying mechanism, because that would break the portability
accross mechanisms that makes GSS-API so extremely attractive
and useful for applications.  GSS-API is not a key exchange or
key establishment service.  If you dig alternative ways into
the GSS-API mechanism to get your hands on keying material,
you're breaking the GSS-API abstraction and loosing your
portability.

SPNEGO is a means to help applications negotiate the best common
gssapi mechanism to use.  As it is defined, it is not a gssapi
mechanism by itself and it does not contain any cryptography at all.
It sits on top of regular gssapi mechanism and provides a framing
on the initial protocol exchange.  SPNEGO is used to *select*
the best common mechanism, it is clearly not designed to compose
a new and better mechanism out of serveral gssapi mechanisms below.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 31 Oct 2000 09:33:41 -0500

> GSS-API authentication and a SSH-based key exchange.

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.

I used the Kerberos authentication and session integrity and privacy
mechanism as an example.

> allow to use any GSS-API mechanism, not just the Kerberos GSS-API mech.

So I mentioned the "Kerberos" GSS mechanism. What I suggest does not in
itself require that you use Kerberos. Sue me :)

> "portable" accross different and independent GSS-API mechanisms.

???

GSS-API is a wrapper interface to cryptographic mechanisms.

SPNEGO was thought of, specified and implemented to deal with certain
limitations of GSS-API.

So now I was suggesting extensions to SPNEGO and a new GSS flag to bring
PFS support to GSS-API -- not that an SSH GSS mech couldn't be designed,
just that it seemed an interesting alternative to me. It still does.

> you're breaking the GSS-API abstraction and loosing your

GSS-API *is* "a key exchange or key establishment service."

How could it provide message integrity and message confidentiality
without key establishment?

> a new and better mechanism out of serveral gssapi mechanisms below.

SPNEGO *is* a GSS-API mechanism from everything I can tell. Ok, I'll go
re-read the spec.

SPNEGO provides framing around the individual mechanisms' tokens, but
SPNEGO is *within* GSS-API so as to allow its use with any protocols
that support GSS-API without further modifications to those protocols.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 31 Oct 2000 12:36:00 -0500

> that support GSS-API without further modifications to those protocols.

From the Abstract of RFC 2478, "The Simple and Protected GSS-API
Negotiation Mechanism":

   The Simple and Protected GSS-API Negotiation Mechanism defined here
   is a pseudo-security mechanism, represented by the object identifier
   iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2) which
   enables GSS-API peers to determine in-band whether their credentials
   share common GSS-API security mechanism(s), and if so, to invoke
   normal security context establishment for a selected common security
   mechanism. This is most useful for applications that are based on
   GSS-API implementations which support multiple security mechanisms.

So SPNEGO *is* a GSS-API mechanism, not an abstraction above GSS-API.

   This allows to negotiate different security mechanisms, different
   options within a given security mechanism or different options from
   several security mechanisms.

and

   The Simple and Protected GSS-API Negotiation Mechanism uses the
   concepts developed in the GSS-API specification [1]. The negotiation
   data is encapsulated in context-level tokens. Therefore, callers of
   the GSS-API do not need to be aware of the existence of the
   negotiation tokens but only of the new pseudo-security mechanism. A
   failure in the negotiation phase causes a major status code to be
   returned: GSS_S_BAD_MECH.

I note that the SPNEGO spec already adds two functions to the GSS-API
spec.

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.

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.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 31 Oct 2000 12:32:53 -0500

On Tue, Oct 31, 2000 at 05:53:55PM +0100, Martin Rex wrote:
> Nicolas Williams wrote:
> 
> One of the drawbacks of SPNEGO undoubtedly is, that only addresses
> the future and does not solve the problem for the existing non-SPNEGO
> installed base.  (One of the reasons why it is hardly used).

This is a drawback of the GSS-API implementations.

> No it is *NOT*.
> GSS-API is a service provider that offers "authentication",
> and optionally message protection services: message integrity
> and maybe additionally message integrity combined with message
> confidentiality.  It is an mere assumption that the gssapi mechanism
> uses crypto as we know it and performs a key exchange.

Right. But in order to provide message signing/encryption a key must be
established and it is the responsibility of the GSS-API mechanism used
to do so. In effect, this means that GSS-API is a "a key exchange or key
establishment service" wherever the underlying mechanisms are.

> Look at the spec, in particular at the SPNEGO spec.  GSS-API v2 allows
> mechanisms that provide ONLY authentication and no message integrity
> and message privacy services.  The Microsoft NT Lan Manager protocol
> is one example.  In particular, when you perform NTLM "authentication"
> to a server on a Win95/98 machine, you will not establish a shared secret.
> NTLM uses a challenge response scheme based on a password, i.e. it
> uses a shared secret, but it doesn't create one.

Right. See above.

> Even for those gssapi mechanisms that establish a shared secret key,
> they are allowed to hide it from the application (e.g. in the TCB).
> Microsoft's W2K Kerberos could hide the keying material in the TCB
> if they wanted to (I don't know whether they do, and I don't know
> whether the session key can be accessed at the SSPI level --
> there is a request call, but does it return the key?).

GSS-API has no concept of separate key exchange and encryption
mechanisms. And the C bindings RFCs do not specify any API for obtaining
the key material where it is available, IIRC.

> Anyway, nobody above the GSS-API should care what the gssapi mechanism
> does with its keying material.

SPNEGO might, but SPNEGO operates within GSS-API, so I agree with this
statement.

> It exports the GSS-API interface and it has it's own mech_OID, but
> it is definitely not a gssapi mechanism (otherwise you could use
> it without needing any other real gssapi mechanism below it -- which
> you can NOT).

It is a mechanism, a pseudo-mechanism, to be precise (that's what the
RFC calls it). It wraps sub-mechanisms' GSS tokens and is useless
without real GSS mechanisms.

> SPNEGO is on top of GSS-API as far as gss-api mechanisms are concerned,
> and it is below GSS-API as far as applications are concerned.

This is what I said.

> Although SPNEGO was designed as a glue layer between GSS-API aware
> applications and real GSS-API mechanisms, once you try to implement
> such a thing you will realize that it's close to impossible to make it
> plug'n'play for arbitrary gssapi implementations.  I expect that those
> who do it make specific assumptions (i.e. meta-knowledge) about some
> implementations details or actively use cooperation from the underlying
> gssapi mechanisms beyond the GSS-API v2 spec.

Well, there is no GSS-SPI C Bindings specification, thus there is no way
to write portable GSS mechanism providers.

A GSS-SPI C Bindings RFC might be useful to MIT and/or Heimdal and any
vendor whose implementation is related to either of those (e.g., Sun?).

I wholly agree with this sentiment.

Nico
--