Alan DeKok [mailto:al...@deployingradius.com] writes:
> Glen Zorn wrote: > > If certificate-based TLS authentication is used & the TTLS server is > located > > in the visited network (something that the client can check by > matching the > > identity advertised with a name in the cert), the task is accomplished > (in > > that the problem becomes one of policy, provisioning and > implementation > > rather than protocol design or standardization). > > My understanding was that the TLS tunnel was used for at least two > purposes. One was to perform TLS server validation, as you suggest > above. Another was to provide privacy for authentication credentials. > > The proposal above satisfies the first purpose, but satisfies the > second only when the TTLS & home AAA server are co-located, or in the > same management domain. > > For roaming, the TTLS server is not in the same management domain as > the home AAA server. The proposal above would require that the TTLS > server take the authentication credentials from inside of the TLS > tunnel, and proxy them over normal RADIUS, without the protection of a > TLS tunnel > > This proxying violates the privacy requirements. What privacy requirements are those? > > The only way I could see this method working is if the data inside of > the TLS tunnel was another TLS session. The client could verify that > the outer session matched the local network, and that the inner session > matched the home network. > > Unless I'm missing something, that would require standards action, as > there is no document describing TLS inside of TTLS. EAP-TTLS provides for the transport of EAP inside the TLS tunnel. > There is no > document describing how the client could perform the certificate checks > against the local network information, so that would require standards > action, too. Why? I thought that we were talking about commercial entities here: certainly roaming consortia can specify how they want to take care of internal matters... > > And I'm not sure why this applies only to TTLS. I see this as > applying equally well (or poorly) any other TLS-based EAP method. > > Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
