Subject: [abfab] Use of anonymous TLS w/ ABFAB

From: "Jim Schaad" <[email-masked]>
Date: Wed, 14 Dec 2011 21:26:43 -0800

Nico,

This goes out of tracker issue #29.

One of the things that I am looking at for the Plasma work is the set of items which would be required for doing TLS and ABFAB together and what things can be eased.

Normally I would want to have a hard check on the name of the TLS server and matching w/ the certificate.  However, just like one could use ABFAB for the purpose of doing user authentication, I think that one can use ABFAB for doing server authentication.  That is one could be able to authenticate either an anonymous TLS server, or a TLS server with whom you do not have a trust anchor.

This would be similar to what you laid out for the use authentication method.  That is one would setup the TLS channel, perform the ABFAB authentication with the required channel binding from the TLS session and then throw away the ABFAB work after the ABFAB has completed it authentication process (i.e. the MIC is checked).  At this point one should have mutual authentication, and the EAP channel binding should have compared the name the client is looking from (from the TLS certificate or the URL) with that provided by the ABFAB RP.

Does this seem a reasonable approach in some circumstances?  Are there circumstances you can see where this would be unreasonable?

Jim

---

From: Nico Williams <[email-masked]>
Date: Thu, 15 Dec 2011 04:53:11 -0600

On Dec 15, 2011 12:27 AM, "Jim Schaad" <[email-masked]> wrote:
> Normally I would want to have a hard check on the name of the TLS server
and matching w/ the certificate.  However, just like one could use ABFAB
for the purpose of doing user authentication, I think that one can use
ABFAB for doing server authentication.  That is one could be able to
authenticate either an anonymous TLS server, or a TLS server with whom you
do not have a trust anchor.

The tls-server-end-point channel binding tour does not require that the
server cert be valid to any trust anchor, not does out require pre-sharing
of self-signed certs, not does it require any particular names our name
forms to appear in the server cert.  I.e., server certs can be anonymous
and pseudonymous if you like.

If you don't want to use server certs at all (self-signed our otherwise)
you can always use anon DHE cipher suites and use the tls-unique channel
binding type.

The tls-server-end-point CB type is easy to support almost universally,
whereas tls-unique support is a bit harder to come by (not all TLS stacks
support it, sadly).

> This would be similar to what you laid out for the use authentication
method.  That is one would setup the TLS channel, perform the ABFAB
authentication with the required channel binding from the TLS session and
then throw away the ABFAB work after the ABFAB has completed it
authentication process (i.e. the MIC is checked).  At this point one should
have mutual authentication, and the EAP channel binding should have
compared the name the client is looking from (from the TLS certificate or
the URL) with that provided by the ABFAB RP.
>
> Does this seem a reasonable approach in some circumstances?

Yes, it does.

>  Are there circumstances you can see where this would be unreasonable?

I can't think of any.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 15 Dec 2011 06:26:06 -0500

>>>>> "Jim" == Jim Schaad <[email-masked]> writes:

    Jim> Does this seem a reasonable approach in some circumstances?
    Jim> Are there circumstances you can see where this would be
    Jim> unreasonable?

So, technically it's a lot easier to do this with certs for which you
don't share a trust anchor than for TLS with anonymous DH ciphers.
Mostly implementation issues at fault; end-point channel bindings are
more widely implemented than unique for TLS.

The general model is sound and is one Nico and I have been working on
for years.

It means you're really trusting EAP channel binding. It means whoever
runs your ABFAB actually needs to do a quality job of validating
servers.  However they may have a smaller problem than a global PKI to
solve so it may be easir for them to do that.

It's unreasonable if you want to validate the server before disclosing
what abfab realm you want to talk to.

It's unreasonable if your implementation doesn't let you fiddle with TLS
validation and defer it until after CB so you can suppress if CB
succeeeds.

It may be unreasonable if the client machine needs to trust the server
independently of the user at the client machine. Often the client
machine will not be able to establish trust in the ABFAB architecture.

--Sam

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Thu, 15 Dec 2011 12:37:04 +0100

> solve so it may be easir for them to do that.

Would not this be an interesting use case for the trust router?

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:      +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Sam Hartman <[email-masked]>
Date: Thu, 15 Dec 2011 08:57:00 -0500

>>>>> "DIEGO" == DIEGO LOPEZ GARCIA <[email-masked]> writes:

    >> The general model is sound and is one Nico and I have been
    >> working on for years.
    >> 
    >> It means you're really trusting EAP channel binding. It means
    >> whoever runs your ABFAB actually needs to do a quality job of
    >> validating servers.  However they may have a smaller problem than
    >> a global PKI to solve so it may be easir for them to do that.

    DIEGO> Would not this be an interesting use case for the trust
    DIEGO> router?

Yes!  The trust router is great at allowing you to organize a community
that is going to be focused enough to give better trust and security to
its members than a general PKI.  We're beginning to see that the most
interesting value in our architecture of the trust router is exactly
that it lets you have a bunch of these little communities running around
and manage them effectively and focus the authentication context.