Hi, I'm currently looking at https://www.ietf.org/id/draft-mattsson-eap-tls13-02.txt. It states that: While Elliptic Curve Cryptography (ECC) was optional for earlier version of TLS, TLS 1.3 mandates support of ECC (see Section 9 of [I-D.ietf-tls-tls13]). To avoid fragmentation, the use of ECC in certificates, signature algorithms, and groups are RECOMMENDED when using EAP-TLS with TLS 1.3 or higher. That sounds like useful avice. I'm wondering though what to do if you have a diverse variety of client devices doing EAP; some of which only do TLS 1.2 while others do TLS 1.3. The EAP server can only present one certificate to its incoming peer connections. If it has a ECDSA certificate, there's a chance for an interop problem with TLS 1.2 clients not supporting the needed cipher suites. If it has a RSA certificate, it misses out on the small-cert benefits. I wonder if it's possible to have both certificates available to the server, with a late selection: depending on which TLS version has been negotiated, present one cert or the other. Is that kind of stuff doable? It would certainly make a transition easier... Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
On 12 Mar 2018, at 10:40, Stefan Winter <stefan.winter@restena.lu> wrote:
Is that kind of stuff doable?
It is - a few things support key agility, most notable example off the top of my head is nginx and apache. It requires a recent version of openssl, but for apache at least, in the configuration you just specify two cert/key statements. I don't think EAP would be any different - the actual sequence of messages exchanged between client and server is the same as in HTTPS right? As long as TLS1.3 doesn't push whatever heuristic is used to later in the exchange, I don't see that it would be any more difficult to support both ECDSA and RSA simultaneously. As far as I know, the process is transparent to the client. Regards, Adam Bishop gpg: E75B 1F92 6407 DFDF 9F1C BF10 C993 2504 6609 D460 jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.
On Mar 12, 2018, at 10:40 AM, Stefan Winter <stefan.winter@restena.lu> wrote:
I'm currently looking at https://www.ietf.org/id/draft-mattsson-eap-tls13-02.txt.
I'll be at the IETF next Monday, trying to convince them to Do the Right Thing.
It states that:
While Elliptic Curve Cryptography (ECC) was optional for earlier version of TLS, TLS 1.3 mandates support of ECC (see Section 9 of [I-D.ietf-tls-tls13]). To avoid fragmentation, the use of ECC in certificates, signature algorithms, and groups are RECOMMENDED when using EAP-TLS with TLS 1.3 or higher.
That sounds like useful advice.
Yes.
I'm wondering though what to do if you have a diverse variety of client devices doing EAP; some of which only do TLS 1.2 while others do TLS 1.3.
"When in danger or in doubt, run in circles, scream and shout." :)
The EAP server can only present one certificate to its incoming peer connections.
It should be able to pick the "right" certificate.
If it has a ECDSA certificate, there's a chance for an interop problem with TLS 1.2 clients not supporting the needed cipher suites.
If it has a RSA certificate, it misses out on the small-cert benefits.
Yes.
I wonder if it's possible to have both certificates available to the server, with a late selection: depending on which TLS version has been negotiated, present one cert or the other.
Is that kind of stuff doable?
Ask OpenSSL. :( We can do almost anything on our end. Getting the OpenSSL magic correct may be a bit harder. The OpenSSL documentation is a weird combination of exhaustive, and completely unhelpful. If anyone can take a look at how Apache does it, that would help. Simply knowing which OpenSSL calls to do, and in what order, will solve 99% of the problem. Alan DeKok.
On 12 Mar 2018, at 12:01, Alan DeKok <aland@deployingradius.com> wrote:
If anyone can take a look at how Apache does it, that would help. Simply knowing which OpenSSL calls to do, and in what order, will solve 99% of the problem.
I looked at the changes from NGINX - they wrap all of openssl's method calls, but it looks like you "just" call the OpenSSL api call that adds a key pair multiple times. https://trac.nginx.org/nginx/changeset/51e1f047d15d5602a8250dfe9192d0eae71e6... The changes adds a method that accepts an array of certs, which then iterates over the array calling the single certificate version each time. The only sticking point looks to be how to handle the certificate chain - they have a comment about that: https://github.com/nginx/nginx/blob/ed0cc4d52308b75ab217724392994e6828af4fda... It looks deceptively simple, for OpenSSL. Adam Bishop gpg: E75B 1F92 6407 DFDF 9F1C BF10 C993 2504 6609 D460 jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.
On 12 Mar 2018, at 16:41, Adam Bishop <Adam.Bishop@jisc.ac.uk> wrote:
On 12 Mar 2018, at 12:01, Alan DeKok <aland@deployingradius.com> wrote:
If anyone can take a look at how Apache does it, that would help. Simply knowing which OpenSSL calls to do, and in what order, will solve 99% of the problem.
I looked at the changes from NGINX - they wrap all of openssl's method calls, but it looks like you "just" call the OpenSSL api call that adds a key pair multiple times.
mod_ssl is 100x less concise than NGINX, but the same seems to happen. Unfortunately they don't have a single changes when support was added - key agility support magically appears in this refactor: https://github.com/apache/httpd/commit/d2344cb7ea7585f4c413045f2b1189802d8de... Same rough process, except much more verbose and then followed by a ton of alternative key loading mechanisms. I can't find any evidence that the ctx is initialised - the only requirement seems to be openssl 1.0.2+. Loop over the configuration array: https://github.com/apache/httpd/blob/2b9e9b4c4226c22d9f5c489661507e7547de051... Call load cert: https://github.com/apache/httpd/blob/2b9e9b4c4226c22d9f5c489661507e7547de051... Call load key: https://github.com/apache/httpd/blob/2b9e9b4c4226c22d9f5c489661507e7547de051... Rinse, repeat. Adam Bishop gpg: E75B 1F92 6407 DFDF 9F1C BF10 C993 2504 6609 D460 jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.
On 13 Mar 2018, at 00:18, Adam Bishop <Adam.Bishop@jisc.ac.uk> wrote:
I can't find any evidence that the ctx is initialised
s/initialised/initialised differently/ Adam Bishop gpg: E75B 1F92 6407 DFDF 9F1C BF10 C993 2504 6609 D460 jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.
Hi, so, with a bit of luck, this needs just a new config option in modules/eap to allow specifying more than one certificate; and a small amount of code to load both certs. That sounds so easy that I hear an imaginary "I have a bad feeling about this" ;-) Stefan Am 13.03.2018 um 01:20 schrieb Adam Bishop:
On 13 Mar 2018, at 00:18, Adam Bishop <Adam.Bishop@jisc.ac.uk> wrote:
I can't find any evidence that the ctx is initialised
s/initialised/initialised differently/
Adam Bishop
gpg: E75B 1F92 6407 DFDF 9F1C BF10 C993 2504 6609 D460
jisc.ac.uk
Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
-- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
On Mar 13, 2018, at 7:00 AM, Stefan Winter <stefan.winter@RESTENA.LU> wrote:
Hi,
so, with a bit of luck, this needs just a new config option in modules/eap to allow specifying more than one certificate; and a small amount of code to load both certs.
https://github.com/FreeRADIUS/freeradius-server/commit/e8df16d097c961ee80dd2... Pretty much. Due to the way OpenSSL validates private/public key pairs (see SSL_CTX_check_private_key - https://www.openssl.org/docs/man1.0.2/ssl/SSL_CTX_use_certificate.html) the certificate and private_key need to be loaded consecutively so it’s better to specify them together in a configuration stanza, then allow multiple instances of that stanza. certificate { pem_file_type = yes certificate_file = “<path>” private_key_password = “<password>" private_key_file = “<path>" } Using multiple certificate stanzas also allows different passwords to be specified for different pairs, and a mixture of ASN1 and PEM certs. One thing that i’m slightly unsure of is whether we should allow multiple key pairs on the client side too (I did for completeness), presumably crypto agility can be utilised by both TLS peers? Not back porting this to v3. The config parser isn’t sophisticated enough to so the same dynamic structure allocation, and it’d be a breaking change. -Arran
Hi,
One thing that i’m slightly unsure of is whether we should allow multiple key pairs on the client side too (I did for completeness), presumably crypto agility can be utilised by both TLS peers?
I don't think that's necessary: for client cert validation, you don't need private keys and can already use the _dir option if you have more than one CA. So you just put roots of all variety into one directory, and tell FR to validate incoming certs from that directory. So long as the matching root (and intermediates maybe) is in there at all, a chain leading to it can be found. It's the standard and working since a decade way of handling multi roots. So I'd rather not have new code if there's a way without. Stefan -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
On Mar 14, 2018, at 7:23 AM, Stefan Winter <stefan.winter@RESTENA.LU> wrote:
Hi,
One thing that i’m slightly unsure of is whether we should allow multiple key pairs on the client side too (I did for completeness), presumably crypto agility can be utilised by both TLS peers?
I don't think that's necessary: for client cert validation, you don't need private keys and can already use the _dir option if you have more than one CA.
Sorry, wasn’t clear. The SSL_CTX configuration code is common for both TLS servers and TLS clients, and is used for both EAP and RADSEC. In this case FreeRADIUS would be acting as a TLS client for RADSEC. -Arran
Hi,
Sorry, wasn’t clear. The SSL_CTX configuration code is common for both TLS servers and TLS clients, and is used for both EAP and RADSEC. In this case FreeRADIUS would be acting as a TLS client for RADSEC.
Ah. Well the cert length considerations are really about EAP as the data channel is so narrow and peculiar. In a RadSec connection, length of the cert is a NOOP consideration. Of course if you really want to have two distinct certs for actual security reasons(?), then yes, multiple client certs would be useful there. Stefan -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
On Mar 14, 2018, at 1:57 PM, Stefan Winter <stefan.winter@RESTENA.LU> wrote:
Hi,
Sorry, wasn’t clear. The SSL_CTX configuration code is common for both TLS servers and TLS clients, and is used for both EAP and RADSEC. In this case FreeRADIUS would be acting as a TLS client for RADSEC.
Ah. Well the cert length considerations are really about EAP as the data channel is so narrow and peculiar.
In a RadSec connection, length of the cert is a NOOP consideration.
Of course if you really want to have two distinct certs for actual security reasons(?), then yes, multiple client certs would be useful there.
OK, yes, that’s what I was querying. I guess it’d also allow you to select different certificates depending on the CA list advertised by the server, as well as different certificates for crypto agility. -Arran
Hi,
I guess it’d also allow you to select different certificates depending on the CA list advertised by the server, as well as different certificates for crypto agility.
True! In RFC6614 I wrote that the CA indication is something that should be honoured (it's useful if your server is in multiple consortia and needs to have different certs) but since eduroam seems to be the only large dynamic discovery + Radsec consortium, this was never urgent to actually do. Which doesn't mean it shouldn't be done :-) Stefan -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
On Mar 14, 2018, at 3:41 PM, Stefan Winter <stefan.winter@RESTENA.LU> wrote:
Hi,
I guess it’d also allow you to select different certificates depending on the CA list advertised by the server, as well as different certificates for crypto agility.
True! In RFC6614 I wrote that the CA indication is something that should be honoured (it's useful if your server is in multiple consortia and needs to have different certs) but since eduroam seems to be the only large dynamic discovery + Radsec consortium, this was never urgent to actually do. Which doesn't mean it shouldn't be done :-)
OK, finished messing around with he config files and config file format. - certificate {} sections are now called chain {} sections to better match what we’re doing with them (building key type specific chains). - The server at debug level 3 (-Xx) will now print out which key types it loaded chains for, and which certificates make up those chains. Thu Mar 15 18:44:05 2018 : tls - Found 2 server certificate chain(s) Thu Mar 15 18:44:05 2018 : tls - RSA chain Thu Mar 15 18:44:05 2018 : tls - [0] RSA /C=FR/ST=Radius/O=Example Inc/CN=Example Server Certificate/emailAddress=admin@example.org Thu Mar 15 18:44:05 2018 : tls - EC chain Thu Mar 15 18:44:05 2018 : tls - [1] EC /C=FR/ST=Radius/L=Somewhere/O=Example Inc/emailAddress=admin@example.org/CN=Example Certificate Authority Thu Mar 15 18:44:05 2018 : tls - [0] EC /C=FR/ST=Radius/O=Example Inc/CN=Example Server Certificate/emailAddress=admin@example.org - A few extra Makefile targets have been added to generate ecc certificates. - Certificate chain compilation functions in OpenSSL 1.0.2 have now been exposed. This allows us to build and validate chains on startup. This also has a performance benefit at the chains are no longer built at runtime. The pre-compiled chains will not include certs from the top level ca_file or ca_path. - For the pre-compiled chains to work, you must provide all certificates from the Root CA to the server certificate. - With OpenSSL 1.0.2 and the default v4 config, the Root CA will not be sent to the supplicant as part of the chain even if you include it in the PEM certificate bundle. If you want additional changes in the docs and/or demo EC certs to be configured by default, please send pull requests. It’d also be nice if someone could test give this some more thorough testing. -Arran
nice...its about time some nice debug output was provided to show what was being read and created. question, can we have an option to send the CA to the client as well (just for completeness, to ensure current capabilities (and to deal with older horrible clients) arent lost? I'll have to give v4 another go now :) alan
On Mar 15, 2018, at 7:22 PM, Alan Buxey <alan.buxey@gmail.com> wrote:
nice...its about time some nice debug output was provided to show what was being read and created. question, can we have an option to send the CA to the client as well (just for completeness, to ensure current capabilities (and to deal with older horrible clients) arent lost?
Already there :) chain { … # # Only available with OpenSSL >= 1.0.2 # # Omit the Root CA from the compiled certificate chain. # The Root CA should already be known/trusted by the client so it is # usually not needed unless the client is particularly poorly behaved. # # Note: The Root CA must still be available for chain compilation to # succeed even if "include_root_ca = no". # include_root_ca = yes } https://github.com/FreeRADIUS/freeradius-server/blob/v4.0.x/raddb/mods-avail... <https://github.com/FreeRADIUS/freeradius-server/blob/v4.0.x/raddb/mods-available/eap#L193> The debug output will reflect exactly what certs will be sent, so toggling it you’ll see an extra cert appearing/disappearing. -Arran
thx! alan On 15 March 2018 at 19:55, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On Mar 15, 2018, at 7:22 PM, Alan Buxey <alan.buxey@gmail.com> wrote:
nice...its about time some nice debug output was provided to show what was being read and created. question, can we have an option to send the CA to the client as well (just for completeness, to ensure current capabilities (and to deal with older horrible clients) arent lost?
Already there :)
chain { …
# # Only available with OpenSSL >= 1.0.2 # # Omit the Root CA from the compiled certificate chain. # The Root CA should already be known/trusted by the client so it is # usually not needed unless the client is particularly poorly behaved. # # Note: The Root CA must still be available for chain compilation to # succeed even if "include_root_ca = no". # include_root_ca = yes }
https://github.com/FreeRADIUS/freeradius-server/blob/v4.0.x/raddb/mods-avail... <https://github.com/FreeRADIUS/freeradius-server/blob/v4.0.x/raddb/mods-available/eap#L193>
The debug output will reflect exactly what certs will be sent, so toggling it you’ll see an extra cert appearing/disappearing.
-Arran - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Hi, hm, added a comment to that commit. I don't trust GitHub enough to assume you've been notified and have seen it (did you?) Stefan Am 13.03.2018 um 19:20 schrieb Arran Cudbard-Bell:
On Mar 13, 2018, at 7:00 AM, Stefan Winter <stefan.winter@RESTENA.LU> wrote:
Hi,
so, with a bit of luck, this needs just a new config option in modules/eap to allow specifying more than one certificate; and a small amount of code to load both certs.
https://github.com/FreeRADIUS/freeradius-server/commit/e8df16d097c961ee80dd2...
Pretty much. Due to the way OpenSSL validates private/public key pairs (see SSL_CTX_check_private_key - https://www.openssl.org/docs/man1.0.2/ssl/SSL_CTX_use_certificate.html) the certificate and private_key need to be loaded consecutively so it’s better to specify them together in a configuration stanza, then allow multiple instances of that stanza.
certificate { pem_file_type = yes certificate_file = “<path>” private_key_password = “<password>" private_key_file = “<path>" }
Using multiple certificate stanzas also allows different passwords to be specified for different pairs, and a mixture of ASN1 and PEM certs.
One thing that i’m slightly unsure of is whether we should allow multiple key pairs on the client side too (I did for completeness), presumably crypto agility can be utilised by both TLS peers?
Not back porting this to v3. The config parser isn’t sophisticated enough to so the same dynamic structure allocation, and it’d be a breaking change.
-Arran
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
-- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
participants (5)
-
Adam Bishop -
Alan Buxey -
Alan DeKok -
Arran Cudbard-Bell -
Stefan Winter