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

=?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.
> >
> > 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'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.

*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.

> 
> > First of all, the GSS-API mechanism should protect against replay
> > attacks all by itself.  Where that is insufficient, the additional
> > use of GSS-API channel bindings should do the trick.
> > At a first glance, the use of the SSL session ID should be sufficient.
> > (unless the SSL/TLS stack uses a really braindead algorithm to
> >  generate SSL session IDs.)
> 
> Replay or tunneling attacks is what I worry about. With the lack  
> checking of binding or folding keymaterial from gss-api into tls.
> 
> For example, an gssapi connection done in clear can be tunneled into
> a protected channel and if there is no verification that the sender/ 
> recviers have access to the resulting context (using gss_wrap/gss_get_mic)
> there is no actual authenticaition going on.
> 
> 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.)

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.

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).

> 
> Thats why I say that gss should contribute with/authenticate the key  
> material, either by prf or get-mic.
> 
> Thats why I say that gss-api is not a OTP/password system, you can't
> treat as it is.

If only the Kerberos authentication exchange is used for authentication
and there is no cryptographic link to the (application) data of the
communication, then Kerberos is basically reduced to an OTP scheme, correct!

With Kerberos, it remains an OTP with a specific target, but when multiple
targets (services) share the same key (which is not uncommon for Kerberos
on Unix and a pityful near Must on Microsoft Windows) and the authentication
tokens are sent in the clear (or can be obtained by MITM or some sort
of social engineering) then we have the same vulnerability
as every other OTP scheme.

We certainly can fix that vulnerability for gssapi mechanisms which establish
a shared session key during authentication.  Mixing keying material
that is cryptographically bound to the GSS-API exchange into the TLS
key establishment is one possible solution.  But I'm sure there are
many ways to skin the cat, and I'm very uncomfortable with the
one proposed in the current ID.

GSS_prf is (only) a partial solution.  However, I just noticed that
it currently suffers a fatal defect which bars its use in other
standards track protocols.  But that defect should be easy to fix.
Still, GSS_prf is a very new optional feature, and I firmly believe
we should neither completely ignore the installed base that doesn't have
it, nor those mechanisms that can not easily adopt it (like SPKM&friends,
which is neither fatally broken nor insecure, inspite of several problems
in the spec).

The problem of GSS_prf rfc-4401 is, that lacks a context attribute flag
(prf_avail BOOLEAN in rfc-2743 terminology, GSS_C_PRF_FLAG bit value (512)
 in rfc-2744 terminology) and semantics, so that the availability of this
extension can be signaled/negotiated between initiator and acceptor
(similar to how integ_avail and conf_avail must be signalled/negotiated)
so that the established security context correctly indicates whether
this feature is available on a security context (i.e. that
the implementations on both sides have confirmed to each other
that it is available), and indicate the result of this negotiation
through the (output) context attributes to the calling application.
Other than prot_ready and trans_avail, prf_avail is not an issue
of the local implemenation only.

>From what I remember how the signalling of integrity and confidentiality
context attriubutes/flags in Kerberos, this should be easy to specify
and almost trivial to implement.

Traditional GSS-API channel bindings (at least the stuff for which
I have seen example usage scenarios and how it is used with
FTP-GSSAPI) seem inadequate as a solution.  The cryptographic
binding of the gssapi message protection to the gssapi authentication
has always been considered an implicit feature.

We're discussing the combination of the GSS-API authentication
with message protection entirely outside of GSS-API, and I don't
remember any real discussions about this in CAT/Kitten before
GSS_prf, which is one of the reasons what traditional GSS-API
doesn't support it (the other is crypto-export politics, when
GSS-API was originally designed there were strict US crypto export
regulations and the GSS-API abstraction was also used to
keep crypto keys out of reach of the application caller
and to be able to enforce "integrity only" in spite of
a shared session key as a result of the authentication.
(Does anyone remember that Microsoft un-documented the "Seal/Unseal"
 calls in SSPI because of this?)

Anyway, I would really prefer if we devise a method to use
gss-api over tls with mechanism implementations that do NOT have
GSS_prf for the case that is not available.  I'm ok with the
use of GSS_prf when the defect in rfc4401 described above is
fixed and there is a requirement to use it only when the
context attribute confirms that both communication peers
implement GSS_prf (in an interoperable fashion, of course!)

In order to establish the cryptgraphic binding, we can likely not use
any "public" information in the fashion of traditional gssapi
channel bindings (like network transport addresses or the SSL
session ID (which I suggested)).

Since the original GSS-API design sort-of protects the keying material
from the application, we may need to "invent" a scheme using
gss_wrap/gss_unwrap with confidentility protection.

I get the feeling that we might not be able to provide a secure
binding of the encrypted TLS channel with the GSS-API authentication
for a mechanism that does not have GSS_prf and no confidentiality
protection, and not at all for an authentication-only gssapi
mechanism.  TLS encryption is no pixie-dust for the misappropriated
OTP token problem.

