I think the typecode and separate document are orthogonal. There has been discussion of adding enhancements to EAP-TLS, such as channel bindings, which would probably not be backward compatible. In this case we would need a new typecode for this new protocol. PSK or other ciphersuites could be negotiated in TLS under this method type.
Joe > -----Original Message----- > From: Tschofenig, Hannes [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 26, 2006 9:52 AM > To: Charles Clancy; Bernard Aboba > Cc: emu@ietf.org > Subject: AW: [Emu] Tying EAP-TLS method type to specific ciphersuites > > Hi Charles, > > > > -----Ursprüngliche Nachricht----- > > Von: Charles Clancy [mailto:[EMAIL PROTECTED] > > Gesendet: Donnerstag, 26. Oktober 2006 18:45 > > An: Bernard Aboba > > Cc: emu@ietf.org > > Betreff: RE: [Emu] Tying EAP-TLS method type to specific > ciphersuites > > > > So, it sounds like defining an EAP type code for EAP-TLS > with non-PKI > > ciphersuites sounds like the best way to go. Would it be > appropriate > > to have IANA allocate a new EAP type code with 2716bis, or have a > > seperate document discussing EAP-TLS with TLS-PSK ciphersuites? > > A separate document is needed since the security properties > are different. > You need to describe them somewhere. > > Example: > draft-otto-emu-eap-tls-psk-01.txt > > For some other ciphersuites you even need todo more. > Example: A Kerberos based TLS ciphersuite > > Ciao > Hannes > > > > > > -- > > t. charles clancy, ph.d. <> [EMAIL PROTECTED] <> > www.cs.umd.edu/~clancy > > > > > > On Mon, October 23, 2006 9:07 pm, Bernard Aboba wrote: > > >>Should the split be EAP-TLS-v1 (PKI only) vs EAP-TLS-v2 > > (PKI and PSK)? > > >> Or > > >>EAP-TLS-PKI and EAP-TLS-PSK? If we have both legacy issues > > AND footprint > > >>issues, perhaps something like ... > > > > > > So far, we've talked about handling PSK support by creating > > a new EAP > > > method > > > with a distinct name: "EAP-TLS-PSK". That approach > > enables embedded > > > devices to implement only PSK ciphersuites, reducing > > footprint. It also > > > avoids impacting the interoperability and security of > > existing EAP-TLS > > > implementations. > > > > > > Given that EAP-TLS already supports PKI, I'm not sure why a > > distinct EAP > > > method called "EAP-TLS-PKI" would be needed. > > > > > > Creating "versions" of EAP-TLS would potentially confuse > > customers and > > > cause > > > problems with existing test suites and certification > > programs. Witness > > > the > > > confusion that was created by PEAP versioning, where PEAPv0 > > and PEAPv1 did > > > not interoperate. So I'd stay away from versioning if at > > all possible. > > > > > > > > > > > > _______________________________________________ > > > Emu mailing list > > > Emu@ietf.org > > > https://www1.ietf.org/mailman/listinfo/emu > > > > > > > > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www1.ietf.org/mailman/listinfo/emu > > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
