Subject: [TLS] new TLS extension: "Inner Application"

From: Paul Funk <[email-masked]>
Date: Mon, 28 Feb 2005 00:35:25 -0500

I'd like to solicit comment on the following draft:

http://www.ietf.org/internet-drafts/draft-funk-tls-inner-application-extension-01.txt

This draft defines a new TLS extension that allows authentication or other
information exchange to occur under the protection of the TLS handshake and
prior to exchange of upper-layer data. This permits a TLS session to be 
secured
by EAP authentication in addition to TLS authentication, allows either 
party to
interrogate the "endpoint integrity" status of the other, etc., prior to 
proceeding
with data exchange. It is also intended to serve as a means to perform layer 3
authentication and negotiation of security parameters for additional 
communication
channels. Finally, it serves as the basis for the EAP-TTLS authentication 
protocol.

The authors are hopeful that this draft will be of interest to members of 
the working
group. Our intention is to take this to proposed standard RFC status.

Thank you very much,

Paul

Paul Funk
Funk Software, Inc.
617 497-6339
[email-masked]

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

---

From: David Hopwood <[email-masked]>
Date: Mon, 28 Feb 2005 06:21:01 +0000

Paul Funk wrote:
> secured by EAP authentication in addition to TLS authentication, allows either 
> party to interrogate the "endpoint integrity" status of the other, etc., prior
> to proceeding with data exchange. It is also intended to serve as a means to
> perform layer 3 authentication and negotiation of security parameters for
> additional communication channels. Finally, it serves as the basis for the
> EAP-TTLS authentication protocol.

An obvious alternative is to strictly layer the authentication protocol
over TLS, e.g. "application / EAP / TLS / TCP / IP". That appears to me
to be simpler, so what is the technical motivation for using new TLS
record ContentTypes instead?

-- 
David Hopwood <[email-masked]>

---

From: Paul Funk <[email-masked]>
Date: Mon, 28 Feb 2005 01:44:52 -0500

At 06:21 AM 2/28/2005 +0000, David Hopwood wrote:
>>secured by EAP authentication in addition to TLS authentication, allows 
>>either party to interrogate the "endpoint integrity" status of the other, 
>>etc., prior

The purpose is to separate the EAP authentication from the upper-layer
data (e.g. HTTP). So the TLS session has three phases: TLS handshake,
Inner Application (e.g. EAP authentication using new record type), then
HTTP traffic. In effect, the TLS handshake plus the exchange under the
new record type becomes an "extended handshake", allowing the data
session to proceed only after both TLS handshake and EAP authentication.

The intention is to provide a 3-phase model for HTTP or other TCP sessions,
and provide a 2-phase model (TLS handshake, then authentication under new
record type, but omitting any further data exchange) if just authentication is
required. The 2-phase model would look like what you are suggesting.

Paul Funk
Funk Software, Inc.
617 497-6339
[email-masked]

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 28 Feb 2005 09:20:23 +0100

On Monday 28 February 2005 07:44, Paul Funk wrote:

> data (e.g. HTTP). 
You can separate that data by encapsulating the other protocol within the
application data of tls. Ie you tag the data you want to distinguish.

As I understood from the document the unique offer of TLS/IA comparing
to TLS-PSK and TLS-SRP, is that it allows for client password based
authentication using a challenge-responce protocol. Although it doesn't
look a bad idea, in this draft, it is heavily separated from the TLS protocol
--not part of the handshake, uses different record types, this AVP format etc, 
and that makes it look like an ugly plugin. 
Other than that the idea of exporting the TLS secret to other protocols does 
not really sound nice. 

Although I like the idea of adding challenge and responce protocols being
added, i don't like the way. It is only EAP-related, and it can hardly
benefit any other applications.

-- 
Nikos Mavrogiannopoulos

---

From: Paul Funk <[email-masked]>
Date: Mon, 28 Feb 2005 19:40:32 -0500

>application data of tls. Ie you tag the data you want to distinguish.

Well, a new record type is a good way to do the tagging. The idea is that
the TLS data endpoints shouldn't have to distinguish authentication data
from their own data. So the TLS engine handles TLS handshake and
authentication via new record type, and only emits the data to the upper layer
application that it is interested in. This would allow, for example, a bump in
the wire to perform the TLS handshake and inner application protocols, and
expose a simple unencrypted data stream to a backend server.

>Other than that the idea of exporting the TLS secret to other protocols does

One of the intentions of the protocol is independence of the inner application
from the TLS handshake. This means that the confidence in the TLS handshake
itself need not be re-examined.

Another intention is that arbitrary information exchange be possible within
the tunnel created by the TLS handshake. TLS itself is very regimented,
and for good reason. So, yes, the data within the new record type is very
un-TLS, and it occurs after the base TLS security has been established
via the regimented handshake. Once the handshake is complete, a more
free-form exchange is possible.

The reason that the Diameter AVP format was chosen is for compatibility
with the RADIUS/Diameter infrastructure, with which much of the anticipated
inner application traffic will have to interoperate.

>benefit any other applications.

It's more than just EAP-related. Any sequence of Diameter AVPs may be
used; EAP is just one example. Plus, Diameter provides for vendor extensions.
So it is possible to define any inner application you like; authentication 
is one,
key agreement for an additional data channel might be another, endpoint
integrity a third, etc.

Paul Funk
Funk Software, Inc.
617 497-6339
[email-masked]