On Feb 1, 2021, at 1:30 PM, Joseph Salowey <j...@salowey.net> wrote: > [Joe] This could also address the early export of keys before the peer is > authenticated. RFC 5216 provides a canonical way to create these IDs, but I'm > not sure anyone follows it today
FreeRADIUS does not officially expose Peer-Id or Server-Id. But the certificate subjectAltNames are available via the policy engine. The greater difficulty is *which* Id to use. RFC 5216 Section 5.2 says: It is possible for more than one subjectAltName field to be present in a peer or server certificate in addition to an empty or non-empty subject distinguished name. EAP-TLS implementations supporting export of the Peer-Id and Server-Id SHOULD export all the subjectAltName fields within Peer-Ids or Server-Ids, and SHOULD also export a non-empty subject distinguished name field within the Peer- Ids or Server-Ids. All of the exported Peer-Ids and Server-Ids are considered valid. > and it may be difficult to implement in practice due to ordering. It might > be simpler to just specify that the end entity peer and client certificates > are used in the key derivation. Most libraries provide APIs to get the raw > certs. Yes. We expose the certs to the policy engine, along with various fields. Having the TLS exporter use more data should just be about updating some code. Alan DeKok. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
