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

[Larry Zhu <[e-mail]>]

Martin Rex wrote:
> The FXA-TLS ID says "the client MUST request mutual authentication"
> and continues with "MUST fail if not available", and this is where
> it obviously introduces the "acceptor-to-initiator" authentication.

> GSS-API traditionally implied initiator-to-acceptor authentication.
> When the initiator requests "mutual authentication", it is actually
> a request for "acceptor-to-initiator" authentication.

> The "acceptor-to-initiator only" authentication, which is what is
> commonly used by Web-Browsers with HTTPS these days would be
> GSS-API with anonymous client credentials requesting mutual
authentication
> Anonymous (initiator) credentials are not very well-defined and
> supported by very few gssapi mechanisms these days).  Anonymous
> acceptor credentials are somewhat more common, they're required
> for gssapi mechanisms that are unable to perform acceptor-to-initiator
> authentication, e.g. challenge-response mechanisms like NTLM.

> So the mutual flag is somewhat of a misnomer, witnessing that
> originally one didn't think about mechanisms where the client
> would not be authenticated.

Let's move pass this please. I would clarify that this ID does not call
for acceptor-to-initiator authentication.

> PSK cipher suites are already a big prerequisite and significant
> unnecessary burden.

> I would prefer an extension approach that could be built with minor
> modifications to an existing SSLv3-only stack in a small amount of
time,
> using only the available SSL ciphersuites.

Throw you ideas, you have all my ears. Personally I believe the existing
selection that is based on the cipher suites works fine and it is a
time-proven model. I would object to adding extra complexity here.



> I'm not aware that there is a generic GSS PRF spec.  I know there is
> one for Kerberos, and that some people confuse GSS-API with Kerberos.

> Implementors of SPKM (rfc-2025) will first have to standardize
> on a prf before they can implement it, which is a HUGE burden.

Let me reiterate, the PRF RFC is new, but the PRF operation is not new
to implementations. And let me also reiterate that the ID does not want
to plug in any GSS-API mechanism. SPKM is a deprecated and broken one
that IETF does not intend to support.

We have enough said, please move on.

> I didn't say that it can not work without, just that the security
> level of the GSS-API mechanism itself is marginal at best when
> compared to TLS.

> I think that a protocol providing a standardized GSS-API
authentication
> for a TLS-protected communication channel should not discriminate
against
> or preclude whole classes of gssapi mechanism -- if it did, it should
> not be considered for IETF standards track, because we certainly can
> do much better.

It is the choice of the policy as how cipher suites are selected today.
This ID does not change that, please move on for this.

> It unecessarily puts the authentication exchange into the cleartext
> section of the TLS handshake.  We already know that this is considered
> a problem for the client certificate message in the existing
> SSL/TLS handshake, why should we repeat this known mistake when
> it can be easily avoided?

You can use TLS protect the handshake, you can do that today. How to do
that is just NOT within the scope of this draft.

Again, in certain aspects, we are just trying to make PSK-TLS more
deployable and fix the mutual auth problem in PSK-TLS. We move the
GSS-API handshake down to the TLS stack to provide a platform solution
so everything on top can benefit from it.


> I'm all for layering protocol stacks.  However I totally disagree
> about the layering sequence.  I firmly believe that the GSS-API
> implementation should be called by a communication layer on top
> of regular TLS, and provide a TLS-with-added-value, instead
> of a forced marriage as required for FXA-TLS and its predecessor
> proposal.

GSS-API is designed to work without TLS protection. Just think how SASL
works you should appreciate the work here.

> You should know pretty well.  You're involved in the FAST-Armor vs.
StartTLS
> discussion which addresses know weaknesses in specific
> authentication exchanges that are in common use and can not be easily
> abandoned.

> Many WindowsXPsp2 machines perform regular NTLM authentications these
days
> because of a serious bug in the sp2 Kerberos.dll.  (which is fixed by
>>KB885887, but that Hotfix is still not publicly available and SP3
> is delayed for whatever strategic reasons).

I do not know how you can relate any of these to this work.

> We are already at a level of complexity where dirty hacks will create
> HUGE problems already in the short run.

This is a generic and extensible solution.

> There are no such things as homogeneous environments.  And even
> the homogeneous new installations that your seem to have in mind
> are going to the the heterogeneous environments of tomorrow, when
> a new feature or scheme comes up that people what to use (and
> for which they need a migration path).

> If we get smooth cooperation of GSS-API based and traditional
> certificate-based Server authentication this time around, this
> will likely reduce the pain and suffering for the next
> transition.

Again, I do not know how any of the points you raised is related to the
work here.

