Re: [Emu] Using public CA infrastructure for autonomic bootstrapping over EAP.

[Alan DeKok <[e-mail]>]

On Jan 17, 2020, at 5:19 PM, Michael Richardson <[e-mail]> wrote:
> }  c) supplicants do not check DNS names or any other field in the certificates
> }  d) as a result of this lack of verification, supplicants ship with all known
> }     CAs disabled for TLS-based EAP methods"

  For (d), CAs are disabled also because of protocols like EAP-TTLS with embedded PAP.  If the supplicant trusted a root CA, then it would trust any certificate signed by that CA, and expose the users clear-text password to anyone.

  Supplicants now check:

* for a named SSID
* the CA is manually enabled for that SSID
* the server certificate is known (pre-configured or downloaded and cached)

  All of those conditions have to be met before EAP is performed.

> [c] is a problem that we partly want to fix.

  Yes.

> Let's go back to the start with goals and requirements.
> 
> 0) there is nothing broken with manual provisioning of private CAs to be used
>   in Enterprise-WPA (EAP-TLS, etc.) uses of EAP/802.1X.  This can continue
>   as is.  The server certificate needs to have id-kp-serverAuth OID set in
>   order to be trustable by comododity clients as deployed today.
>   There is very little use of additional OIDs, even those some have been defined.
>   Clients do not insist upon them, and *as a result*, it is technically
>   possible to use certificates issued by public CAs here.

  Yes.

  I've omitted BSRKI comments.  I have less to contribute there

> So, it seems that we ought to:
>  a) suggest that EAP-TLS (and EAP-TEAP) clients should include the DN
>     (rfc822Name) of the certificate that they should be talking to.

  I'm not clear on "include".

>  b) we should perhaps have an OID extension in the CA certificate (trust
>     anchor) that says if the CA will use the id-kp-eapOverLAN bit or not.
>     (or other extensions)
>     If so, then the client should insist that the resulting extension be present.
>     Maybe there is another way to do this that would be easier, but this
>     makes sense to me.

  There may be other ways.  Taken to the extreme, each use-case for TLS should have its own OID.

  I don't know that there's a good solution here.

  On a related note, Stefan Winter had a proposal for a standard configuration for EAP:

https://tools.ietf.org/html/draft-winter-opsawg-eap-metadata-02

That would seem to solve all of the provisioning problem.  There are still verification problems.

  I suspect we need to clearly separate the two situations, i.e.:

1) a supplicant magically has the information it needs to authenticate.  What does that information look like?  What's in the certs?

2) a supplicant is unconfigured, how is it possible to get the supplicant to state (1) above?  Is the information available in state (1) helpful for provisioning?

  Alan DeKok.