Re: [TLS] the use cases for GSS-based TLS and the plea for

[Nicolas Williams <[e-mail]>]

On Fri, Jul 20, 2007 at 06:51:22PM +0200, Martin Rex wrote:
> =?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?= wrote:
> > > I agree that there should NOT be a need for a fully configured PKI.
> > >
> > > I completely disagree on the absense of a Certificate-based server
> > > credential.  A fallback self-signed cert is a no-brainer.

If the server has a cert, then it should use it.  The server can't know
whether the client will or will not care.

Using a cert, even a self-signed cert, has its advantages.  See
draft-johansson-http-tls-cb.

> > > Do you seriously propose to give up on a mandatory-to-implement
> > > authentication scheme that will provide interoperability when
> > > your locally-preferred authentication scheme (GSS-API) is
> > > unavailable.
> > >
> > > SSL started off with mandatory to implement ciphersuites in order
> > > to provide interoperability, and historically, these used a
> > > certificate-based credential.
> > 
> > Yes. I think there is an requirement to not need a x509 certificate  
> > at all to run the gssapi tls functionallity. How is this conflicting with  
> > anything you write above ?

I would think that this work is not about obviating the need for an
x.509 server cert, but about providing an alternate way of
authenticating either or both of the client and the server to the other.

The use of an x.509 cert by either party should not be precluded by the
use of the GSS-API; it should merely be made unnecessary.

> I'm confused.
> 
> We don't have a standard(s track document) yet, so currently we're
> discussing what potential requirements a standard for a combination of
> TLS encryption with GSS-API authentication should have.

That's true.  We should come up with a set of requirements, but I don't
think we necessarily need a separate doc to record these requirements
(just in case others do).

> *I* want to see a requirement for a server credentials in order
> to put pressure on the interoperability aspect.  Interoperability
> is important, and the previous specs used a certificate-based
> credential for this purpose.  We all know pretty well that
> popular gssapi mechanism like Kerberos5 have a serious
> inter-organisation interoperability problem, and that is
> unlikely to go away anytime soon.  So to provide interoperability
> from the beginning we ought to stick to the one authentication
> scheme that currently works best cross-organization.

So why bother with this doc then?  Why not just say: "if you want to use
TLS then deploy a PKI?"  (And to the question of where to store user
creds, one answer that comes to mind would be kx509, another would be
SACRED.)

No, we want this work because in some environments you don't want to
have to bother with PKI when you already have Kerberos V or something
else.  Hand-waving about "serious inter-organisation interoperability"
problems in Kerberos V isn't a serious argument for requiring that a
server-side x.509 cert always be used when the GSS-API is used as well.

> > On real world example of this is using ssh this the gss-userauth
> > (not gss-userauth-with-mic), then an attacker can pick up an ftp-gss
> > connection to the same host and tunnel it into the ssh connection
> > and get logged in.
> 
> 
> Very good point. (Although I needed a few minutes to understand
> what you are describing.)

The SSHv2 thing was about channel binding -- we needed to bind the
GSS-API authentication to the SSHv2 session's initial key exchange and
algorithm negotiation.  The SSHv2 work did not use the channel binding
facility of the GSS-API; instead it used MIC tokens to achieve much the
same effect.

> I hadn't thought of this so far.
> 
> But now as you mention it, there's a deja-vu.  It think this same
> vulnerability that has been described for krsh and krlogin long ago.

Can't have been: there's no channel to bind there.  The issue is related
though (see below).

The problem in the SSHv2 case was that an active attacker could act as
an MITM (though this might depend on the user answering "yes" to the
unknown hostkey question; but users always say yes to the "are you sure
you want to give all your money to this guy?" dialogs).  By binding the
GSS-API context to the SSHv2 session the server could ensure that there
was no MITM.  See below.

> It probably affects all communication where the Kerberos gssapi
> authentication exchange is "in the clear" and the successor
> communication is not at least integrity protected with the
> session key from the authentication (independent of the protocol,
> be it some kind of RPC or network file system or rfc4559).

Right, if you use krsh/krlogin/telnet you want to ensure that you don't
merely authenticate but that you protect the whole session also (rlogin
-x ...).  But really, you shouldn't use krsh/krlogin/telnet -- just use
SSHv2.

By not doing channel binding in SSHv2 what was happening is that we had
the equivalent of using the GSS-API only for authentication and not for
protecting the whole session.

Nico
-- 

_______________________________________________
TLS mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tls