--larry
-----Original Message-----
From: Martin Rex [mailto:[e-mail]] 
Sent: Tuesday, July 17, 2007 1:38 PM
To: Larry Zhu
Cc: [e-mail]
Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for
integrating

Larry Zhu wrote:
> 
> Martin Rex wrote:
> > - It requires hostbased service names plus mutual authentication,
> >   altough the majority of gssapi mechanism does not implement
> >   hostbased service names and a significant fraction of
> >   "simple" gssapi mechanisms doesn't provide acceptor-to-initiator
> >   authentication at all.
> 
> Where is the acceptor-to-initiator introduced here?

The FXA-TLS ID says "the client MUST request mutual authentication"
and continues with "MUST fail if not available", and this is where
it obviously introduces the "acceptor-to-initiator" authentication.

GSS-API traditionally implied initiator-to-acceptor authentication.
When the initiator requests "mutual authentication", it is actually
a request for "acceptor-to-initiator" authentication.

The "acceptor-to-initiator only" authentication, which is what is
commonly used by Web-Browsers with HTTPS these days would be
GSS-API with anonymous client credentials requesting mutual
authentication
Anonymous (initiator) credentials are not very well-defined and
supported by very few gssapi mechanisms these days).  Anonymous
acceptor credentials are somewhat more common, they're required
for gssapi mechanisms that are unable to perform acceptor-to-initiator
authentication, e.g. challenge-response mechanisms like NTLM.

So the mutual flag is somewhat of a misnomer, witnessing that
originally one didn't think about mechanisms where the client
would not be authenticated.



> 
> >- It requires the brand-new optional extension "GSS_Pseudo_random"
> >   from a gss-api mechanism, which the majority of existing
> >   mechanism do not implement, and which can not be provided
> >   by a significant fraction of gss-api mechanisms that do
> >   not provide confidentiality protection and is impossible to
> >   provide by authentication-only mechanisms.
> 
> I beg to disagree on this. The FXA-TLS ID defines a generic and
> extensible mechanism to allow 
> the use of off-shelf GSS-API libraries, but it does not encourage the
> use of arbitrary GSS-API mechanism for the TLS handshake.
> Apps will pick and choose which GSS-API mechanism to support.
> 
> This is in analogy and consistent with the fact that how you choose to
> negotiate the RFC4279 PSK cipher suites. This differs from RFC4279 in
> that using RFC4279 you do not authenticate the server other than to
the
> extend that the server knows the shared key and that key may be shared
> among multiple services on the server host.

PSK cipher suites are already a big prerequisite and significant
unnecessary burden.

I would prefer an extension approach that could be built with minor
modifications to an existing SSLv3-only stack in a small amount of time,
using only the available SSL ciphersuites.


> 
> The GSS PRF is designed to be very light-weighted to be implemented.
> Most existing GSS-API already have implemented it one way or the
other.
> The PRF RFC is new, but it is not new at all to implementations.

I'm not aware that there is a generic GSS PRF spec.  I know there is
one for Kerberos, and that some people confuse GSS-API with Kerberos.

Implementors of SPKM (rfc-2025) will first have to standardize
on a prf before they can implement it, which is a HUGE burden.


> 
> >- it performs the gssapi handshake in the clear before the
> >   TLS encryption applied.  It would be much better if the
> >   GSS-API authentication is performed within a tunnel that
> >   is already TLS-protected, so that the cryptographic
> >   strength of both add up for network-level attacks.
> 
> If an GSS-API mechanism cannot work without TLS protection, it should
> NOT be selected according to this draft.

I didn't say that it can not work without, just that the security
level of the GSS-API mechanism itself is marginal at best when
compared to TLS.

I think that a protocol providing a standardized GSS-API authentication
for a TLS-protected communication channel should not discriminate
against
or preclude whole classes of gssapi mechanism -- if it did, it should
not be considered for IETF standards track, because we certainly can
do much better.

>
> Furthermore this draft does not
> prevent the gss-api data from being protected by TLS. People want to
do
> that already do it. It is just not within the scope of this draft. 

It unecessarily puts the authentication exchange into the cleartext
section of the TLS handshake.  We already know that this is considered
a problem for the client certificate message in the existing
SSL/TLS handshake, why should we repeat this known mistake when
it can be easily avoided?


> 
> This draft wants to move the GSS-API down to the TLS stack. This way
all
> upper layer protocols would benefit from it automatically if it is
> chosen based on the negotiation layer.

I'm all for layering protocol stacks.  However I totally disagree
about the layering sequence.  I firmly believe that the GSS-API
implementation should be called by a communication layer on top
of regular TLS, and provide a TLS-with-added-value, instead
of a forced marriage as required for FXA-TLS and its predecessor
proposal.


