Subject: [TLS] the use cases for GSS-based TLS and the plea for integrating Kerberos with TLS: draft-santesson-tls-gssapi

From: Larry Zhu <[email-masked]>
Date: Mon, 16 Jul 2007 20:27:43 -0700

As we know -02 was published and it integrates Kerberos-alike GSS
mechanisms with TLS by importing the GSS key as PSK. It does so to
minimize the impact to the TLS state machine.

http://www.ietf.org/internet-drafts/draft-santesson-tls-gssapi-02.txt

EKR requested us to nail down the use cases for this protocol and
explain the rational for the integration.

In response, the ID revision -03 contains the use cases and why we want
to integrate Kerberos with TLS, particularly in the introduction
section.

http://www.secure-endpoints.com/tls-gss/draft-santesson-tls-gssapi-03.tx
t

The flowing document based on email posted by Larry Zhu describes
additional background information for the protocol design.

http://www.secure-endpoints.com/tls-gss/fka-tls.txt

thanks,

--larry

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

---

From: Martin Rex <[email-masked]>
Date: Tue, 17 Jul 2007 20:40:42 +0200 (MEST)

> explain the rational for the integration.

On first reading, it doesn't appear much different from the last
proposal und suffers the same problems

 - The GSS-API token exchange is still within the TLS handshake
   (a little earlier than in the last proposal, but still within
    and with an unpredictable amount of additonal round-trips).

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

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

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

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

Personally, I firmly (and still) believe that this is an entirely
wrong approach.

The most interesting aspect of GSS-API is being able to authenticate
clients (because this is where the costs are when personalizing
credentials).  For the server side, the authentication should
be designed to always support both, GSS-API based authentication
AND SSL-Server certificate based authentication, to provide the
interoperability with the installed base that one has come to
expect from SSL/TLS.

The most sensible approach, and the one with the least impact
on existing TLS would IMHO be to perform GSS-API authentication
after a regular TLS handshake and use channel bindings based
on existing TLS secure channel information.  With such a design
no changes to the TLS state machine are necessary, only an
extension to signal/negotiate availability/use of the
additional message exchange following the TLS handshake.

For distributed servers, it would even be possible to move the
GSS-API handshake entirely into the backend (and not
on the reverse proxies, SSL accellerators and such).
The necessary hooks into SSL/TLS are an extension indicator
for the handshake plus the secure channel bindings info of
the underlying SSL/TLS session, and that is completely
independent of any particular gssapi mechanism.

Building a additional layer which calls into your favorite
GSS-API off-the-shelf GSS-API mechanism and also into
a pretty much vanilla TLS stack, while providing an API
to applications that look like a regular TLS stack
will be a much more sensible approach to the underyling problem.

I would not want to see a forced marriage of TLS with GSS-API,
where TLS needs to be changed significantly, and where there
are so many limitations on what GSS-API mechanisms may be
used with this and the resulting impact on security. 

-Martin

---

From: Larry Zhu <[email-masked]>
Date: Tue, 17 Jul 2007 12:23:08 -0700

>   "simple" gssapi mechanisms doesn't provide acceptor-to-initiator

Where is the acceptor-to-initiator introduced here?

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

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.

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

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.

>   will almost always be legacy, and fairly weak in comparison to

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.

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

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. 

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>

> interoperability with the installed base that one has come to

Yes, this is specifically called out in -03. We have a separate section
for it.

>will be a much more sensible approach to the underyling problem.

Again, I have stated my points on this just now.

--larry

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Tuesday, July 17, 2007 11:41 AM
To: Larry Zhu
Cc: [email-masked]
Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for
integrating

 

-Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 17 Jul 2007 22:37:39 +0200 (MEST)

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

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

> 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

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?

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

> most economical way to innovate and reduce the proliferation of

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

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

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

> completely violates the IETF tenet.

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

---

From: Larry Zhu <[email-masked]>
Date: Tue, 17 Jul 2007 16:04:22 -0700

> would not be authenticated.

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

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

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

> not be considered for IETF standards track, because we certainly can

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

> of a forced marriage as required for FXA-TLS and its predecessor

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

> is delayed for whatever strategic reasons).

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

> HUGE problems already in the short run.

This is a generic and extensible solution.

> will likely reduce the pain and suffering for the next

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:[email-masked]] 
Sent: Tuesday, July 17, 2007 1:38 PM
To: Larry Zhu
Cc: [email-masked]
Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for
integrating

GSS-API with anonymous client credentials requesting mutual
authentication

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.

> most economical way to innovate and reduce the proliferation of

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

-Martin

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Wed, 18 Jul 2007 18:18:33 +0200

Comment on the draft draft-santesson-tls-gssapi-03.txt

- An important goal to meet is enabling use of authentication
   infrastructure of the GSS mech for server and client
   authenticiation. When using gss server authentication, thers shold
   be no need to have a certificate on the server.

- Feedback of key-data from the GSS-MECH back into the tls
   statemachine. GSS-API is more then a glorified OTP/password system,
   it provides key material that should be used, this solves problems
   like replay attacks w/o the need for a replay cache, etc.

- I would prefer having both the ability to run gssapi in clear and
   inside a DH protected tls connection. But it should run inside TLS
   and not the application layer. I.e., not http negotiate yet again.
   Saying that all gss mechs are cryptographicly weak is wrong, saying
   they are strong are also wrong. Should provide both, or just define
   cryptographicly weak gss-mechs as out of scope for this
   solution. Defining a solution that only uses the weak mech's
   functionally seems, well, weird and quite unfriendly.

- If its required to have DN for authorisation, well have the gss-mech
   define that then. I really don't like how everytime naming get up,
   its assumed that TLS naming today accully works, how many apps
   actually does correct authorisation with tls certificate based
   naming today, and why should they work with gss-style names ?

This proposed solutions fixes 1, 2, 3, and 4. But thats becase I
think weak gss mechs should be thrown out the window.

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.

Love

---

From: Larry Zhu <[email-masked]>
Date: Wed, 18 Jul 2007 09:41:49 -0700

Love Hörnquist Åstrand wrote:

>   inside a DH protected tls connection. 

In fact you have this ability in draft -02/-03.

 the protocol defined in this draft is generic and extensible, such that you can build the DH protection logic into the GSS-mechanism to encrypt GSS-API data for the real mechanism such as digest. 

even better, you do not need to do that for every real GSS-API mechanism, instead, you can define a stackable protection GSS-mechanism like SPNEGO, and use that to protect for the real GSS-API mechanisms.

do you agree?

--larry

________________________________

From: Love Hörnquist Åstrand [mailto:[email-masked]]
Sent: Wed 7/18/2007 9:18 AM
To: Larry Zhu
Cc: [email-masked]
Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for integrating Kerberos with TLS: draft-santesson-tls-gssapi

Love

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Wed, 18 Jul 2007 18:51:54 +0200

18 jul 2007 kl. 18.41 skrev Larry Zhu:

>  the protocol defined in this draft is generic and extensible, such  
> that you can build the DH protection logic into the GSS-mechanism  
> to encrypt GSS-API data for the real mechanism such as digest.
>
> even better, you do not need to do that for every real GSS-API  
> mechanism, instead, you can define a stackable protection GSS- 
> mechanism like SPNEGO, and use that to protect for the real GSS-API  
> mechanisms.
>
> do you agree?

No.

If the gss mech is weak and needs dh/rsa, may it should a requirement  
to have use server certificates. I'm tired of sprinkling DH everywhere.

