Re: [Emu] Idea: New X509 Extension for securing EAP-TLS

[Alan DeKok <[e-mail]>]

On Nov 20, 2019, at 5:23 AM, Dan Harkins <[e-mail]> wrote:
>>   See RFC 4334 and its discussion of SSIDs.
> 
>   Is this _my_ certificate that has this attribute in it or is it in a certificate I receive?

 The Introduction of RFC 4334 says:

   Automated selection of client certificates for use with PPP and IEEE
   802.1X is highly desirable.

  Which seems clear.

> If it's my certificate then what is the point of putting it in my certificate?

   See the text in the document, which explains this in detail.

> I am asking for
> ambiguous data to be certified and placed in my certificate for my own use? If this attribute
> is in a certificate I receive then what does it mean to "select the correct certificate for
> authentication in a particular WLAN"?

  The text explains this in detail.  I'll summarize.

  The use-case of the document is that an individual is issued a client certificate.  That certificate contains an OID about the expected use-case (EAPoL), and also a list of SSIDs used to perform EAP.  When a client system is confronted with a set of SSIDs, it can cross-correlate the SSIDs it sees with SSIDs in it's certificate store.  The client system can then select an appropriate authentication method (EAP versus WPA-PSK), and also a client certificate to use.  Since it's selected a client cert, it can also verify the certificate chain back to the root.

  I would *also* argue that this information can be placed in a server certificate, for situations when client certificates are not being used.  As discussed extensively previously on this list, a client can connect to an SSID, obtain the server cert, and then verify:

a) the server cert is intended for EAPoL (and is not just a cert taken from a web server)
b) the SSIDs in the cert match the SSID used to authenticate
c) the NAIRealm in the cert matches a user identifier stored in the client system

  In which case the client has *more* information than what is available to it today, and can thus make better decisions about whether or not to accept the cert.

>   This attribute seems useless to me and its ambiguity and therefore unverifiability is a
> large reason why.

  I would suggest not using it for your own purposes then.  I would also suggest allowing *others* to use it, if they find it useful.

  Alan DeKok.