Subject: [TLS] TLS Inner Application Extension

From: Yaron Sheffer <[email-masked]>
Date: Wed, 20 Sep 2006 13:17:57 +0300

Hi,

After some (cursory) research, I only found a few short discussions of draft-funk-tls-inner-application-extension. So here are a few questions, and sorry if this horse has been beat to death already. Sorry for the horse, too.

Has there been discussion of accepting this as a WG draft? Can someone please summarize or point me to the summary for that?

Were there in the past any alternative proposals for integrating EAP into TLS? To clarify, EAP/TTLS and keen don't count. I am talking of using EAP to authenticate a TLS tunnel.

>From an architectural point of view, this proposal is different enough from the use of EAP in IKEv2 to raise a few questions. In IKEv2, only EAP is used between client and gateway. The gateway then uses RADIUS+EAP to the AAA server. Diameter can of course replace RADIUS here. In the current draft, RADIUS is effectively extended into the client. Which means that the client is expected to deal with the whole fun of RADIUS attributes, maybe a dozen or more in 3GPP environments. But anyway, lots and lots of semantics. And if the client can already do EAP (perhaps for IKEv2 or for 802.1X) that's nice but insufficient.

Moreover, the gateway would need to inspect the AVPs, so that keys that are not meant to go on the wire are not forwarded to the client. So the gateway, instead of having reduced complexity because RADIUS AVP functionality is moved to the client, still needs to understand these attributes.

Thanks for any clarifications!

            Yaron

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

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Thu, 21 Sep 2006 16:55:35 +0200

Hi Yaron, 
 
thanks for your interest in the document.
 
RADIUS does not run all the way to the TLS client with the mentioned
proposal. A subset of the draft authors had the idea that it would be
good to reuse the RADIUS attribute format and to keep the draft generic
to support more than just EAP (including SAML etc.). 
 
I personally feel more confident with a restricted scope of only using
EAP. 
The feedback we received support this idea. 
 
Ciao
Hannes
 
PS: There is an open source implementation of the draft available. 

________________________________

	Von: Yaron Sheffer [mailto:[email-masked]] 
	Gesendet: Mittwoch, 20. September 2006 06:18
	An: [email-masked]
	Betreff: [TLS] TLS Inner Application Extension

	Hi,

	After some (cursory) research, I only found a few short
discussions of draft-funk-tls-inner-application-extension. So here are a
few questions, and sorry if this horse has been beat to death already.
Sorry for the horse, too.

	Has there been discussion of accepting this as a WG draft? Can
someone please summarize or point me to the summary for that?

	Were there in the past any alternative proposals for integrating
EAP into TLS? To clarify, EAP/TTLS and keen don't count. I am talking of
using EAP to authenticate a TLS tunnel.

	From an architectural point of view, this proposal is different
enough from the use of EAP in IKEv2 to raise a few questions. In IKEv2,
only EAP is used between client and gateway. The gateway then uses
RADIUS+EAP to the AAA server. Diameter can of course replace RADIUS
here. In the current draft, RADIUS is effectively extended into the
client. Which means that the client is expected to deal with the whole
fun of RADIUS attributes, maybe a dozen or more in 3GPP environments.
But anyway, lots and lots of semantics. And if the client can already do
EAP (perhaps for IKEv2 or for 802.1X) that's nice but insufficient.

	Moreover, the gateway would need to inspect the AVPs, so that
keys that are not meant to go on the wire are not forwarded to the
client. So the gateway, instead of having reduced complexity because
RADIUS AVP functionality is moved to the client, still needs to
understand these attributes.

	            Yaron