Support Cancel-Lock

[rra]

Reported by eagle on 14 Dec 2008 07:14 UTC Cancel-Lock was a draft for a way to authenticate cancels cryptographically, the idea being that all articles would contain challenges that could only be met by the person knowing the original challenge secret. A cancel would then only be honored if it had the answer to the challenge in the article.

Abuse of cancels has dropped considerably and the Cancel-Lock protocol never made it to an RFC, but it may still be worth looking at supporting this in INN.

The first attached approach is from Andreas Barth. It has the following features:

• A user can only post cancels for articles that are local posted or were originally generated and canceled by a cancel-lock enabled newsreader. The administrator may however allow users in readers.conf to post cancels for every article.

• The patch adds just a very small burden on accepting articles and cancels with post and almost no burden at all for transferring articles.

• Any news system could detect whether a cancel for an article originating at your site is fraud.

The patch does the following:

• if an article is posted, - unless existing - a user cancel lock is added, and always an admin cancel lock is added.

• if a cancel (oder supersedes) is posted, a user cancel key is always added. Now it is checked, whether one of the keys matches one of the locks. If yes, the cancel is accepted. The cancel is also accepted, if the original article is (no longer) available, or the original article has no lock and was posted before a given time (to allow for the transition periode). Otherwise, the cancel is rejected.

You must also create the files /etc/news/canlock.def and /etc/news/canlock.adm and fill them with any characters (but please use printable characters, that makes the live of fgets easier). The patch needs some polishing before inclusion, especially review and removing of the fixed path for the secret files.

Also attached is another approach. Both require the libcanlock library, also attached.

• libcanlock.tar.gz (libcanlock library)
• canlock.tar.gz (another Cancel-Lock patch, older)
• nnrpd-cancel-lock.patch.txt (patch against INN 2.3.5)

[rra]

Comment by iulius on 21 Dec 2008 21:28 UTC The draft can be found at http://tools.ietf.org/html/draft-ietf-usefor-cancel-lock-01.

[rra]

Comment by iulius on 21 Dec 2008 21:30 UTC Another approach by Alexander Bartolich:

https://code.th-h.de/?p=usenet/INN.git

Also see (in German):

news:f683h5$51u$7@news.albasani.net news:f8ffta$dd1$3@news.albasani.net

[Julien-Elie]

RFC 8315 has now standardized Cancel-Lock, and a new libcanlock3 library has been released. We have to implement:

• [x] the generation of Cancel-Lock and Cancel-Key header fields in nnrpd, along with a new inn-secrets.conf file to store the secrets;
• [x] the verification of these header fields in innd;
• [x] a generator of cancels (notably for the news administrator, so that he can easily retrieve the key and post cancels in case of abuse).

[evs38]

@Julien-Elie Is it possible to implement IP-based hashes generation to use them when access groups are shared between several people? This allows to cancel messages for users who are not authorized on the server.

[Julien-Elie]

I've implemented addcanlockuser (boolean) in readers.conf access groups that can be set to true (the default, add a user Cancel-Lock hash based on the authenticated username) or false (no user Cancel-Lock hash). I understand your proposal. Would changing addcanlockuser to a string with the following behaviour suit your needs?

• username: the default, add a user Cancel-Lock hash based on the authenticated username
• ip: add a user Cancel-Lock hash based on the IP of the connected client
• none: no user Cancel-Lock hash