[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

AW: [TLS] TLS Inner Application Extension

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:yaronf@xxxxxxxxxxxxxx]
Gesendet: Mittwoch, 20. September 2006 06:18
An: tls@xxxxxxxxxxxxxx
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.

 

Thanks for any clarifications!

 

            Yaron

_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls