> -----Original Message----- > From: Narayanan, Vidya [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 07, 2007 1:28 PM > To: Joseph Salowey (jsalowey); Bernard Aboba; [email protected] > Subject: RE: [Emu] RFC4279 support in draft-simon-emu-rfc2716bis? > > 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.
[Joe] EAP provides negotiation and it is even used in real networks. I agree it is not ideal, but it is what we have. >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. > [Joe] I'm not sure what principle you are referring to so I don't see how it can be applied to this problem. The client tells the server it supports method x by responding to the server's challenge for method x. The ciphersuite is not available in the initial challenge. One could modify EAP-TLS such ciphersuites are advertised in the EAP-TLS start, but this would interfere with backwards capability, hence there is a charter item for enhanced TLS. > 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. > [Joe] Most TLS libraries support "profiling" of TLS ciphersuites for different applications and deployments. > 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. > [Joe] It is not necessary to put restrictions on an enhanced EAP-TLS since it does not have the same backwards compatible expectations as EAP-TLS. > 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. > [Joe] There are EAP use cases where peer authentication is not required but server authentication is. There are also instances where anonymous ciphersuites are used, but the trade off in security is much more severe with anonymous ciphersuites. > Vidya > _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
