FreeRADIUS EAP-TLS Auth. Issues

[Gerald Vogt]

On 24.01.24 18:19, Alan DeKok wrote:
> On Jan 24, 2024, at 11:33 AM, Gerald Vogt <vogt at spamcop.net> wrote:
>> So I have made suggestions on how to improve this, how to have clear and distinguished configuration parameters for the configuration of the tls server and the tls client verification.
> 
>    I'll have to disagree.  You were asked repeatedly in the GitHub issue to explain.  The responses were not actionable.

Oh goodness. You are persistent. I don't know how else to explain how 
something is confusing or misleading expect describing the confusion 
that there is.

>> I have pointed out how the comments for the configuration parameter are confusing or misleading.
> 
>    What is confusing?  What is misleading?  I've asked you for details.  In response, I get long descriptions which aren't actionable.

I have explained several points in my second message in the ticket.

                 #  If ca_file (below) is not used, then the
                 #  certificate_file below SHOULD also include all of
                 #  the intermediate CA certificates used to sign the
                 #  server certificate, but NOT the root CA.

O.K. If ca_file is not used, I put the server cert following by the 
issuing CAs in order except the root ca into certificate_file.

                 #  When using "ca_file" or "ca_dir", the
                 #  "certificate_file" should contain only
                 #  "server.pem".  And then you may (or may not) need
                 #  to set "auto_chain", depending on your version of
                 #  OpenSSL.

O.K. In the other case the ca_file or ca_dir are used (i.e. defined) 
certificate_file should only contain the server certificate. It is a 
"should" but the average user will hopefully the developers advice.

                 #  Trusted Root CA list
                 #
                 #  This file can contain multiple CA certificates.
                 #  ALL of the CA's in this list will be trusted to
                 #  issue client certificates for authentication.

So now it starts: I want to use client certificates. Thus, if I do I can 
define ca_file.

Now if I do that, it means I am using "ca_file", i.e. the 
certificate_file should contain only the server certificate, not the 
issuing CAs.

This also means, that "ALL of the CAs in this list will be trusted to 
issue client certificates".

This means, if my client certs and server certs use different CAs I 
cannot distinguish them, e.g. my server cert could be used for client 
certificate authentication (if it the server has the attributes set). 
Something I don't want.

So what now? Do I deviate from the "should contain only server.pem"? Or 
it is wrong to use "ca_file"?

Logical decisions based on the information given lead me here. Now I 
have to track back to find a descision which gets me what I want.

Second confusion: it says "Trusted Root CA list". It says "Root CA". 
That does not include intermediates CAs. But without the intermediates, 
you cannot create a chain from the (server cert only) certificate_file 
nor can you verify client certs issued by intermediates.

So what now? So is this really only a root ca list and the intermediates 
must go somewhere else? Or is it simply a trusted ca list?

                 #  In general, you should use self-signed
                 #  certificates for 802.1x (EAP) authentication.
                 #  In that case, this CA file should contain
                 #  *one* CA certificate.

O.K. Again, if I follow that advice, use self-signed certificates for 
EAP, thus put only one CA cert into the ca_file, it also requires my 
server cert to be issued by that CA, when I follow the instructions before.

                 #
                 #  Directory where multiple CAs are stored.  Both
                 #  "ca_file" and "ca_path" can be used at the same time.
                 #

After all the explanations before telling me what to do when, this now 
only tells me ca_path is a list of CAs.

This is unclear: where is this used? Does the ca_file comment applies 
and this is a place for (root?) CAs used for client certificates?

Or is it just the same like ca_file but with certs stored in a directory?

Above first it says "ca_file (below) is not used" and later it says 
"When using "ca_file" or "ca_dir",". Is this distinction intentionally 
or is it simply an error of omission?

I am only reading what's in the comments and am trying to figure out how 
to correctly configure it to get a working tls server with the chain 
attached and allowing for client certificates.

That's what I wrote in the issue, which you mostly ignore in your response.

In the end, I have configured certificate_file with the server cert 
followed by the issuing ca chain and put all ca root and intermediate ca 
certs for client certificates into ca_file, so explicitly not doing what 
I "should" do.

The texts in the comments is somewhat like a logical riddle to solve, 
you'll  have to try all possible combinations until you'll find one 
which doesn't end in a contradiction.

At the same time, because it's unclear to me what each parameter really 
does and where it's used, it's difficult to give a suggestion how it 
would be better.

I do not know how to describe the issue, except "long descriptions". I 
could translate the text into logical expression though the "should" 
makes it hard.

>> If it's so easy and so clear, why don't you write it simply into the documentation? If I point out discrepancies or what's unclear but you shut it down.
> 
>    I didn't say it was easy and clear.  I said that you need to describe exactly what's wrong it the existing documentation.  In response, I got nothing actionable.

Well, if the text is unclear and I don't know what the text really 
should be because it's unclear how everything is used exactly, I cannot 
give you a better text nor anything else "actionable". I can only point 
out, describe, explain the confusion.

>    In case it wasn't clear, the documentation is as clear as we can make it.  We've put literally decades into understanding every possible situation for FreeRADIUS, including TLS.  Yet despite that, OpenSSL and TLS are still magic.  It's still not clear to us why some things work and some don't.

Well, that's bad. I cannot tell what you have found which "works" or 
"don't", but generally I don't see the "magic" you have found, at least 
when it's related to the certificate handling.

The TLS server cert and it's chain is, well, static.

For the client certificate you have to verify the client certificate 
which usually can be simulated with "openssl verify" using the right 
parameter set of -{no,}CA{file,path,store} -{un,}trusted.

At least for a lot of web servers running httpd or nginx, or postfix 
mail servers I never found myself in a situation that was unclear or was 
magically not working the way I expected it and how it was documented...

