On Feb 7, 2021, at 9:27 PM, Joseph Salowey <[email protected]> wrote: > > 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)
What format is used for then peer certificate? The EAP-TLS application doesn't necessarily have access to the "on the wire" format of the certificate. It may only have access to a decoded / high-layer representation of the certificate. For that reason, I would prefer to avoid using the certificate in any key derivation. The peer ID may be more, if we just a field in a certificate (e.g. subjetAltName). It is simple, and can be exported as an opaque blob. > 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. I would prefer to define a consistent key derivation. The more if / then / else cases are defined, the more opportunity for error. TBH, just leaving it as draft-13 or -14 is fine. The main important change for me is to mandate the use of TLS alert as a secure altReject indicator, and a delayed close_notify / commitment message (after the client cert) was a secured altAccept indicator. Alan DeKok. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
