Subject: RE: [Emu] Issue with RFC 2716bis key generation

From: Bernard Aboba <[email-masked]>
Date: Thu, 7 Jun 2007 21:21:13 -0700

Most existing RFC 2716 implementations are TLS version agnostic, and so many already support TLS v1.1 and will also automatically support TLS v1.2 when that is implemented in the underlying SSL/TLS code.
 
While RFC 2716bis will obsolete RFC 2716, this doesn't mean that existing EAP-TLS implementations will become obsolete or will change; almost all of them should be compliant with the new spec.  

_______________________________________________
Emu mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/emu

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 11 Jun 2007 14:27:40 -0700

Hao said:

Sorry, I mistyped. I meant to say why not keep the approach used in RFC2716? What's the reason for the change in 2716Bis?
 
[BA]  I would agree that the approach used in RFC 2716 is preferrable.  As to how the change got into RFC 2716bis, it appears to have been introduced in -01; -00 Section 2.5 contained the original text from RFC 2716. 
 
The text inserted into -01 appears to have been taken from the EAP Key Management Framework document, which included similar text in Appendix C in -00, and included an Appendix A on EAP-TLS key management up to version -09 (e.g. see http://www.watersprings.org/pub/id/draft-ietf-eap-keying-09.txt). 
 
As you noted, the formula in RFC 2716bis appears to imply that two PRFs need to be computed (TLS-PRF-64 and TLS-PRF-128) when in fact only one is needed (a single TLS-PRF-128).