>    But you don't accept that.  You're refusing to do the work to figure it out, while still demanding that we do that work.  And anything you do figure out is secret, and you're not going to share.

I am trying to figure out what "magic" you have implemented with those 
configuration parameters, but it's difficult and you are not really 
helping to clear that up. So I can only guess... So basically, I could 
repeat those exact three sentences, because that's how it seem to me.

>    That attitude is highly inappropriate.

I could repeat that sentence, too. I try to figure it out, how it really 
works, and just give me an attitude...

>> Also, assuming that people know that the option "ca_dir" is used as openssl "CApath", thus requires the hashes, well... "We do not include ... all of OpenSSL documentation". Let the dumb user figure it out themselves. Why should the docs indicate that ca_dir is CApath and requires c_rehash (did FR 2.x mentioned c_rehash?)
> 
>    If only there was some kind of github thing where you could explanations to the documentation, and have them included in the server.

And that's what you like to do, too, ironically ignoring lots of 
explanations and than picking on one single point. If I suggest 
something I'd rather do that in the context of the whole process and not 
just a breadcrumb only because that's what you understood.

> 
>> I did a bunch of stuff.
>>
>> It works for me. And I think the way I did it I think it only works the way I expect it and that there are not side effects which are allowed.
> 
>    So everything you did is secret, and you're not going to document what you did.
> 
>    Wonderful.  If you want a reason why you think the documentation is bad, it's because people figure things out, and then refuse to contribute.

As I wrote multiple times before and you didn't seem to read: I can only 
contribute with a suggestion of a better text, if I understand how it 
works exactly. You don't want to help with that. Nor are you even trying 
to understand the confusion of those contradictory statements in the docs.

I can write a suggestion for the docs based on how I use it now. But I 
don't know if it's correct because I don't know where each parameter is 
used exactly. It works for me and I hope that it doesn't allow more 
clients certs then I want, but I cannot tell for sure.

However, the way I have configured it is mostly in direct contradiction 
to what in those comments. That adds to my hesitation to suggest a text.

I assume that the current text has been added there for a reason and is 
or was accurate at some time. Or the current text is accidentally 
incorrect, but noone noticed.

I am trying to figure out what's right.

>> The documentation is unclear. I have to guess what the documentation means. You ask me for documentation updates. How am I supposed to give you a documentation update from some guesses? That documentation won't get any better, it's just another guess.
> 
>    Excuses.  You can document a "howto":  This is what I did, and this is what happens, and this is what works.

Again: if I do that I want to give an accurate and correct description. 
I don't think a howto is helpful which contradicts the docs or another 
howto. People will just wonder more, why it's different or if it's 
different cases.

If I do something I do it right. I don't really think it's helpful to 
write a howto "ignore what's in the docs because it's wrong, but do it 
this way instead..."

>    All of your blaming me here is just excuses so that you to find reasons to *not* contribute.

It's you who is refusing and simply closed the issue before. It was a 
very clear sign to me that you are absolutely not interested in my 
feedback... It's not blame. You did close my issue. That's just what it is.

My current understanding on the use of those parameters is limited and 
the current docs are confusing. You are not helping to clear this 
confusion but you want me to write something. If I write something I 
want it to be accurate. I don't really see the point of changing those 
texts into something I guess what it is, because maybe that's not 
accurate either.

>> If that's a problem for you or doesn't fit your standards, well, no need to repeat your "patches are welcome"...
> 
>    My general response of "patches are welcome" is to people who give vague complaints, and then demand that everyone *else* do work.

"Statement A contradicts statement B" isn't vague. You demand from me to 
do the work to solve this contradiction.

>    For people who give clear descriptions of problems, I push in fixes.  Documentation updates, code changes, etc.  Anyone who's paid attention to the list will see hundreds of examples of people saying "this isn't clear", followed be me pushing a patch minutes later.

The docs for those parameters aren't clear. I do not know how to give a 
clearer description of that. If you want me to provide a documentation 
update, I need to understand what it's doing exactly and not based on my 
assumptions and guesses of how and where those parameters may be used...

>    Yet some people always find a reason to complain, and reasons why they should never contribute.  And it's never their fault.  Hence my hostility to that entitled and negative attitude.

The only negative attitude here comes from you. You quickly fall into 
hostility and quickly shut it down.

And it was you who complained about my explanation on how to use 
reject_unknown_intermediate_ca in this thread and why it is needed. It's 
the situation how it is and hopefully the solution for the issue the 
user had. I understand that it (probably) works different with 4.x. I 
don't really expect larger changes to go into 3.2 either, if 4.x is in 
the making. So it is as it is.

I then responded to your complaint. I have contributed to the other user 
and this list. So I really find this comment inappropriate. I do 
contribute. You just don't like my contributions for whatever reason. 
You just don't want to understand what I write. It probably doesn't 
matter how often and in what way I try to explain it. You want a clear 
explanation of something which isn't clear at the moment...

And considering my repeated attempts to explain the situation and how 
it's difficult to suggest a better text if it is unclear how it exactly 
works.

So negating all my contributions to "never" isn't really nice either. I 
know you can go into the technicality that you wrote "some people", but 
in the context it's obvious that you apply the generic to me, because 
otherwise it wouldn't make much sense.

I didn't complain. I understand that you simply don't like me or the way 
I explain and write my points. I understand that you consider this 
completely and totally my fault. I understand that you think this 
entitles you to quick hostility and shutting people down. I understand 
that you think it is no fault of yours at all...

It is what it is... I continue to contribute in the way I do, if you 
like it or not. You can complain about it or not. Or maybe I don't 
contribute anymore. There are a many other projects where they welcome 
my insight and contribution even if it is sometimes difficult to get a 
common understanding of things. And there is not this immediate hostility.

So like it or not...

Cheers,

Gerald