Hi, I'm currently implementing an OCSP responder for use with EAP-TLS. I think I found a case of insufficient algorithm agility. Or I'm doing something wrong, hence my mail to the list here -can someone quickly confirm if I'm on the right track? I have a copy of the request FR 3.0.12 sends and the response I send back: [root@snf-734018 ticker]# openssl ocsp -reqin realrequest.der -req_text OCSP Request Data: Version: 1 (0x0) Requestor List: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: DCEB2C72264239201A4A5DF547C78268A1CB33A2 Issuer Key Hash: BC8DDD42F7B3B458E8ECEE403D21D404CEB9F2D0 Serial Number: 0BA50D497E [root@snf-734018 ticker]# openssl ocsp -respin realresponse.der -resp_text OCSP Response Data: OCSP Response Status: successful (0x0) Response Type: Basic OCSP Response Version: 1 (0x0) Responder Id: O = eduroam, OU = eduroam-as-a-Service, CN = eduroam-as-a-Service Client Auth Issuing CA - Prototype Produced At: Jan 11 08:24:56 2017 GMT Responses: Certificate ID: Hash Algorithm: sha256 Issuer Name Hash: 7A6CC4FC2F34491E91A8764D1F0990FB8FE02FE6FD64713AE4DCE0E731E5B508 Issuer Key Hash: D9CE624ED036FD290E8BDA9A36107D40D37C41DF1BB268741157074D66B3C038 Serial Number: 0BA50D497E Cert Status: good This Update: Jan 11 08:24:56 2017 GMT Next Update: Jan 21 08:24:56 2017 GMT Signature Algorithm: sha256WithRSAEncryption As can be seen, the request is about the same certificate (by serial), and the issuer and key are identical (I verified that out-of-band; it's my own CA and my own response generator. I am sure all is good.). But: FreeRADIUS sends the name and key hashes hashed with SHA1; my resonse does the hashes with SHA256. The result in debug mode is: Wed Jan 11 03:56:13 2017 : Debug: (54) eap_tls: Starting OCSP Request Wed Jan 11 03:56:13 2017 : Debug: (54) eap_tls: ocsp: Using responder URL "http://ocsp-test.hosted.eduroam.org:80/ticker/" Wed Jan 11 03:56:13 2017 : ERROR: (54) eap_tls: ocsp: No Status found Wed Jan 11 03:56:13 2017 : ERROR: (54) eap_tls: ocsp: Certificate has been expired/revoked The Status sits right there in the response: "Cert Status: good" but for some reason FR won't accept it. I believe it would be easy to fix this; calculate the name and key hashes for both algos and check if the response matches any one of those. I thought I could slap you with RFC6960's section 4.3: "Clients that request OCSP services SHALL be capable of processing responses signed using RSA with SHA-256 (identified by the sha256WithRSAEncryption OID specified in [RFC4055]). " but that one only pertains to the signature hash algorithm of the full response (which is sha256, and which does not seem to be the issue here). So, is all that correct? For the moment I will generate responses with SHA1 name and key hashes. But it feels like a step in the wrong direction. 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
And, for the record, if I use SHA1 name and key hashes, the result is as expected: Wed Jan 11 04:34:28 2017 : Debug: (5) eap_tls: Starting OCSP Request Wed Jan 11 04:34:28 2017 : Debug: (5) eap_tls: ocsp: Using responder URL "http://ocsp-test.hosted.eduroam.org:80/ticker/" Wed Jan 11 04:34:28 2017 : Debug: Waking up in 0.4 seconds. Wed Jan 11 04:34:28 2017 : Debug: Waking up in 0.7 seconds. This Update: Jan 11 09:33:01 2017 GMT Next Update: Jan 21 09:33:01 2017 GMT Wed Jan 11 04:34:29 2017 : Debug: (5) eap_tls: ocsp: Cert status: good Wed Jan 11 04:34:29 2017 : Debug: (5) eap_tls: ocsp: Certificate is valid Stefan Am 11.01.2017 um 10:30 schrieb Stefan Winter:
Hi,
I'm currently implementing an OCSP responder for use with EAP-TLS. I think I found a case of insufficient algorithm agility. Or I'm doing something wrong, hence my mail to the list here -can someone quickly confirm if I'm on the right track?
I have a copy of the request FR 3.0.12 sends and the response I send back:
[root@snf-734018 ticker]# openssl ocsp -reqin realrequest.der -req_text OCSP Request Data: Version: 1 (0x0) Requestor List: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: DCEB2C72264239201A4A5DF547C78268A1CB33A2 Issuer Key Hash: BC8DDD42F7B3B458E8ECEE403D21D404CEB9F2D0 Serial Number: 0BA50D497E [root@snf-734018 ticker]# openssl ocsp -respin realresponse.der -resp_text OCSP Response Data: OCSP Response Status: successful (0x0) Response Type: Basic OCSP Response Version: 1 (0x0) Responder Id: O = eduroam, OU = eduroam-as-a-Service, CN = eduroam-as-a-Service Client Auth Issuing CA - Prototype Produced At: Jan 11 08:24:56 2017 GMT Responses: Certificate ID: Hash Algorithm: sha256 Issuer Name Hash: 7A6CC4FC2F34491E91A8764D1F0990FB8FE02FE6FD64713AE4DCE0E731E5B508 Issuer Key Hash: D9CE624ED036FD290E8BDA9A36107D40D37C41DF1BB268741157074D66B3C038 Serial Number: 0BA50D497E Cert Status: good This Update: Jan 11 08:24:56 2017 GMT Next Update: Jan 21 08:24:56 2017 GMT
Signature Algorithm: sha256WithRSAEncryption
As can be seen, the request is about the same certificate (by serial), and the issuer and key are identical (I verified that out-of-band; it's my own CA and my own response generator. I am sure all is good.).
But: FreeRADIUS sends the name and key hashes hashed with SHA1; my resonse does the hashes with SHA256.
The result in debug mode is:
Wed Jan 11 03:56:13 2017 : Debug: (54) eap_tls: Starting OCSP Request Wed Jan 11 03:56:13 2017 : Debug: (54) eap_tls: ocsp: Using responder URL "http://ocsp-test.hosted.eduroam.org:80/ticker/" Wed Jan 11 03:56:13 2017 : ERROR: (54) eap_tls: ocsp: No Status found Wed Jan 11 03:56:13 2017 : ERROR: (54) eap_tls: ocsp: Certificate has been expired/revoked
The Status sits right there in the response: "Cert Status: good" but for some reason FR won't accept it.
I believe it would be easy to fix this; calculate the name and key hashes for both algos and check if the response matches any one of those.
I thought I could slap you with RFC6960's section 4.3: "Clients that request OCSP services SHALL be capable of processing responses signed using RSA with SHA-256 (identified by the sha256WithRSAEncryption OID specified in [RFC4055]). "
but that one only pertains to the signature hash algorithm of the full response (which is sha256, and which does not seem to be the issue here).
So, is all that correct?
For the moment I will generate responses with SHA1 name and key hashes. But it feels like a step in the wrong direction.
Greetings,
Stefan Winter
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.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 Jan 11, 2017, at 4:30 AM, Stefan Winter <stefan.winter@restena.lu> wrote:
But: FreeRADIUS
... OpenSSL...
sends the name and key hashes hashed with SHA1; my resonse does the hashes with SHA256.
The result in debug mode is:
Wed Jan 11 03:56:13 2017 : Debug: (54) eap_tls: Starting OCSP Request Wed Jan 11 03:56:13 2017 : Debug: (54) eap_tls: ocsp: Using responder URL "http://ocsp-test.hosted.eduroam.org:80/ticker/" Wed Jan 11 03:56:13 2017 : ERROR: (54) eap_tls: ocsp: No Status found Wed Jan 11 03:56:13 2017 : ERROR: (54) eap_tls: ocsp: Certificate has been expired/revoked
The Status sits right there in the response: "Cert Status: good" but for some reason FR
... OpenSSL...
won't accept it.
I believe it would be easy to fix this; calculate the name and key hashes for both algos and check if the response matches any one of those.
I thought I could slap you with RFC6960's section 4.3: "Clients that request OCSP services SHALL be capable of processing responses signed using RSA with SHA-256 (identified by the sha256WithRSAEncryption OID specified in [RFC4055]). "
but that one only pertains to the signature hash algorithm of the full response (which is sha256, and which does not seem to be the issue here).
So, is all that correct?
Mostly. We don't implement OCSP. OpenSSL does. We just call the OpenSSL API. If it returns "no", there's not a lot we can do. Perhaps try upgrading OpenSSL. Alan DeKok.
We don't implement OCSP. OpenSSL does. We just call the OpenSSL API. If it returns "no", there's not a lot we can do.
Perhaps try upgrading OpenSSL.
Agreed, you need at least 0.9.8l for sha256 Looking through the OCSP API we can control the digest algorithms used for generating the request, so we might be able to swap the digests to SHA256, which would likely fix your issue, but agreed the OpenSSL code should be more agile. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Hello,
Perhaps try upgrading OpenSSL.
Agreed, you need at least 0.9.8l for sha256
This is CentOS 7, OpenSSL 1.0.1e-fips 11 Feb 2013 I'm fairly certain that a generic "SHA256 support" is not specific enough; OpenSSL would have to know that at exactly this place SHA256 is expected and needs to be supported.
Looking through the OCSP API we can control the digest algorithms used for generating the request, so we might be able to swap the digests to SHA256, which would likely fix your issue, but agreed the OpenSSL code should be more agile.
Digest crypto agility is not the issue (also the failing response didn't fail on the SHA256 digest response signature). It's rather about controlling the hash algo for the issuer key and name. If this is all on OpenSSL's side then I guess the only thing to say is "too bad". I'll stick with SHA1 then. Greetings, 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
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
Stefan Winter