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. 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. 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. 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