Love

> integrating Kerberos with TLS: draft-santesson-tls-gssapi
>

---

From: Martin Rex <[email-masked]>
Date: Wed, 18 Jul 2007 20:24:18 +0200 (MEST)

>    be no need to have a certificate on the server.

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.

>    like replay attacks w/o the need for a replay cache, etc.

Do you know of a weakness in TLS that we don't, or what is your
rationale for this.  As I already described, the majority of
GSS-API mechanisms doesn't have gss_prf and for an entire classes of
GSS-API mechanism it is impossible to provide keying material or
gss_prf.  In order to mix GSS-API-based keying material into the
TLS key exchange you will have to MESS severely with TLS internals.

Unless you can show that TLS key establishment is weak or broken,
such messing around with TLS internal is a pretty bad idea -- and
even if you could show -- we should rather fix TLS instead of
messing with the TLS key exchange.

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

>    functionally seems, well, weird and quite unfriendly.

There is a substantial security benefit in being able to perform
the GSS-API authentication under TLS encryption, namely to protect
the identity of the client from network-level sniffing.  We have
heard repeated request for protection of the SSL client cert,
which unfortunately travels in the cleartext portion of the
SSL handshake (probably in an attempt to simplify the SSL state machine
to make the encrypted part of a full handshake and the encrypted part
of a session resume alike).

Can you provide any technical reasons why a solution should provide
for GSS-API authentication in the cleartext part of the communication?

"I like it" and "it's easier for me to read network traces" do not describe
convincing technical benefits.

>    naming today, and why should they work with gss-style names ?

Actually, TLS does NOT do naming at all.  That has been explicit
in the specs from the beginning.  The details of the authentication
process is outside of the scope of TLS and must be addressed by
communication protocols built on top of TLS (like HTTP over SSL/TLS).

The document under discussion breaks with this tradition
in a pretty bad and totally unnecessary fashion. 

> think weak gss mechs should be thrown out the window.

The strength of a cryptographic protocol wears off (quickly) over time.  

This is one of the reasons why I would greatly prefer an approach
orthogonal to the TLS protocol engine.  If you do the GSS-API handshake
after the TLS handshake, under TLS protection, using the SSL Record
protocol and probably with a different "container tag" than regular
application data (so no-one will confuse it with application data),
then improvements to TLS (like new and stronger ciphersuites)
can be used as soon as they become available, entirely independent
of the inner GSS-API authentication and without having to update
the gssapi-over-tls specification. 

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

About 6 different vendors have certified for interoperability
with our application with SPKM-based gssapi mechanisms and
4 more with SPKM-like mechanisms.  Doing this costs them real money,
and they wouldn't have done it when there weren't any of our customers
using these third-party products and paying for it.

As I've been saying before the big advantage of the PKI-based 
gssapi mechanisms for Single Sign-On is, that it is possible to
share the credentials with the Web-Browser and re-use Single Sign-On
between off-the-shelf Web-Browsers and off-the-shelf Web-Servers
already today.  We've been doing this on company-wide scale for
the last 6 years.

I'm getting the impression that it might be much easier for me
to write an I-D with a well-designed proposal than to continue
bashing on draft-santesson-tls-gssapi-03.txt

But I'm not a TLS expert (I only have been doing support and
some improvements the last 6 years for an OEM library that we ship),
and would need help/advice on how to add the extension with
the least possible impact the maximum orthogonality to the
TLS architecture (in order to continuously benefit from TLS evolution).

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 18 Jul 2007 20:46:11 +0200 (MEST)

Larry Zhu wrote:
> mechanism, instead, you can define a stackable protection
> GSS-mechanism like SPNEGO, and use that to protect for the
> real GSS-API mechanisms.

Ouch.

With a simple mechanism (OID) negotiation logic within a
Hello extension, we could get rid of SPNEGO entirely for gssapi-tls.

This would have many advantages:
 - when the common mechanism OID selection is built into
   a TLS extension, then TLS can simply perform the regular
   SSL handshake when no common mechanism is available.

 - it completely avoids the entire SPNEGO codebase.
   a large part of the installed base of GSS-API mechanism doesn't
   have SPNEGO, and as I've said, we would have compelling use
   cases if the scheme would work with the existing installed
   base (of gssapi mechanisms) and without SPNEGO and minimalistic
   changes to SSL/TLS.

   Changes to the Web-Browsers and Web-Servers are necessary,
   of course, but with such a low-impact change as I have been
   describing throughout my last postings, the necessary small
   changes for Browsers like Firefox and TLS implementations would
   come within a few weeks.  And I would give this a much better
   chance to get implemented into our backends and SSL 

 - and additional multi-mechanism glue layer would be entirely
   unnecessary in this scenario.  A server or browser could
   simply load and use the negotiated GSS-API mechanism directly.

Btw. thinking about the security context establishment of GSS-API:
there is no size limit on the context-level tokens within GSS-API.
Although a single SSL Record of 16K would be sufficient for the
majority of environments (gss-api mechanisms) that I have seen,
extensive use of X.509v3 extensions (attributes,constraints,policies,
URLs,disclaimers,digital-junkyard-of-your-favorite-CA) as well
as PACs or similar bloat in Kerberos certificates might exceed 16K.
so a simple framing protocol for the gssapi context level
tokens might be needed.

-Martin

---

From: Larry Zhu <[email-masked]>
Date: Wed, 18 Jul 2007 12:51:20 -0700

> bashing on draft-santesson-tls-gssapi-03.txt

This sounds very constructive and promising. 
I am happy that you support the work.
 
Instead of writing a separate draft, you can update the ID with your proposal, unless you have a complete different beast. We do not need to have two different proposals doing the same thing if we can agree with the proposal you are making.
 
I am very pleased that we are making progress on this now. 

In the meanwhile, I would like to have more reviewers commenting on this effort. Please tell us what you think.

Thanks,

--larry
-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Wednesday, July 18, 2007 11:24 AM
To: Love Hörnquist Åstrand
Cc: Larry Zhu; [email-masked]
Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for

-Martin

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Thu, 19 Jul 2007 21:19:04 -0400

> 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 ?

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

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.

> convincing technical benefits.

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.

> in rfc-2025 with the stuff that really gets used in productive

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

> using these third-party products and paying for it.

And yet, rfc2025 (spkm) doesn't specify a default dh group, nor a way to
negotiate them.

