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

[Alan DeKok <[e-mail]>]

On Nov 20, 2019, at 9:58 AM, Dan Harkins <[e-mail]> wrote:
>>   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.
> 
>   So you asked for imprecise, ambiguous, and unverified information to be put
> in your own certificate for you to use later. Just because something is in an
> RFC doesn't make it right. And appeal to RFC is another form of appeal to
> authority fallacy.

  You asked how it worked.  I pointed you to the RFC.  You now claim I *can't* refer to the RFC, because it's an appeal to authority.

  To recap: appeals to authority are logical fallacies where someone says "I'm right because of this authority".  I'm not saying that.  I'm saying that some people find it *useful*.  I'm pointing to the RFC as evidence that people find it useful.  I'm pointing to the RFC as an explanation of how it works.

  I think some of this back and forth could have been avoided with a careful reading of the RFC.

>   Oh, and what's the point of verifying the chain of your own certificate prior
> to connecting to a network? Do you do OCSP responses to see if your certificate
> has been revoked?

  I had hoped my explanation was unclear.  I guess not.

 The point was that when a client connects, it can check the *server* certificate chain back to the *same* CA which was used to issue the client cert.

  I've never seen a client check it's own certificate chain during authentication.  Such a use-case would be ludicrous, which makes me wonder why you think that's what I was proposing.

>>   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:
> 
>   Yea, and that's why I gave you the list of actions a client takes and asked
> you to point out where in the list this happens. You deleted the list.

  Yes.  Because I gave an explanation of how it works.  I want to be sure that the explanation is understood before going into further details.

  If my explanation makes no sense, then there's no point in me discussing technical details.

>> 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.
> 
>   If the information is ambiguous and unverified why would you use it in a decision
> to accept a certificate or not?

  Well we're going in circles.  I've given explanations.  You reject them whole-sale, and keep asking me for more explanations.

>   I'm not proposing to prevent you from doing anything. I'm asking what's the point
> and why. You didn't really provide one. And good luck getting a public CA to put
> ambiguous and unverifiable information in a certificate for you.

  I've already addressed these points.  Please see my previous messages.

  I think this horse has been beaten to death.  I don't see any point in continuing it, unless there is progress.

  Alan DeKok.