On Mon, Feb 01, 2021 at 02:52:58PM -0500, Alan DeKok wrote: > 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.
I had missed that part of 5216 before. While you're mostly stuck doing that sort of "all names in the cert are deemed valid" for the TLS client certificate, since the server just asks for *some* cert and has to handle what it gets back, that's not the normal pattern for authenticating the server. Consider, e.g., the RFC 6125 procedure, which takes as input to validation the name that the TLS client was attempting to initiate communication towards. Depending on the application protocol that might be a DNS-ID or URI-ID or whatever, but there's still a clear "I initiated communication towards this specific named entity; can the server prove that it is that entity" which is very much not "they proved possession of the private key; all names are verified". Even for the same server and same certificate, the answer can be different for different names in the certificate. (I am about to clear a DISCUSS position on draft-ietf-quic-http for just this topic; the historical HTTP semantics are in line with RFC 6125. It is perhaps not strictly required that the EAP usage do the same, but it is surprising, at least.) > > 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. I think that you get better security properties if you include the entire certificates, but even just identities are better than nothing (provided there is a clear unique ordering/encoding, as you note). -Ben _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
