On Dec 15, 2011 12:27 AM, "Jim Schaad" <[email protected]> wrote: > Normally I would want to have a hard check on the name of the TLS server and matching w/ the certificate. However, just like one could use ABFAB for the purpose of doing user authentication, I think that one can use ABFAB for doing server authentication. That is one could be able to authenticate either an anonymous TLS server, or a TLS server with whom you do not have a trust anchor.
The tls-server-end-point channel binding tour does not require that the server cert be valid to any trust anchor, not does out require pre-sharing of self-signed certs, not does it require any particular names our name forms to appear in the server cert. I.e., server certs can be anonymous and pseudonymous if you like. If you don't want to use server certs at all (self-signed our otherwise) you can always use anon DHE cipher suites and use the tls-unique channel binding type. The tls-server-end-point CB type is easy to support almost universally, whereas tls-unique support is a bit harder to come by (not all TLS stacks support it, sadly). > This would be similar to what you laid out for the use authentication method. That is one would setup the TLS channel, perform the ABFAB authentication with the required channel binding from the TLS session and then throw away the ABFAB work after the ABFAB has completed it authentication process (i.e. the MIC is checked). At this point one should have mutual authentication, and the EAP channel binding should have compared the name the client is looking from (from the TLS certificate or the URL) with that provided by the ABFAB RP. > > Does this seem a reasonable approach in some circumstances? Yes, it does. > Are there circumstances you can see where this would be unreasonable? I can't think of any. Nico --
_______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
