Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Mon, Feb 01, 2021 at 02:52:58PM -0500, Alan DeKok wrote:
> On Feb 1, 2021, at 1:30 PM, Joseph Salowey <[e-mail]> 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