Proposal for restricting authentication concerning use of revoked and expired GPG ID's in key-cert objects
Dear DB WG, It came to my attention the RIPE NCC Database does not do validation of signed updates. (Other than checking the key is allowed to sign updates for object(s) in question) I got the understanding from writing to DB-WG-Chairs this was a decision made years back. I think is less than optimal from a security perspective an signed update (with GPG and/or X509 certs) is not validated against (1) when the update was signed (E.g. signing was done 10 minutes ago) and (2) that the expiration date for the keys are not validated. Usually I will expect if I revoke a GPG-key|X509-cert. It cannot be used any more. But the RIPE NCC Database does still allow this currently. This is relevant in the case I ever lose a private GPG-key|X509-cert to less than friendly 3rd-parties. And the lost private GPG-key|X509-cert is the one used for signing updates to the database. What I have in mind. Is the RIPE NCC Database begins verifying validity (not revoked and/or expired) of GPG-key|X509-cert used to sign updates with. Christoffer
Hi Christoffer, DB WG,
On 1 Nov 2018, at 15:35, Christoffer Hansen (Lists) via db-wg <db-wg@ripe.net> wrote:
Dear DB WG,
It came to my attention the RIPE NCC Database does not do validation of signed updates. (Other than checking the key is allowed to sign updates for object(s) in question)
The RIPE database validates a signed update message against any PGP or X509 key(s) associated with the maintainer(s) of the object. The database will WARN on update if the key-cert (containing a public key or certificate) is expired, and will FAIL the update if the key-cert is revoked.
I got the understanding from writing to DB-WG-Chairs this was a decision made years back.
This has been the behaviour at least since the re-implementation in 2012, we retained the existing behaviour for compatibility.
I think is less than optimal from a security perspective an signed update (with GPG and/or X509 certs) is not validated against (1) when the update was signed (E.g. signing was done 10 minutes ago) and (2) that the expiration date for the keys are not validated.
The RIPE database does validate key expiry but only adds a warning to the response. Should the RIPE database refuse to apply updates signed with an expired key? Should the RIPE database refuse to apply updates that were signed more than 'n' minutes ago (or in the future) ?
Usually I will expect if I revoke a GPG-key|X509-cert. It cannot be used any more. But the RIPE NCC Database does still allow this currently. This is relevant in the case I ever lose a private GPG-key|X509-cert to less than friendly 3rd-parties. And the lost private GPG-key|X509-cert is the one used for signing updates to the database.
Revoked keys indeed cannot be used any more. To revoke a key, you will need to update the existing key-cert object with the revoked version. You can also delete the key-cert object. Is it enough to update or delete a revoked key? Should the RIPE database process key revocation certificates?
What I have in mind. Is the RIPE NCC Database begins verifying validity (not revoked and/or expired) of GPG-key|X509-cert used to sign updates with.
Christoffer
Regards Ed Shryane RIPE NCC
On 05/11/2018 16:12, Edward Shryane wrote:
This has been the behaviour at least since the re-implementation in 2012, we retained the existing behaviour for compatibility.
I would not mind breaking this compatibility for a slight increase in security. Since the current behaviour has been in place for 6 or more years.
The RIPE database does validate key expiry but only adds a warning to the response. Should the RIPE database refuse to apply updates signed with an expired key?
I will strongly PREFER if updates signed with an expired key is refused.
Should the RIPE database refuse to apply updates that were signed more than 'n' minutes ago (or in the future) ?
I would say YES to this one. And prefer at most 1 hour of maximum accepted time since the message was signed. Before the update message will not be accepted and an error returned to the sender.
Revoked keys indeed cannot be used any more. To revoke a key, you will need to update the existing key-cert object with the revoked version. You can also delete the key-cert object.
Is it enough to update or delete a revoked key? Should the RIPE database process key revocation certificates?
o If emailed to auto-dbm@. I suggest it be processed and queued for automatic removal from the DB. o Having a regular scan of existing keys in the DB. And automatically remove the ones recently expired with a warning message to the maintainer of the automatic removal. Is what I will strongly prefer. (Similar process to how unreferenced person objects is removed today) Christoffer
Hi, On Mon, Nov 05, 2018 at 04:12:10PM +0100, Edward Shryane via db-wg wrote:
Should the RIPE database refuse to apply updates that were signed more than 'n' minutes ago (or in the future) ?
I think this would be a valuable improvement.
Usually I will expect if I revoke a GPG-key|X509-cert. It cannot be used any more. But the RIPE NCC Database does still allow this currently. This is relevant in the case I ever lose a private GPG-key|X509-cert to less than friendly 3rd-parties. And the lost private GPG-key|X509-cert is the one used for signing updates to the database.
Revoked keys indeed cannot be used any more. To revoke a key, you will need to update the existing key-cert object with the revoked version. You can also delete the key-cert object.
Is it enough to update or delete a revoked key? Should the RIPE database process key revocation certificates?
One of the problems here is that the RIPE DB cannot reliably know if a GPG key is revoked, unless it is *told*. "Telling it" can be done nicely by removing the key-cert object - otherwiese it would need to poll key-servers and hope for a key revocation to appear there. A catch-22 arises if the key-cert object needs a signed update with that very key to be deleted... (Not providing solutions, just bringing up aspects to consider) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On 05/11/2018 17:56, Gert Doering wrote:
On Mon, Nov 05, 2018 at 04:12:10PM +0100, Edward Shryane via db-wg wrote:
Is it enough to update or delete a revoked key? Should the RIPE database process key revocation certificates?
One of the problems here is that the RIPE DB cannot reliably know if a GPG key is revoked, unless it is *told*.
"Telling it" can be done nicely by removing the key-cert object - otherwiese it would need to poll key-servers and hope for a key revocation to appear there.
I suggest just removing the key-cert object. Instead of updating the key-cert object with a revoked version.
A catch-22 arises if the key-cert object needs a signed update with that very key to be deleted...
I would not use this approach of requiring a signed update to remove the key. If an authenticated SSO account is signed into the RIPE NCC website and tries to remove a key-cert object the DB. This should be allowed. -- Christoffer Hansen
Dear Working Group, to follow up on this discussion, the upcoming Whois 1.93 release will implement the following changes: - Updates signed with an expired PGP key or X509 certificate will now FAIL (currently a warning is generated). - Updates will FAIL one hour after they are signed, and also updates signed more than one hour in the future. - Updates to key-cert objects with an Expired or Revoked public key (or certificate) will FAIL. To measure the potential impact of these changes, I reviewed all Whois updates between October - December 2018. - Approximately 4% of all updates are signed with a PGP key or X509 certificate. - 99% of X509 key-cert certificates are expired. I found 5 X509 signed updates with an expired key. - 16% of PGP key-cert keys are expired. I found 63 PGP signed updates with an expired key. - I found 24 PGP signed updates more than one hour in the past, and none signed in the future. We will notify maintainers of expired key-cert objects separately (by email) of this upcoming change. Regards Ed Shryane RIPE NCC
On 1 Nov 2018, at 15:35, Christoffer Hansen (Lists) via db-wg <db-wg@ripe.net> wrote:
Dear DB WG,
It came to my attention the RIPE NCC Database does not do validation of signed updates. (Other than checking the key is allowed to sign updates for object(s) in question)
I got the understanding from writing to DB-WG-Chairs this was a decision made years back.
I think is less than optimal from a security perspective an signed update (with GPG and/or X509 certs) is not validated against (1) when the update was signed (E.g. signing was done 10 minutes ago) and (2) that the expiration date for the keys are not validated.
Usually I will expect if I revoke a GPG-key|X509-cert. It cannot be used any more. But the RIPE NCC Database does still allow this currently. This is relevant in the case I ever lose a private GPG-key|X509-cert to less than friendly 3rd-parties. And the lost private GPG-key|X509-cert is the one used for signing updates to the database.
What I have in mind. Is the RIPE NCC Database begins verifying validity (not revoked and/or expired) of GPG-key|X509-cert used to sign updates with.
Christoffer
Hi Ed Thanks for following up on this. Just one question, have you taken into account time zones? If an update is signed now in Dubai it is 19:51. If the update is processed on Amsterdam time, it is 16:51. Will this update fail because it is 3 hours in the future? cheersdenisco-chair DB-WG From: Edward Shryane via db-wg <db-wg@ripe.net> To: db-wg <db-wg@ripe.net> Sent: Monday, 11 February 2019, 15:55 Subject: Re: [db-wg] Proposal for restricting authentication concerning use of revoked and expired GPG ID's in key-cert objects Dear Working Group, to follow up on this discussion, the upcoming Whois 1.93 release will implement the following changes: - Updates signed with an expired PGP key or X509 certificate will now FAIL (currently a warning is generated). - Updates will FAIL one hour after they are signed, and also updates signed more than one hour in the future. - Updates to key-cert objects with an Expired or Revoked public key (or certificate) will FAIL. To measure the potential impact of these changes, I reviewed all Whois updates between October - December 2018. - Approximately 4% of all updates are signed with a PGP key or X509 certificate. - 99% of X509 key-cert certificates are expired. I found 5 X509 signed updates with an expired key. - 16% of PGP key-cert keys are expired. I found 63 PGP signed updates with an expired key. - I found 24 PGP signed updates more than one hour in the past, and none signed in the future. We will notify maintainers of expired key-cert objects separately (by email) of this upcoming change. Regards Ed Shryane RIPE NCC
On 1 Nov 2018, at 15:35, Christoffer Hansen (Lists) via db-wg <db-wg@ripe.net> wrote:
Dear DB WG,
It came to my attention the RIPE NCC Database does not do validation of signed updates. (Other than checking the key is allowed to sign updates for object(s) in question)
I got the understanding from writing to DB-WG-Chairs this was a decision made years back.
I think is less than optimal from a security perspective an signed update (with GPG and/or X509 certs) is not validated against (1) when the update was signed (E.g. signing was done 10 minutes ago) and (2) that the expiration date for the keys are not validated.
Usually I will expect if I revoke a GPG-key|X509-cert. It cannot be used any more. But the RIPE NCC Database does still allow this currently. This is relevant in the case I ever lose a private GPG-key|X509-cert to less than friendly 3rd-parties. And the lost private GPG-key|X509-cert is the one used for signing updates to the database.
What I have in mind. Is the RIPE NCC Database begins verifying validity (not revoked and/or expired) of GPG-key|X509-cert used to sign updates with.
Christoffer
Hi Denis,
On 11 Feb 2019, at 16:53, denis walker <ripedenis@yahoo.co.uk> wrote:
Hi Ed
Thanks for following up on this. Just one question, have you taken into account time zones? If an update is signed now in Dubai it is 19:51. If the update is processed on Amsterdam time, it is 16:51. Will this update fail because it is 3 hours in the future?
cheers denis co-chair DB-WG
Good question. We rely on the Bouncy Castle cryptography library to provide the signing time for the message, and it does appear to take the timezone into account. I tested by signing a message inside a virtual machine set to a different timezone (EST), and the signature creation time was correctly mapped to the local timezone (within a minute rather than hours). The signed updates in production appear to confirm this - only 24 messages were more than 1 hour old, out of 118,183 (from October to December 2018), and none of these appeared to be offset by a multiple of hours. Regards Ed
I’m surprised at the question. I don’t know PGP/GPG all that well, but I checked and the IETF standard for X-509 certificates (RFC5280) requires CAs to use UTC in the signature time fields, and CMS (RFC5682) requires UTC in the SigningTime (in both cases, up to the year 2049). Does this become an issue because the signatures in the RIPE database are doing something different? —Sandy
On Feb 11, 2019, at 11:41 AM, Edward Shryane via db-wg <db-wg@ripe.net> wrote:
Hi Denis,
On 11 Feb 2019, at 16:53, denis walker <ripedenis@yahoo.co.uk> wrote:
Hi Ed
Thanks for following up on this. Just one question, have you taken into account time zones? If an update is signed now in Dubai it is 19:51. If the update is processed on Amsterdam time, it is 16:51. Will this update fail because it is 3 hours in the future?
cheers denis co-chair DB-WG
Good question. We rely on the Bouncy Castle cryptography library to provide the signing time for the message, and it does appear to take the timezone into account.
I tested by signing a message inside a virtual machine set to a different timezone (EST), and the signature creation time was correctly mapped to the local timezone (within a minute rather than hours).
The signed updates in production appear to confirm this - only 24 messages were more than 1 hour old, out of 118,183 (from October to December 2018), and none of these appeared to be offset by a multiple of hours.
Regards Ed
Hi Sandy, according to the OpenPGP Message Format RFC (https://tools.ietf.org/html/rfc4880), the signature creation time is in UTC. 3.5. Time Fields A time field is an unsigned four-octet number containing the number of seconds elapsed since midnight, 1 January 1970 UTC. 5.2.3.4. Signature Creation Time (4-octet time field) The time the signature was made. Regards Ed
On 11 Feb 2019, at 19:29, Sandra Murphy <sandy@tislabs.com> wrote:
I’m surprised at the question. I don’t know PGP/GPG all that well, but I checked and the IETF standard for X-509 certificates (RFC5280) requires CAs to use UTC in the signature time fields, and CMS (RFC5682) requires UTC in the SigningTime (in both cases, up to the year 2049).
Does this become an issue because the signatures in the RIPE database are doing something different?
—Sandy
On Feb 11, 2019, at 11:41 AM, Edward Shryane via db-wg <db-wg@ripe.net> wrote:
Hi Denis,
On 11 Feb 2019, at 16:53, denis walker <ripedenis@yahoo.co.uk> wrote:
Hi Ed
Thanks for following up on this. Just one question, have you taken into account time zones? If an update is signed now in Dubai it is 19:51. If the update is processed on Amsterdam time, it is 16:51. Will this update fail because it is 3 hours in the future?
cheers denis co-chair DB-WG
Good question. We rely on the Bouncy Castle cryptography library to provide the signing time for the message, and it does appear to take the timezone into account.
I tested by signing a message inside a virtual machine set to a different timezone (EST), and the signature creation time was correctly mapped to the local timezone (within a minute rather than hours).
The signed updates in production appear to confirm this - only 24 messages were more than 1 hour old, out of 118,183 (from October to December 2018), and none of these appeared to be offset by a multiple of hours.
Regards Ed
Hi Just playing devil's advocate to be sure :) cheersdenisco-chair DB-WG From: Edward Shryane <eshryane@ripe.net> To: Sandra Murphy <sandy@tislabs.com> Cc: denis walker <ripedenis@yahoo.co.uk>; db-wg <db-wg@ripe.net> Sent: Monday, 11 February 2019, 19:56 Subject: Re: [db-wg] Proposal for restricting authentication concerning use of revoked and expired GPG ID's in key-cert objects Hi Sandy, according to the OpenPGP Message Format RFC (https://tools.ietf.org/html/rfc4880), the signature creation time is in UTC. 3.5. Time Fields A time field is an unsigned four-octet number containing the number of seconds elapsed since midnight, 1 January 1970 UTC. 5.2.3.4. Signature Creation Time (4-octet time field) The time the signature was made. Regards Ed
On 11 Feb 2019, at 19:29, Sandra Murphy <sandy@tislabs.com> wrote:
I’m surprised at the question. I don’t know PGP/GPG all that well, but I checked and the IETF standard for X-509 certificates (RFC5280) requires CAs to use UTC in the signature time fields, and CMS (RFC5682) requires UTC in the SigningTime (in both cases, up to the year 2049).
Does this become an issue because the signatures in the RIPE database are doing something different?
—Sandy
On Feb 11, 2019, at 11:41 AM, Edward Shryane via db-wg <db-wg@ripe.net> wrote:
Hi Denis,
On 11 Feb 2019, at 16:53, denis walker <ripedenis@yahoo.co.uk> wrote:
Hi Ed
Thanks for following up on this. Just one question, have you taken into account time zones? If an update is signed now in Dubai it is 19:51. If the update is processed on Amsterdam time, it is 16:51. Will this update fail because it is 3 hours in the future?
cheers denis co-chair DB-WG
Good question. We rely on the Bouncy Castle cryptography library to provide the signing time for the message, and it does appear to take the timezone into account.
I tested by signing a message inside a virtual machine set to a different timezone (EST), and the signature creation time was correctly mapped to the local timezone (within a minute rather than hours).
The signed updates in production appear to confirm this - only 24 messages were more than 1 hour old, out of 118,183 (from October to December 2018), and none of these appeared to be offset by a multiple of hours.
Regards Ed
participants (7)
-
Christoffer Hansen -
Christoffer Hansen (Lists) -
denis walker -
Edward Shryane -
Gert Doering -
netravnen＠gmail.com -
Sandra Murphy