> 
> 
> >  Recent TLS implementations provide fairly strong protection,
> >  and to make use of any TLS extension in this area, a new TLS
> >  implementation will be required.  The involved GSS-API mechanism
> >  will almost always be legacy, and fairly weak in comparison to
> >  a recent TLS.
> 
> Can you provide a concrete example? And we can analyze that if you do.
I
> do not have an example myself, but I can envision similar advances
would
> have to be made into Kerberos, and we do not lose the protection
> end-to-end in such situations. Integrating GSS with TLS gives us the
> most economical way to innovate and reduce the proliferation of
> mechanisms.

You should know pretty well.  You're involved in the FAST-Armor vs.
StartTLS
discussion which addresses know weaknesses in specific
authentication exchanges that are in common use and can not be easily
abandoned.

Many WindowsXPsp2 machines perform regular NTLM authentications these
days
because of a serious bug in the sp2 Kerberos.dll.  (which is fixed by
KB885887, but that Hotfix is still not publicly available and SP3
is delayed for whatever strategic reasons).


> 
> > Doing it in the fashion that Stefan is looking for means that one
will
> have to merge GSS-API and TLS with a sledge hammer, and will be
> extremely > 
> > difficult to impossible to adopt by very common environments that
> terminate the SSL/TLS communication at the edge of a backend
distributed
> > 
> > system(reverse proxies, SSL Accellerators as closed third-party
boxes,
> etc.)
> 
> Not all gss-api mechanisms are created equal. The TLS client need to
> choose the GSS-API mechanism in the same way it need to select which
set
> of ciphersuites to support. This is a very consistent and time-proven
> model. There is no one arguing for a plug-&-play model that allows the
> plug-in of any GSS-API mechanism to TLS.

There is significant interest in plug-n-play arbitrary gssapi mechanisms
into a single gssapi multi-mechanism.  Is it really that difficult to
predict that people will want a choice of the gssapi mechanism that
they use with TLS?

The one thing that can be loaded off to (the) TLS (handshake) is the
common gssapi mechanism selection (no optimistic token).  But that
could be done in a fairly generic black box fashion (independent
of any particular gssapi mechanism/implementation).


I consider the lack of support for virtual hosts in (base) SSL/TLSv1
an issue that should be addressed and solved by a GSS-API authentication
for TLS standard.  And it should be solved in a transparent fashion
for TLS using a regular SSL server certs and TLS using GSS-API based
server authentication.

Very few GSS-API mechanisms allow for "automatic selection" of
server credentials during gss_accept_sec_context().

Since the creation of credentials is EXPLICITLY made a local
issue of an implementation, no standard based on GSS-API should
make an assumption as to whether a gssapi mechanism can
automatically determine and correctly acquire a matching
server credential when gss_accept_sec_context is called
with GSS_C_NO_CREDENTIAL.  In fact, most gssapi mechanism
implementation are not able to do this.


> 
> I would like to request to have meaningful technical discussions
before
> making a conclusion prematurely. 
> 
> <Krb-wg chair hat on>
> 
> The scenarios for securing TLS using Kerberos are very compelling, and
> this draft provides the simplest way to provide a secure solution that
> the industry badly need. The industry will do it with or without IETF.


I thought this is about authentication a secure TLS channel using
a GSS-API mechanis.

I agree that such a possibility would be greatly appreciated.

We currently have the situation that we can use GSS-API based
Single Sign-On with our legacy frontends, but not with the
HTTP-based newer frontends.

Right now, single sign-on is only possible if the GSS-API based
Single Sign-On is based on PKI (i.e. SPKM-like) with X.509 certs
and offers a possibility to furnish the browser with either
the PKI credentials or a PKCS#11 access to these credentials.


The possibility to offer GSS-API based authentication for the
HTTP-based access as well would be great, but in order to support
that on our backends, we would need an approach which flies
with NO CHANGES whatsoever to an existing GSS-API mechanism
and EXTREMELY low impact changes to an exiting SSLv3 implementation...


> 
> If IETF wants to stay relevant in today's fast paced world, it should
> not delay the process and work out a solution that is consistent with
> the IETF framework. The current process is simply not acceptable and
> completely violates the IETF tenet.
> 
> <krb-wg chair hat off>

We are already at a level of complexity where dirty hacks will create
HUGE problems already in the short run.

There are no such things as homogeneous environments.  And even
the homogeneous new installations that your seem to have in mind
are going to the the heterogeneous environments of tomorrow, when
a new feature or scheme comes up that people what to use (and
for which they need a migration path).

If we get smooth cooperation of GSS-API based and traditional
certificate-based Server authentication this time around, this
will likely reduce the pain and suffering for the next
transition.


-Martin


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