> TLS architecture (in order to continuously benefit from TLS  

Clearly we are no TLS experts either.

Maybe you could write a simple document that describe how you
want it to work so Larry, Stefan and Jeff can see if that is acceptable
for their problems and let them fill out the rest ?

Love

---

From: Martin Rex <[email-masked]>
Date: Fri, 20 Jul 2007 18:51:22 +0200 (MEST)

=?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?= wrote:
> 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.

> checking of binding or folding keymaterial from gss-api into tls.
> 
> recviers have access to the resulting context (using gss_wrap/gss_get_mic)

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

> material, either by prf or get-mic.
> 

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.

> DH's in stack. But you might be just fine with that.
> 
> 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.

> <digest> for all other types. You like doing one RSA operation
> per packet ?
> 
> 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

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 20 Jul 2007 12:18:38 -0500

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

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

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

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

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

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

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

---

From: Martin Rex <[email-masked]>
Date: Fri, 20 Jul 2007 19:40:34 +0200 (MEST)

> creds, one answer that comes to mind would be kx509, another would be

What I meant (and forgot to add) was "certificate-based credential
(self-signed when no PKI is used) as a mandatory to implement
feature for interoperability".

If support of cert-based credentials is a mere MAY, then I am sure
there will be servers/services where installing or using a PKI
credential is impossible/defective/unusable, and you cannot complain
to the vendor because not-supporting it is fully compliant with the spec.

Everyone will be happy when Kerberos can be used cross-organization
one day.  But until that day, I want to make sure that the customer
has the working alternative to use PKI when there is a need for it.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 20 Jul 2007 12:50:53 -0500

> to the vendor because not-supporting it is fully compliant with the spec.

I don't think this spec aims to change TLS 1.1 to make any current
cipher suites that are REQUIRED to implement no longer REQUIRED to
implement.  Nor would I support that, for interop reasons, of course.

Nico
--

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 20 Jul 2007 13:55:59 -0400

> has the working alternative to use PKI when there is a need for it.
Let me rephrase what you want:

* You do not want to require that a server certificate be used when a
TLS_GSS cipher is selected

* You do want to require that all TLS implementations support for the
certificate based ciphers

Note that while we can standardize implementation requirements, we
cannot standardize the deployment requirements. 

No one that is promoting TLS GSS wants to eliminate the use of
certificate based TLS ciphers.  The purpose of adding the TLS GSS
ciphers is to provide a solution for environments that certificate
management costs exceed the costs of the pre-existing infrastructure.

Jeffrey Altman

---

From: Martin Rex <[email-masked]>
Date: Fri, 20 Jul 2007 20:19:24 +0200 (MEST)

> implement.  Nor would I support that, for interop reasons, of course.

This isn't about what the TLS implementation supports, but what
subset of the TLS implementations features a server/service
is able to use.

The hard part of the work isn't the code, it is the configuration
and administrative UI stuff.

As I wrote in previous Emails, I think the gssapi-over-tls authentication
should be put into a module "TLSplus" above a mostly vanilla TLS and next
to completely vanilla GSS-API and look like a normal TLS for the
application caller.  Implementors will probably use different approaches,
some will not provide seperate module and not be able to plug'n'play
gssapi mechanisms.  Others may want to offer exactly this modularization,
and especially the gss-api plug'n'play.

For the architecture I've been trying to describe, ABI issues and
binary plug'n'play is fairly easy compared to the interoperability
issues among independent implementations (at least if you do a certain
level of QA on the API -- tough luck, Solaris Kerberos included
SunOS 5.9 still contains numerous API-level bugs in the GSS-API
they should consider adopting several 10-year old fixes from MIT
Kerberos GSS-API).

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 20 Jul 2007 13:21:22 -0500

> subset of the TLS implementations features a server/service

See Jeff's point about implementation versus deployment.

We could require the use of a self-signed cert if no PKI is available,
but, why?  (I gave an answer, of course, related to
draft-johansson-http-tls-cb).

---

From: Martin Rex <[email-masked]>
Date: Fri, 20 Jul 2007 20:28:26 +0200 (MEST)

> TLS_GSS cipher is selected

Nope.  I completely dislike the lack of orthogonality to TLS on
this issue.  I do NOT want the gssapi-over-tls require any particular
ciphersuite (instead work with those that are there and future ones),
and in particular I do this spec NOT want to define a new cipher
suite.

> certificate based ciphers

I want a mandatory to implement subset of ciphersuites.  SSLv3 had
this and from what Nico says, TLSv1.1 might still have it.
(I'm behind on TLS evlutionary changes).

> cannot standardize the deployment requirements. 

We can not require which buttons the customer presses on installation,
but we can require which buttons must be available to the customer for
installation/configuration. 

> management costs exceed the costs of the pre-existing infrastructure.

I have _never_ disputed this motivation.  And I certainly do not
want to take this freedom away from the customer.  However, I clearly
want to deny the vendor a compliance tag for not providing a fully
functional option to the customer.

-Martin

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 20 Jul 2007 14:45:53 -0400

> functional option to the customer.
Martin:

That is exactly what mandatory to implement means.  The vendor must
implement it to be considered in compliance.

However, you can't mandate in an IETF standard what is deployed by the
users of the implementation. 

My requirement is that TLS be deployable without certificates if an
alternative mechanism for managing keys distribution is available.   I
have that today with RFC 2712.  

Jeffrey Altman

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 20 Jul 2007 14:49:25 -0400

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Friday, July 20, 2007 12:51 PM

[Many excellent points and much cogent discussion snipped ...]

-----End Original Message-----

It seems strange to criticize SPKM and SPNEGO for being ASN.1-based
while not making the same criticism of Kerberos.   To what extent
has the adoption and theoretical review of Kerberos been hampered
by this "huge" roadblock?   And of course, SNMP
(http://www.ibr.cs.tu-bs.de/~schoenw/papers/sane-2002.pdf) has been a
huge failure in
the marketplace for the same reasons :-)

I don't disagree that the learning curve for ASN.1 is steeper than
for bits-in-boxes (http://www.ietf.org/rfc/rfc791.txt).  But anyone
who wishes to learn has open source software to look at, as well
as the ability to obtain free copies of ITU specs (no registration
required, no more limit of 3 freebies per year), including X.680
http://www.itu.int/rec/T-REC-X.680-200207-I/en.

Dave

---

From: Martin Rex <[email-masked]>
Date: Fri, 20 Jul 2007 21:12:14 +0200 (MEST)

Kemp, David P. wrote:
> by this "huge" roadblock?

When ASN.1 was less of a problem, then the ambiguity about
the AlgOID within PKCS#1 would not have been earlier detected,
it would not even exist!

Or you may want to look at the pity the PKI guys created with
certificate chains in ASN.1 containers (SOAP/WS-Security).
The PKI guys messed abused PKCS#7 containers and CertificatePairs
until they finally came up with a PKIPath.

The text of the defect report describing PKIPath (not easy to find)
is much better than what was added to the spec document.  But
both do not say a word whether a self-signed RootCA certs is
either prohibited, allowed, expected, required.  TLSv1.0
already recognized this ambiguity in SSLv3 and fixed it long ago.

-Martin

---

From: Leif Johansson <[email-masked]>
Date: Fri, 20 Jul 2007 22:55:00 +0200

Martin Rex wrote:

<snip>
> has the working alternative to use PKI when there is a need for it.
Its important to remember that _both_ PKI and Kerberos
have cross-realm issues. The main difference is that many
PKI implementations allow the users to disregard the lack
of cross-realm trust (eg a pre-configured trust-anchor).

I know this point has been made before on this thread but
I felt it was important enough to emphasize one more time.

The fact that PKI implementations delegate the trust-
decision to the user at session-establishment-time is
arguably a source of many egregious problems.

This is my way of saying that I agree with Nico that any
arguments based on the fact that Kerberos doesn't have
widely deployed cross-realm are just as pointless as
arguments against PKI because there is no common
trust-root: building federations is a hard problem and
not because we haven't gotten the bits right.

I do believe it is a requirement of any solution in this space
that it be able to gracefully handle the case when the gss
handshake fails (for whatever reason) by falling back to
<whatever>. I think the text used to describe this in the
draft can be improved and I will try to help by offering
constructive comments later on.

       Cheers Leif

---

From: Martin Rex <[email-masked]>
Date: Sat, 21 Jul 2007 00:25:01 +0200 (MEST)

> of cross-realm trust (eg a pre-configured trust-anchor).

I beg to differ.  Several PKI toothing problem can be
entirely avoided by applications when the ACLs account
for both, subject AND issuer of a certificate in order
to support authentication from different independent PKIs.

SSL/TLS Client certificates from seperate independet PKIs
is fairly commen, the Web Browsers implement it and
client components in distributed application backends
normally also support it today. 

A Kerberized server that authenticates users from realms with
not trust relationship is somewhere between difficult (MIT Kerberos)
to impossible (Microsoft Kerberos)

At least there appear to be workable approaches to deal with
seperate Kerberos client credentials for independent realms
(probably because it is so difficult to solve the issue on the
 server end).

> not because we haven't gotten the bits right.

I belief that a common trust-root is a stupid and flawed approach.
Of course, the PKI guys desperately need it, because without it
all their policy and name constraints stuff remains the
useless bloat that it is.

The Kerberos cross-organization problem exists because
of the security problems and administrative problems
of a cross-realm trust.

A common trust-root and relying on policy&name constraints
to work puts PKI technology into a similarily miserable position
as Kerberos so it is really stupid to go down this road.

Why do I need a dozen different plastic cards in my wallet?
Can't those issuer not simply agree on a single one?

Well, those issuers want to keep full authority over this card
and not have to ask or negotiate with others what they may and
may not do with a card.

Think of revocation policies.  Right now, each issue can seperately
decide when to renew or revoke their card and for which reasons,
and lots of other policies.  If you only had one card, the rules
would have to be very different (and organization would have
to revoke privileges instead of revoking your credential).

PKI is no silver bullet.  And if you want to make best use of
the existing installed-base technology today, you should probably
forget about common trust-root for online authentication.

> constructive comments later on.

I'm less enthusiastic about the aggressiveness of the fallback.
I hate (hiden) fail-overs, because they're often the root of
mysterious and hard to diagnose problems.

*I* strongly prefer an initial negotation that provides a high
probabilty that a particular method will succeed, and then
exactly one attempt, an error message when it fails and
NO (automatic) fallback.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 20 Jul 2007 23:07:06 -0500

Martin, I definitely agree about islands of trust.

If servers/acceptors/responders should be able to have credentials for
multiple islands of trust[*] then we need to have them tell the
client/initiator what "islands"[*] of authentication, and what
mechanisms, they have credentials for.

It may be too late to work federation negotiation into SPNEGO, but it
makes plenty of sense to me that application protocols should handle
federation and mechanism negotiation rather than pseudo-mechanisms.

Here's our chance to get that right for TLS.

*  "worlds" or "federations" or whatever we should call it; in the
   Liberty, OpenID and other such communities the term used is
   'federation;, so I propose we use that.

Nico
--

---

From: Leif Johansson <[email-masked]>
Date: Sat, 21 Jul 2007 14:22:42 +0200

<snip>
> to support authentication from different independent PKIs.
Then you can just aswell avoid the use of issuers at
all and keep track of (say) certificate fingerprints
for self-signed certs.
> normally also support it today. 
Which was precisely my argument. A set of roots in
a common trust-store effectively makes them all
equivalent in terms of trust and if you think this
doesn't matter I invite you to investigate the pretty
large differences that exist between the CAs that
are all part of (say) the IE default trust-store.
<snip>
> useless bloat that it is.
Good, then we agree on this.
> of the security problems and administrative problems
Which are more or less exactly the same problems that
exist whenever you try to setup any kind of federation. In
fact most cross-realm kerberos trusts are much easier to
setup and maintain than your (not so common) bridge CA.

You are comparing apples and pears in this email by holding
up browser-based PKI as an example of how easy cross-
domain trust is compared to kerberos. In fact there are
extremely few examples of cross-domain trusts (brigde-CAs)
in the PKI world compared to the relatively large number
of cross-realm trusts operational today.
> Can't those issuer not simply agree on a single one?
In fact I sure hope not but that is definitely off topic.
<snip>
> exactly one attempt, an error message when it fails and

Good - this seems like the core of the disagreement.
   
    Cheers Leif

---

From: Chris Newman <[email-masked]>
Date: Wed, 25 Jul 2007 14:24:31 -0500

For my IESG review of draft-ietf-tls-srp-14.txt, I voted to abstain with the 
following comment:

------
This a matter of application software architecture that applies to any
user-based authentication mechanism embedded in TLS that involves
or may involve unspecified server storage of per-user credential
information.

TLS stacks and the APIs to TLS stacks have started to ossify into
operating systems, mobile devices and shipping application software.
Such stacks are absolutely critical to application security, and are
already so complex that they are the cause of a significant number of
software defects and security updates.  I am very concerned about
adding unnecessary complexity to such a critical software component.
There is already a great deal of flux upgrading the cipher suites,
cipher modes and hash functions in these stacks.

Meanwhile, all the software infrastructure in applications surrounding
user identity, server credential repositories for users, and identity
federation is highly complex and in a great deal of flux.  If one looks
at the amount of complexity in the GSSAPI or deployed general
purpose SASL APIs and imagines the complexity of a software stack
including all those APIs blended with a TLS API, I find the prospect
daunting.  Indeed the complexity is sufficiently great that I consider
it bad architecture.

Meanwhile, there's a viable alternative.  If TLS and an authentication
framework such as GSSAPI, EAP or SASL are loosely bound using a
mechanism such as TLS channel bindings (TLS negotiates the security
layer which is subsequently bound to a completely separate user
authentication), then there is a very simple and clean boundary
between the two software stacks, leading to a much more pragmatic
real-world architecture.
------

I have subsequently spoken to other implementers in the applications area who 
integrate TLS and identity stacks into their application server software.  They 
all shared this concern to varying degrees.

This issue clearly also applies to a mechanism that embeds GSS in TLS.  As a 
measure of IETF consensus in support of such a mechanism, I want to see 
evidence there are real-world consumers of this technology sufficient that it 
might deploy.  Specifically, is this likely to be implemented in multiple TLS 
stacks?  Are applications that consume TLS stacks interested in using this 
instead of their present identity APIs and models?

                - Chris Newman
                Applications Area Director

---

From: Larry Zhu <[email-masked]>
Date: Wed, 25 Jul 2007 12:48:21 -0700

For use cases, please review my slides and the meeting minutes for the
TLS working group. I would like to recap the main points below:

Methodology wise the way to deal with complexity is to build abstraction
layers. GSS-API is ideal for encapsulating the described complexity. 

We strongly believe there is a confusing message in IETF. Our security
AD made a presentation in the TLS working group yesterday and the
message is that we want everyone to use TLS for everything. But you
can't use Kerberos in TLS in a secure fashion today. The FXA-TLS fills
in this gap. It is not a conspiracy that the two presentations were
arranged together with my slides extending Tim's slides in that sense.
With FXA-TLS, one can use both certificate based authentication and
Kerberos using one mechanism. No one wants to design their protocols
once with Kerberos and once with TLS, no one want to review their
protocols twice. Experience has clearly shown that requiring two set of
mechanisms (one for Kerb and one for TLS) adds a lot of unnecessary
complexity to what is already too complex. Not to mention the burden to
test two sets of mechanisms. We the IETF really should build a better
building block for future IETF standard protocols and deliver a coherent
strategy/solution. 

Non-IETF protocols that do not have a SASL variant do not even have a
choice, we have to integrate Kerberos into the TLS stack to get Kerberos
to work, not to mention the practical reasons due to firewalls and NAT
traversal.

--larry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, July 25, 2007 12:25 PM
To: [email-masked]; Larry Zhu
Cc: [email-masked]
Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for
integrating

For my IESG review of draft-ietf-tls-srp-14.txt, I voted to abstain with
the 
following comment:

------

I have subsequently spoken to other implementers in the applications
area who 
integrate TLS and identity stacks into their application server
software.  They 
all shared this concern to varying degrees.

This issue clearly also applies to a mechanism that embeds GSS in TLS.
As a 
measure of IETF consensus in support of such a mechanism, I want to see 
evidence there are real-world consumers of this technology sufficient
that it 
might deploy.  Specifically, is this likely to be implemented in
multiple TLS 
stacks?  Are applications that consume TLS stacks interested in using
this 
instead of their present identity APIs and models?

                - Chris Newman

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 26 Jul 2007 17:46:58 +0200

Chris Newman <[email-masked]> writes:

> sufficient that it might deploy.  Specifically, is this likely to be
> implemented in multiple TLS stacks?  Are applications that consume TLS

I believe GSS-API support in TLS, either directly, or through some
generic external-authentication-protocol (which may use channel bindings
to bind the external authentication to the TLS stream) is a good idea.
We all know RFC 2712 is broken. GSSAPI-in-TLS seems like a simple way
fix both RFC 2712 and enable other useful things.

I've been planning to implement Kerberos/GSS-API support in GnuTLS, but
until there is consensus around a specific protocol I can't start.

I think it would be useful if those who are opposed to the past, and
current, GSSAPI-in-TLS proposals describe how they like GSS-API to be
implemented in TLS rather than criticizing the proposals.
Alternatively, if they see any other non-GSS-API way to integrate
Kerberos into TLS, as that appear to be the main use-case for
GSSAPI-in-TLS.

/Simon

---

From: Chris Newman <[email-masked]>
Date: Thu, 26 Jul 2007 11:00:39 -0500

> TLS working group. I would like to recap the main points below:

I will look at them.

> layers. GSS-API is ideal for encapsulating the described complexity.

Abstraction layers can decrease complexity, increase complexity, cause "data 
hiding" (good), and "data losing" (bad).  How abstraction layers are hooked 
together matters a great deal.  There's an abstraction layer between 
applications and TLS.  There's an abstraction layer between applications and 
SASL/GSSAPI.  But what you're proposing shoves GSSAPI behind the TLS 
abstraction, creating a clear case of "data losing" in the abstraction model. 
That would require punching holes through the TLS abstraction layer so the 
application can control both GSSAPI and any back channels GSSAPI uses to talk 
to user authentication repositories or trusted third parties.

> message is that we want everyone to use TLS for everything.

A bit of a confused message is inevitable in a rough consensus organization. 
We're participating as individuals and have different perspectives and 
positions as individuals.  The work to form a rough consensus can be messy. 
But I hear your complaint and will talk to Tim to see if the two of us can 
agree on a more unified message.

For starters, I would agree that when a security services layer is needed in an 
application protocol stack that TLS is likely the right mechanism to provide 
that layer.  I'm not convinced the "SL" portion of "SASL" has any value in 
practice.

> No one wants to design their protocols
> complexity to what is already too complex.

I'd agree that implementers only want to integrate one security services layer. 
But some implementers want their security services layer and identity stack to 
be as cleanly separated as possible so a tight binding between the two is not 
desirable.  TLS only provides certificate-based identity today, a mechanism 
that is very different from other user identity services because it does not 
require the TLS stack to perform a user identity network lookup in the middle 
of the TLS handshake.  Doing that means the TLS stack suddenly has to 
communicate problems talking to the identity lookup service through the TLS 
stack and back to the application.

> Not to mention the burden to

It's more important to build a strategy/solution that can be deployed and 
sustained in the real world with multiple independent interoperable 
implementations.

> to work, not to mention the practical reasons due to firewalls and NAT

An application protocol that needs user-level authentication and fails to 
include an authentication framing mechanism in the protocol is designed 
incorrectly, and the fact some non-IETF protocols have that problem is not a 
reason to add complexity to IETF protocols.  HTTP has such a framing mechanism, 
SSH has one, also SASL, GSSAPI and EAP include protocol abstractions that could 
be used to provide such a mechanism in any other application protocol.

If you try to solve the general application-layer user authentication problem 
in the TLS stack, that adds a bunch of requirements to TLS that it probably 
shouldn't have if there's a desire to keep the stack simple.  An example would 
be error messages suitable for end-user consumption and the language 
negotiation necessary for such messages (SSH does this, for example).

                - Chris

---

From: Leif Johansson <[email-masked]>
Date: Thu, 26 Jul 2007 18:10:24 +0200

> fix both RFC 2712 and enable other useful things.

I fully agree with this.

    Cheers Leif

---

From: Larry Zhu <[email-masked]>
Date: Thu, 26 Jul 2007 09:31:02 -0700

Chris Newman wrote:
> TLS only provides certificate-based identity today, a mechanism 

Reading what you are saying, I suspect you have somewhat misunderstood the proposal and the GSS-API abstraction in general. 
Unfortunately I am on my way home. Thanks for the delay in the airport I am still phyiscally in Chicago. I would suggest for you to talk with Sam Hartman before making further comments on the proposal or GSS-API.

thanks,
--larry
-----Original Message-----
From: Chris Newman [mailto:[email-masked]]
Sent: Thu 7/26/2007 9:00 AM
To: Larry Zhu; [email-masked]
Cc: [email-masked]
Subject: RE: [TLS] the use cases for GSS-based TLS and the plea for integrating

I will look at them.

                - Chris

---

From: Martin Rex <[email-masked]>
Date: Thu, 26 Jul 2007 19:59:42 +0200 (MEST)

There is currently one proposal from Microsoft available as an ID and
I'm planning to come up with an ID in the September/October timeframe
based on the comments that I've made.

The two approaches are in some aspect fundamentally different.
One thing that I particularly dislike about the current ID is its
total silence/ignorance about the necessary changes to add this
to existing implementations and software architectures.

Personally, this impact on the installed base, existing implementations
and existing modularization and software architecture is a significant
concern when comparing the merits of different approaches. YMMV.

 a) draft-ietf-santesson-tls-gssapi:

    - uses GSS-API as a key distribution scheme in order to
      seed a TLS-PSK cihpersuite.  So the (PS)Key is not really
      pre-shared, it is created for and distributed with the
      very same TLS handshake

    # of round-trips: 
       without optimistic gssapi context token
              tls-handshake + gssapi-handshake
       with optimistic gssapi context token (e.g. SPNEGO+optimistic token):
              correct guess: tls-handshake + gssapi-handshake - 1
              wrong   guess: tls-handshake + gssapi-handshake

    advantages:
     * if the gssapi mechanism uses PK-ops-free context establishment
       the the TLS handshake can be performed entirely without PK-ops

    disadvantages:
     * works only with gssapi mechanisms that establish a shared
       session key during security context establishment
       (which essentially means: offer confidentiality message protection)
     * is currently limited to new gssapi mechanisms implementing
       the optional GSS_prf API extension
     * the entire GSS-API security context establishment MUST
       be performed completely inside the TLS handshake
     * requires major re-enginering of the TLS state machine and
       new handshake messages
     * will add at least one round-trip to the TLS-handshake if
       negotiation of gssapi mechanisms should be done and
       _NO_ optimistic gssapi context token scheme is used
     * will mess severly with the protocol stack software architecture
       because the calling application will likely want to
       get access to gssapi extensions/features/attributes
       from the gssapi context and object handles that
       are being using deeply within and owned/managed by TLS during
       the TLS handshake

     * does not provide identity protection for the client
     * does not improve security (weaknesses) over a regular
       gssapi authentication without TLS

 b) my (developing) concept/idea which I have been buiding up during
    my numerous postings last week on the TLS mailing list.

  - uses GSS-API as an additional or alternative authentication method
    for one or both peers on top of a regular TLS ciphersuite and
    after an almost vanilla TLS handshake (using a TLS Hello extension
    for determining availabilty of the protocol extension and selection
    of a common gssapi mechanism), plus three additions to TLS:

     - (preferably) an additional content type at the SSL/TLS record layer
       and API calls/extensions to exchange gssapi context establishment
       tokens following the TLS handshake between the peers

     - the possibility to update (using XOR) the pre-master secret and
       re-generate a new session key of a newly established SSL session
       synchronously (maybe this should use yet another content type
       similar to change_cipher_spec).

     - the possibility to attach an opaque (size-limited) flat-memory
       object to an SSL session (+session cache entry) where
       a seperate software module "TLSplus" above TLS can store those
       gssapi attributes which the application caller might
       want or need on SSL/TLS session resume
       I think it would be good to combine the attaching of
       additional attributes and the update of the pre-master secret
       and keying material

   # of round-trips:
       regular (and this includes mech negotiation):
             tls-handshake + gssapi-handshake
       with TLS-finished piggyback optim.:
             tls-handshake + gssapi-handshake - 1

   the additional TLSplus module will have to implement most of what
   represents gssapi-over-tls, i.e. set up the (simple OID) list of gssapi
   mechanisms for the TLS Hello extension, determine after the
   TLS handshake whether gssapi-over-tls and which mechanism OID
   was negotiated in the Hello extension, perform the GSS-API
   handshake when the TLS handshake is finished (optionally
   using the (clients) TLS finished message(s) as channel bindings,
   update the TLS session crypto keys if the gssapi mechanism can
   provide entropy for a cryptographic binding, collect gssapi
   attributes which the app cares about, serialize them into
   a flat memory object and ask TLS to attach them to the SSL session.

   disadvantages:
     * will incur the (CPU) overhead of a regular TLS handshake in
       addition to the gssapi authentication exchange, which normally
       means a TLS ciphersuite with PK-ops
     * will require one additional round-trip if NO optimization is
       implemented for the client to piggyback the messagee with
       the initiators first gssapi context token onto the
       clients TLS finished message

   advantages:
     * should work with most existing and future TLS cipher suites
     * will work with the entire installed based of gssapi mechs,
       no changes necessary (aside from potential ABI issues).
     * obviates SPNEGO and multi-mech-glues
     * should work with authentication-only gssapi mechanism just fine
       (it doesn't improve the security of the gssapi authentication
        exchange itself, though)
     * should work with SASL instead of GSS-API authentication
       handshakes (at least non-interactive ones)
     * requires only mild modifications of existing TLS implementations
     * should be doable even as a low-impact SSLv3 extension,
       not only TLS v1.x
     * client identity protection because the entire gssapi handshake
       is performed under TLS protection
     * a combination of server-authentication based on SSL server cert
       and client authentication based on gssapi client authentication
       is quite possible, 
     * high orthogonality to the TLS protocol, permitting completely
       independent evolution of gss-api and the TLS protocol stack
     * clear seperation of protocol stacks and abstractions,
       TLS doesn't have to mess with GSS-API, GSS-API doesn't have
       to mess with TLS, TLSplus can be custom tailored to provide
       the amount of gssapi attribute persistence that the application
       needs.

   in order to improve interoperability and to ease the use in heterogeneous
   environments, the TLSplus layer should have a self-signed certificate
   generated in case the customer does not (want to) setup a PKI so
   that non-anonymous TLS ciphersuites can be used.

-Martin

---

From: Chris Newman <[email-masked]>
Date: Thu, 26 Jul 2007 14:46:21 -0500

Larry Zhu wrote on 7/26/07 9:31 -0700:
> Reading what you are saying, I suspect you have somewhat misunderstood the
> proposal and the GSS-API abstraction in general.

That's entirely possible, which is why I wanted to engage in this debate before 
something arrives in front of the IESG and I have to make a decision.  As 
applications area director, I have to invest time to learn how important 
infrastructure proposals are likely to impact Internet applications in general, 
but I have no illusions of being a security expert (rather I'm an application 
expert with a focus on security technology).  This issue is too important for 
me to decide alone, so I'm asking for help from the community to consider these 
issues.

> Unfortunately I am on my way home. Thanks for the delay in the airport I am
> still phyiscally in Chicago.

I wish you a safe flight home.  FYI, I very much appreciate your participation 
in the IETF process.  Technical debate is messy but when the parties involved 
all want the best possible outcome for the Internet, it is worth the effort.

I do want to see Kerberos, TLS and applications such as HTTP, SMTP, IMAP, POP 
combined in a way that is most likely to be widely deployed by multiple vendors.

> I would suggest for you to talk with Sam Hartman

I will certainly do that.  However, I recommend you talk to application 
developers who consume TLS and GSSAPI/SSPI/SASL/EAP APIs to see how they feel 
about these issues.

                - Chris

---

From: Leif Johansson <[email-masked]>
Date: Thu, 26 Jul 2007 22:00:15 +0200

>
> I'd agree that implementers only want to integrate one security
> services layer. But some implementers want their security services
> layer and identity stack to be as cleanly separated as possible so a
> tight binding between the two is not desirable.  TLS only provides
> certificate-based identity today, a mechanism that is very different
> from other user identity services because it does not require the TLS
> stack to perform a user identity network lookup in the middle of the
> TLS handshake.  Doing that means the TLS stack suddenly has to
> communicate problems talking to the identity lookup service through
> the TLS stack and back to the application.
>
Username+password has the same property right? Would you support a
password-based
scheme inside TLS or would you support removing authentication from TLS
entierly?

    Cheers Leif

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 26 Jul 2007 17:45:49 -0400

Umm, is that a trick question?

Symmetric mechanisms (static passwords, OTP, Kerberos, etc) all have
the property of requiring communication with an identity provider
in real-time to authenticate a user (except for pre-placed keys, a
non-scalable technique that is not under consideration for TLS even
though it is supported in IPSec).

Asymmetric (certificate-based) mechanisms can authenticate a user
without communicating with an identity provider and without giving
one party the ability to masquerade as the other.

One certainly would not want to remove asymmetric authentication
from TLS (i.e., it should remain mandatory to implement).  The
discussion concerns whether to add symmetric authentication inside
TLS and if not, how to bind TLS sessions to symmetric authentication
at a layer above TLS.

-----Original Message-----
From: Leif Johansson [mailto:[email-masked]] 
Sent: Thursday, July 26, 2007 4:00 PM
To: Chris Newman
Cc: [email-masked]
Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for
integrating

    Cheers Leif

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 26 Jul 2007 17:55:04 -0400

Chris Newman wrote:
> I will certainly do that.  However, I recommend you talk to
> application developers who consume TLS and GSSAPI/SSPI/SASL/EAP APIs
> to see how they feel about these issues.
>
Chris:

If I am reading you correctly, you would like to see proposals for
example describing how the Windows SSPI and OpenSSL among other TLS
implementations would need to be modified to support the described
functionality.  I think that this is a very important consideration and
I would be happy to propose changes for OpenSSL as I was involved in
adding the support for TLS KRB5 to OpenSSL many years ago.

Jeffrey Altman

---

From: Leif Johansson <[email-masked]>
Date: Fri, 27 Jul 2007 00:21:50 +0200

> Umm, is that a trick question?
Yes.
> TLS and if not, how to bind TLS sessions to symmetric authentication

For the sake clarifying this discussion I'm not sure I understand
what you mean by an symmetric form of authentication. Afaik
there is authentication and other authentication. Both you and
Chris have a point in that there is a difference between X.509
based authentication for TLS and many other mechanism but
so what?

Chris makes the case that errors from (say) network-related
problems which occured out-of-band (wrt TLS) must be
communicated through TLS but so must problems related
to path construction and path validation in the X.509 case,
right?

Having said that I agree fully that a clean stack is a good stack
and I look forward to reading Martins proposal.

    Cheers Leif

---

From: Yoav Nir <[email-masked]>
Date: Thu, 26 Jul 2007 18:14:39 -0500

I disagree with that characterization of certificate-based  
authentication.

You may not need to communicate with an identity provider, but you do  
need to validate the certificate. This necessarily implies checking  
for revocation. Now this could be done using CRL fetching, or OCSP or  
SCVP, but it usually means external communications.

Yes, I know that it's possible to cache CRLs and that the online  
protocols have modes by which the client makes the verification, but  
you can't say that verifying a certificate does not involve external  
communications.

---

From: Chris Newman <[email-masked]>
Date: Fri, 27 Jul 2007 08:50:17 -0500

Leif Johansson wrote on 7/26/07 22:00 +0200:
> Username+password has the same property right?

Yes.

> Would you support a password-based scheme inside TLS or

Most schemes that embed user authentication in the TLS state machine have 
similar issues.  Since GSSAPI is a framework for authentication mechanisms in 
general, it inherits the superset of all authentication-identity-related issues.

> would you support removing authentication from TLS entierly?

No.  Server certificate authentication is useful in practice as part of today's 
interim solution to authentication despite certain dubious qualities.  As 
client certificate authentication is a rarely used feature of TLS, it's 
questionable whether it should have been included in the original design. 
However, given that the mechanism has deployed well in implementations and is 
actually used in some enclaves, it would be far too disruptive to change now. 
Client certificates are also less problematic because the identity service 
lookup can be deferred to the application layer using a mechanism such as SASL 
EXTERNAL or IMAP "* PREAUTH".

                - Chris

---

From: Chris Newman <[email-masked]>
Date: Fri, 27 Jul 2007 09:03:04 -0500

> adding the support for TLS KRB5 to OpenSSL many years ago.

Yes.  And it's not just changes to the TLS stacks, but also to the applications 
that consume the TLS stacks.

I also encourage serious consideration of alternate approaches that involve 
fewer changes to the TLS stack.

                - Chris

---

From: [email-masked]
Date: Sat, 28 Jul 2007 02:07:02 +1200

"Kemp, David P." <[email-masked]> writes:
> Symmetric mechanisms (static passwords, OTP, Kerberos, etc) all have the
> property of requiring communication with an identity provider in real-time to
> authenticate a user (except for pre-placed keys, a non-scalable 
> technique that
> is not under consideration for TLS even though it is supported in IPSec).
>
> Asymmetric (certificate-based) mechanisms can authenticate a user without
> communicating with an identity provider and without giving one party the
> ability to masquerade as the other.
>
> One certainly would not want to remove asymmetric authentication from TLS
> (i.e., it should remain mandatory to implement).

I realise this has the potential to open up a huge can of worms here, but I
can't let this one pass by: "shared keys/passwords/whatever don't scale" is
one of the most persistent myths on computer security.  99.99% of all
authentication is done via pre-shared keys/passwords, including pretty much
arbitrarily large infrastructures like eBay, Amazon, Gmail, any ISP using
RADIUS, and <insert-name-here>.  The ones that we know definitely don't scale
well in comparison are all the others: PKI, Kerberos, yadda yadda yadda, and
in particular the asymmetric-auth ones.

For how many more years do we have to keep flogging the PKI corpse?  If it
worked as intended, the multibillion-dollar phishing industry wouldn't exist.
Why keep it mandatory to implement something that very demonstrably doesn't
work?

Peter.

---

From: Martin Rex <[email-masked]>
Date: Fri, 27 Jul 2007 17:08:18 +0200 (MEST)

> Why keep it mandatory to implement something that very demonstrably doesn't

I beg to differ.

PKI does work.  However, the marketplace has different preferences
for a number of good reasons (IPR issues and operational costs among them).

secret-key or shared-secret authentication comes in all different flavours
and every human being learns the concept behind at a young age and
not necessarily as a software implementation.

public key technology and authentication through public key technology
is different and its complexity appears to be beyond the scope of
many non-technical people.  Where it is used, pushed and advertised,
it is often a part of a MUCH more complex thing called PKI and
cluttered with the ridiculous bloat called X.509 certificate and
the concept of "trusted (certification) authorities".

If Public Key technology was more along the line of the original
models of SSH and PGP, it would likely be used much more often.

-Martin

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 27 Jul 2007 11:18:30 -0400

> models of SSH and PGP, it would likely be used much more often.
You might want to read Alma Whitten's paper "Why Johnny Can't
Encrypt?".  Its a usability study that explains why PGP is not usable
for common folks.

Jeffrey Altman

---

From: [email-masked]
Date: Sat, 28 Jul 2007 03:25:25 +1200

> Encrypt?".  Its a usability study that explains why PGP is not usable

If required I can add a shopping-list of other usability studies looking at
why PKI in general is not usable for common folks.  There's a summary in the
slides at http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf, and a
really long analysis (100-odd pages total, although it covers lots of other
areas as well) at
http://www.cs.auckland.ac.nz/~pgut001/pubs/man_usability.pdf.

(Note that I'm not saying ditch PKI-based auth altogether, keep it if you
want, but don't insist on making it a mandatory option in TLS if it doesn't
work to protect users).

Peter.

---

From: Kyle Hamilton <[email-masked]>
Date: Fri, 27 Jul 2007 08:28:04 -0700

>> is not under consideration for TLS even though it is supported in  

...ummm... the process of creating a key, sending a CSR, and then  
putting the returned certificate and certificate chain in place is a  
key pre-placement mechanism.

Then again, it would also theoretically be possible to generate  
session IDs that you distribute to the clients, and then the clients  
use those pre-generated sessions to share the keys that way.  (That  
path is fraught with so much peril that it's not worth considering  
for a general-purpose implementation, but I can envision a couple of  
specialized environments that it would be useful within.)

>> without

...so OCSP was designed for a purpose that really didn't need to be  
filled.

>> from TLS

I'm inclined to agree.  It is too useful.  However, the issue of  
enforcing X.509/PKIX is... questionable.

> in particular the asymmetric-auth ones.

Why wouldn't the SSH paradigm work here?  You have the public key  
associated with the address you're talking to.  (and if the  
fingerprint popped up when you first connected to it, then a bank  
[for example] would be able to give you the fingerprint to verify  
against when you opened your account.

Personally, I'd like to see the banks that open merchant accounts do  
the certifications of merchant identity.  It would provide for a MUCH  
greater mechanism of knowing who to go after -- because if nothing  
else, the merchant account information could be used in a civil suit  
for garnishment.

> Why keep it mandatory to implement something that very demonstrably  

There are circumstances for which it would work.  It just doesn't  
work very well in the current implementation.  That's the most  
important thing to consider: just because something doesn't work in  
the current implementation doesn't mean it doesn't work period.

To be honest, X.500 (and the entire X.5** suite) is horribly unsuited  
for the purposes for which it was designed -- but LDAP (lightweight  
access to X.500-style directories) has been shown to be useful, which  
means that not all of the work that went into it was wasted.

-Kyle H

---

From: [email-masked]
Date: Sat, 28 Jul 2007 03:34:36 +1200

Kyle Hamilton <[email-masked]> writes:
> Why wouldn't the SSH paradigm work here?

You mean "connect to anything listening on port 22, then hand over your
password in the clear (inside the SSH tunnel)"?  How does it differ from the
current phishing-enabling TLS usage of "connect to anything listening on port
443, then hand over your password in the clear (inside the TLS tunnel)"?

(You're assuming that people check SSH key fingerprints.  Please cite a real-
world usability study supporting this assumption.  NB: That's a booby-trapped
question :-).

Peter.

---

From: Martin Rex <[email-masked]>
Date: Fri, 27 Jul 2007 17:51:37 +0200 (MEST)

> want, but don't insist on making it a mandatory option in TLS if it doesn't

Joe Average also can not set up most things on his Windows PC,
but for the simpler tasks, people can help each other.
With PGP/SSH that has been possible and works fine.

A few years ago I tried to use S/Mime to have someone who had
S/Mime (but not PGP) configured send me stuff in an encrypted
fashion via Email.

I spent an hour until I gave up.  All implementations of S/Mime-capable
MUAs are so horribly broken that even someone with a technical
understanding runs into brick walls everywhere.

None of the MUAs (Outlook&Netscape Navigator) offered me to generate
a self-signed S/Mime capable certificate.
Trying to use existing or newly generated PKI-Credentials (which work
just fine with SSL and GSS-API) proved to be impossible because of the
braindead MUAs (it could be that it wasn't the MUAs fault but a
braindead S/Mime spec that was causing the headaches).

One of the problems with PKI that the technology is often
contorted to push CA business models.  And the other problem
is that it has overloaded "PK credentials" with bloat of the "policy"
category far beyond reason and is causing serious usability,
supportability and interoperability problems for everyone
who starts trying to use the technology for himself.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 27 Jul 2007 18:04:19 +0200 (MEST)

> world usability study supporting this assumption.  NB: That's a booby-trapped

Nope.  SSH automatically verifies the peers public key for your for EVERY
but the first connect.

You may use other out-of-band means to distribute the hosts SSH key
besides answering the "do you confirm the fingerprint" on a first
connect to a host.

IMHO, one should only do the leap-of-faith if oneself has decided
to perform an initial connect, and one should probably not do it
when being asked by someone else to do it (to connect now).

If you use PK-based instead of password-based client authentication
with SSH, then you will at least to "disclose" a password accidentally.

The underlying problem of bootstrapping the authentication process
can not be avoided, independent of whether the authentication uses
asymmetric crypto, symmetric crypto, or is a disclosing authentication.

Using a pre-shared secret (like a password) to bootstrap a stronger
PK-based authentication such as that from SSH is a possibility.
In this scenario, however, the encrypted SSH tunnel is not magic
Pixie dust that can fixed the security problem of that pre-shared
authentication scheme that is being used to bootstrap.

-Martin

---

From: [email-masked]
Date: Sat, 28 Jul 2007 04:11:06 +1200

Martin Rex <[email-masked]> writes:
> SSH automatically verifies the peers public key for your for EVERY
> but the first connect.

And that's exactly what phishing exploits.  Going to a phishing site is always
a first connect.  SSH is no better than TLS when it comes to defending against
phishing.

Peter.

---

From: [email-masked]
Date: Sat, 28 Jul 2007 04:17:33 +1200

> understanding runs into brick walls everywhere.

It's not just S/MIME clients.  The PARC study found that people with *PhDs in
computer science* took, on average, over two hours to set up a cert for their
own use (using paint-by-numbers screenshots as instructions), rated it as the
hardest computer task they'd ever been asked to perform, and had no idea what
they'd done to their computer when they were finished.

PKI people who reviewed the paper were shocked at this, since they assumed
that anyone could do it in a few minutes.

(There's lots more like this in the two refs I gave.  HCISec is a real eye-
opener on the real-world effectiveness of security technology :-).

Peter.

---

From: Martin Rex <[email-masked]>
Date: Fri, 27 Jul 2007 20:02:55 +0200 (MEST)

> SCVP, but it usually means external communications.

Nope, certificate validation does NOT imply certificate revocation
checking.  A CA may want to assert policies to do so, but that
is an entirely different can of worms.

A software architecture that performs certificate revoction checks
by synchronously communicating with third parties over the network
is likely to cause serious problem for the performance and
availability of a service.

I certainly don't mean to imply that certification checking is entirely
useless.  But my idea about a reasonable implementation of
certificate revocation checking precludes synchronous communication
with third parties, and therefore (accessing an) OCSP(-server).
But even then, I would NOT do this within the TLS handshake itself.

-Martin

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 30 Jul 2007 11:15:13 -0400

"Today's interim solution to authentication"???  What do you 
see as the ideal, goal solution to authentication?

Dubious qualities related to factory-default trust lists,
issuance practices, etc can be addressed by changing practices
without changing technologies.  If there were a perfect
(non-dubious) scheme for establishing Kerberos credentials
for all TLS servers on the Internet and configuring clients
to trust only "suitable" servers, that same system could be
implemented more easily and scaleably using certificates.

If the X.500 naming system is considered dubious, certificates
could (and IMO should) be issued using names relevant to the
application (DNS-based, UPNs, issuer/account, etc) rather
than artificially creating ISO Directory names where they are
not needed.

In short, I see SSO being as over-hyped today as PKI
was a decade ago.  Every website that requires users to
create password accounts today could just as easily issue
certificates instead and users would get SSO for free.
An Amazon cert, an eBay cert, banking and brokerage account
certs, IM, discussion forum and online gaming certs, all
unlocked with a single password.  TLS supports that today
(well, almost - it could be easier to manage your whole
wallet of certs on a USB flash drive) but for some reason
(perceptions created by the CA industry?) PKI does not.

So my question at the top is genuine - what characteristics
of today's authentication solutions make them "interim" and
dubious, and what characteristics are required of ideal
Internet-scale authentication solutions?

Dave

-----Original Message-----

> would you support removing authentication from TLS entierly?

No.  Server certificate authentication is useful in practice as part of
today's 
interim solution to authentication despite certain dubious qualities.
As 
client certificate authentication is a rarely used feature of TLS, it's 
questionable whether it should have been included in the original
design. 
However, given that the mechanism has deployed well in implementations
and is 
actually used in some enclaves, it would be far too disruptive to change
now. 
Client certificates are also less problematic because the identity
service 
lookup can be deferred to the application layer using a mechanism such
as SASL 
EXTERNAL or IMAP "* PREAUTH".

                - Chris

---

From: Chris Newman <[email-masked]>
Date: Mon, 30 Jul 2007 16:17:39 -0700

Kemp, David P. wrote on 7/30/07 11:15 -0400:
> ...

This is the wrong forum to discuss authentication technologies in detail.  Some 
of the problems with the presently deployed authentication mechanisms are 
described in draft-hartman-webauth-phishing-05.

                - Chris