Does that mean that we should discriminate against such mechanisms
completely in our protocol design, trying to make them go away?
Personally, I consider it unlikey that password-based authentication
(disclosing as well as challenge-response) and OTP-schemes are
going to be abandoned soon, and that we can speed up the process
by not supporting them at all.  I'm afraid it would be frowned
upon for being a usability and interoperability problem with
existing authentication schemes.

And that would actually be true.  GSS-API was specifically designed
to *NOT* prevent the use of weak and broken security.  Think of
it as an enabling technology -- once you have switched all your
applications to use existing legacy authentication schemes
through GSS-API, the migration/transistion to a better
and more secure authentication scheme/system will be *MUCH*
easier.

So there is real value in the continued support of NTLM within
Microsoft Windows.  I'm just disappointed about the aggressive
fallbacks that have caused Microsoft to break and ship
their Kerberos unnoticed on more than one occasion.

Coming back to the original problem: a cryptographic binding
between the GSS-API authentication and the TLS message protection:

I definitely do not want to see this protocol flush the entropy
from the TLS key establishment down the toilet and replace it
with a (more often than not) lower entropy derived from
a shared session key resulting from the gssapi authentication.

Mixing both entropies would be OK, but there are probably again
many ways to skin the cat.

I'm all but a cryptographer.  AFAIK, mixing entropy from the
GSS-API authentication with the regular TLS-established 
pre-master secret with e.g. XOR might preserve most of what
TLS has achieved for us.

At the abstract level, we only need to make sure that this mixing
of entropy is applied in a synchrous fashion BEFORE application
data is accepted and before the TLS session is added to the
session cache.  However, I don't see an immediate requirement why
this must happen within the TLS handshake, and can not happen
after a GSS-API authentication exchange directly following
the TLS handshake.  We should consider the implications of our
decision -- like necessary changes to our software architecture
(like a protocol state machine) and modularization of our protocol
implementations.

I would strongly recommend to perform the GSS-API handshake entirely
under TLS protection, not just to protect the clients identity,
but also to prevent easy stealing of GSS-API context tokens
for replay in scenarios that continue to (ab)use GSS-API in
the authentication-only OTP style.

> 
> I'm fine with introducing gss+anon-dh, but then we will get multiple  
> DH's in stack. But you might be just fine with that.
> 
> gss+anon-dh will still expose the client infomation to an active  
> attacker in the case of gss-krb5.

I prefer RSA with self-signed cert any time over anon-dh, because
it enables me to (a) verify out-of-band and (b) memorize my decisions.

I have more trust to other people's PGP keys on my keyring that
I've verified myself on a PGP signing party or a personal encounter
than any of the CA-signed S/Mime signatures.

I also have more trust in the public host keys in my personal SSH known_hosts
file than to any CA-signed web-server certificate which my browser
considers trusted based on a list of >100 CAs and zero short-term memory.

I'm well aware that my personal preferences do not scale well to the
general public.  With my browser, I could flush the trust anchors
preconfigured by the vendor/provider and and start adding end-entity
server certs according to my personal verification preferences.
But the "ease of use" of the preconfigured Trust is so damn appealing
to my laziness.

Inappropriate and unlimited "Ease of use" might be the biggest
fertilizer of security problems and computer malware.

> 
> >> Saying SPKM doesn't support gss-psudeo random is just silly,
> >> SPKM doesn't support anything, its not implementable and
> >> I want better security then des/rc2.
> >
> > You seem to confuse the mandatory to implement symmetric ciphers
> > in rfc-2025 with the stuff that really gets used in productive
> > deployments.
> 
> "Do you seriously propose to give up on a mandatory-to-implement
> authentication scheme that will provide interoperability."
> 
> rfc2025 doesn't specifify how to do padding for CONF ciphers for non  
> des/des3.
> 
> INT is specififed using a stream key for des, but using rsa-sign- 
> <digest> for all other types. You like doing one RSA operation
> per packet ?
> 
> Everytime I look as SPKM I get sad. But this is not the right place  
> to talk about SPKM.

It's an emirical fact we cannot deny that purely theoretical review
of a spec leaves many defects.  Implementors have a much better
chance to find them, and ultimately independent implementors 
during interoperability tests.

This is why there are procotol maturity levels in the IETF,
and the prerequisite for draft standard are independent interoperable
implementations.

There were a lot of things to fix and clarify since rfc1510,
and also with SPNEGO.  And there are implementors that care much more
about interoperability between different revisions of their
own implementation than for interoperability with independent
implementations of the specification.  For vendors, there is
unfortunately and encomonic incentive to behave this way,
but this is often not in the interest of the general public. 

So part of the defects are regular toothing problems that are
to be expected.  My main criticism about SPKM and SPNEGO was
their heavy use of ASN.1, which has historically been a reliable
way to prevent high numbers of independent implementation and
early adoption, and it probably still is a huge roadblock
in theoretical review (because of a general lack of intimacy
with ASN.1 among implementors.  This may be attributed to
the fee-based distribution model of the ASN.1 specs and
the fact that it has been spread across a huge number of
documents and defect reports plus not fully backwards-compatible
revisioning.

-Martin

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls