Hi Joe, Let me separate this into different topics for clarity.
> > [Joe] EAP negotiation happens early before TLS negotiation. If a peer > or server negotiate a particular EAP method they may actually not > actually be able to complete this because TLS negotiation arrives upon > an result that is not satisfactory. Restricting EAP-TLS to certificate > based ciphers does not solve this problem, but it helps. In an > enhanced EAP-TLS the initial message from the server could indicate > the supported ciphers giving the chance for a client to NAK. > > 1. TLS negotiations in EAP: --------------------------- I guess in a way, this is trying to perform some rudimentary TLS ciphersuite negotiation at the EAP level. For regular TLS operation, I can see clients connecting to just about any server. However, for EAP, typically, the peer has an "association" with a certain server that at least knows a list of methods that the peer or peers that have an association with it support - that's how it knows what method to start in the EAP Request following the EAP Response Identity. EAP doesn't quite provide method negotiation per se - by using EAP NAKs, we can make it soemthing of a negotiation. If the EAP server has no clue about the peer attempting to authenticate or if the server does not have a reasonable number of methods that it supports, the EAP exchange could potentially go on with several NAKs and that wouldn't be good. By that same principle, it seems like whatever would indicate to the server that the client can do EAP-TLS-PSK (when that is a separate method) should also indicate that the client can do EAP-TLS with PSK ciphersuites. 2. TLS vs. EAP-TLS Implementations: ------------------------------------ I'm a bit concerned about supporting a subset of TLS in EAP-TLS. For instance, consider a server that has a regular TLS implementation and typically supports the PSK ciphersuites. For a client that talks TLS directly to it, it allows negotiation of any ciphersuites, including the PSK ones. However, for a client that talks TLS via EAP, it needs to make sure that only a subset of the TLS ciphersuites are provided as an option. So, in this case, EAP is not just a carrier for the TLS authentication method - EAP then only supports one "profile" of TLS, so to say. If we think that optimizations can be supported by having a separate EAP-TLS-PSK method, we may still want to do that, but, precluding the use of certain TLS ciphersuites with EAP-TLS seems restrictive. 3. Client authentication in EAP-TLS: ------------------------------------ I also notice that client authentication is optional as written in draft-simon-emu-rfc2716bis. When would peer authentication ever be optional for EAP operation? I realize this is something that came from TLS, since client authentication is truly optional in TLS (and that makes sense in certain uses of TLS). However, in the context of EAP, that seems strange. If we were to follow the same notions about optional TLS elements as in RFC4346 (or 4346bis), the server certificate would also then be optional. Vidya _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
