I'd like to get feedback from the working group on the EAP-TLS 1.3 key derivation. Does this improve the security of the system? Are there any implementation barriers?
The key derivation for TLS 1.3 uses the key exporters defined for TLS 1.3. A few reviews have pointed out that the exporter master secret for TLS exporters includes server identity information, but does not include information about the peer/client identity. Both Martin and Ben proposed adding the peer identity into the context parameter for the TLS exporter key derivation. This binds the peer identity into the key derivation for EAP-TLS keys that are used in lower layer protocols. This explicit binding strengthens the resulting authentication implied by the key and should make formal analysis of the system easier. For example, if the EAP-TLS server is requesting a certificate from the peer then the key derivation would look something like: Key = TLS-Exporter(label, peerID/peer certificate, 64) Where the label is the label defined for the key and the peer ID is identity information for the peer. Since the peer ID in EAP-TLS has some potential ordering issues, it may be better to use the end entity certificate of the peer as the peerID. In the case where the peer is not asked for a certificate then the derivation would not include the peerID. The TLS resumption key derivation is derived using both the peer and server identity from the original exchange so adding the peerID into the EAP-TLS key derivation in the resumption is not necessary. Cheers, Joe
_______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
