> -----Original Message----- > From: Narayanan, Vidya [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 06, 2007 11:51 AM > To: Bernard Aboba; [email protected] > Subject: RE: [Emu] RFC4279 support in draft-simon-emu-rfc2716bis? > > Hi Bernard, > Thanks much for the response. If we go down this path, are we > then saying that for every new ciphersuite that may be added > to TLS, a separate EAP method would need to be designed to > support that in EAP? > Also, how is this different from TLS implementations having > to support the newer ciphersuites? >
[Joe] We have a charter item for enhanced TLS which could support other types of ciphersuites along with other features. > I can understand the mandatory cert requirement in RFC2716, > since at that point of time, TLS did not have the PSK > ciphersuites. But, now that we are revising it, does it not > make sense to support all the ciphersuites supported in TLS? > > Also, could you please elaborate on the multiple negotiation problem? > Looking at the message flows in section 2.1 in > draft-otto-emu-eap-tls-psk-02 and section 2.1.1 in > draft-simon-emu-rfc2716bis-08, except for the certs portion, > everything else looks the same. > [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. > Thanks, > Vidya > > > -----Original Message----- > > From: Bernard Aboba [mailto:[EMAIL PROTECTED] > > Sent: Monday, March 05, 2007 11:29 PM > > To: Narayanan, Vidya; [email protected] > > Subject: RE: [Emu] RFC4279 support in draft-simon-emu-rfc2716bis? > > > > According to RFC 2716, a compliant EAP-TLS implementation > must support > > certificates. Since the resources required to support > certificates is > > much larger than the resources required for TLS-PSK, a > combined method > > would not be optimal for use within an embedded environment. There > > would also be substantial costs to adding support for additional > > authentication methods to EAP-TLS. For example, EAP-TLS > certification > > and testing programs have been developed which focus solely on > > certificate ciphersuites; rewriting those test suites would > be costly. > > > > By developing EAP-TLS-PSK as a separate EAP method an > implementation > > can solely implement TLS-PSK while remaining compliant. > This permits > > EAP TLS-PSK implementations to be optimized for embedded > environments. > > As a side benefit, this approach also eliminates multiple levels of > > negotiation, which had been raised as a potential problem. > > > > > > > > _______________________________________________ > Emu mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
