USEFOR Working Group S. Lyall INTERNET-DRAFT September 1998 Expires March 1999 Cancel-Locks in Usenet articles. draft-ietf-usefor-cancel-lock-01.txt Status of this memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document outlines a method that may be used by authors of successor (or canceling) articles to authenticate their authorship of the original article. As a proto-article article passes through various agents they may include the hash of a secret string in a Cancel-Key header. Later if they wish to use a standard mechanism to remove the original article (eg Cancel or Supersede) they can include this string in the Cancel-Lock header to verify that they are entitled to perform this operation. Familiarity with the current News Article Format draft [ARTICLE] is assumed. 1. Introduction: The Cancel-Key & Cancel-Lock headers These two headers MAY be used by posters, posting agents, moderators and injecting agents in order to mark articles they process and to verify canceling , superseding and replacing articles they may subsequently be issued for those originals. They MUST NOT be altered or created by any other agents. The scheme works by included a "Cancel-Lock: " header and contents in an article. Further articles that wish to cancel, supersede or replace this article are required to include a "Cancel-Key: " header which contains a code-string that when hashed yields one of the code-strings in the "Cancel-Lock: " header of the original article. These headers are intended to be used as a simple method to verify that the author of a article which removes another one is either the poster, posting agent, moderator or injecting agent that processed the original article when it was in its proto-article form. 2. Format Cancel-Lock-content = [CFWS] cancel-lock *( CFWS cancel-lock ) [CFWS] Cancel-Key-content = [CFWS] cancel-key *( CFWS cancel-key ) [CFWS] cancel-lock = scheme ":" code-string cancel-key = scheme ":" code-string [ ":" clue-string ] scheme = 1*base64-octet code-string = 1*base64-octet clue-string = 2base64-octet base64-octet = ALPHA / DIGIT / "+" / "/" / "=" 2.1 The "scheme" element The scheme is the format that is used to encode the code-string. This document only defines the scheme of "SHA1" which corresponds to the SHA1 algorithm [SHA1]. Other schemes MAY be defined by further IETF standards. 2.2 The "code-string" element The code-string is a series of base-64-octets. The code-string in a cancel-lock is the hash of the corresponding code-string in a cancel-key. The encoding of the binary key or lock is performed in accordance with the Base64 Transfer Encoding defined in [RFC-2045]. Under Scheme "sha1" the code-string element of a cancel-lock is the output of a hash operation (using the SHA1 algorithm) performed on the code-string of the cancel-key. 2.3 The "clue-string" element The clue-string is an optional element that MAY be included in a cancel-key. It consists of the first two base64-octets of the code-string of the cancel-lock to which the cancel-key corresponds. The clue-string is intended the reduce searching time where multiple cancel-lock's may be referred to by a single cancel-key. 3. Use When an serving agent receives an article that attempts to remove a previous article via Cancel, Supersedes or Replaces, then if the original article contains a valid cancel-lock the replacing article MUST contain a valid cancel-key (or keys) that corresponds to at least one of the cancel-lock's in the original article. 3.1 Adding an initial "Cancel-Lock: " header to a proto-article A Cancel-Lock header MAY be added to a proto-article by the poster or posting agent which will include one or more cancel-locks in its Cancel-Lock-content. If the poster or posting agent does not add a Cancel-Lock header to an article then an injecting-agent MAY add one provided that it positively authenticates the author. The injecting-agent MUST NOT add this header to an article unless it is able to authenticate all cancels, replaces and supersedes from the poster and automatically add the correct Cancel-Key header (and content) for such articles. Other agents MUST NOT add this header to articles or proto-articles that they process. 3.2 Extending the "Cancel-Lock: " header of a proto-article If a "Cancel-Lock: " header has already been added to a proto-article then any agent (prior to the article being injected) further processing the proto-article MAY append a single cancel-lock to those already in the header. No more than one cancel-lock SHOULD be added by each agent that processes the proto-article. Once an article in injected then this header MUST NOT be altered. In particular, relaying agents beyond the injecting agent MUST NOT alter it. 3.3 Adding a "Cancel-Key: " header to a proto-article. The Cancel-Key header MAY be added to a proto-article containing a "Cancel: ", "Replaces: " or "Supersedes: " header by the poster or posting agent which will include one or more cancel-keys in its Cancel-Key-content. These cancel-keys will correspond to some or all of the cancel-locks in articles listed in the "Cancel: " , "Replaces: " and "Supersedes: " headers. If, as mentioned in 3.1 an injecting agent has added a "Cancel-Lock: " header to an article listed in the "Cancel: " , "Replaces: " or "Supersedes: " headers then (assuming it authenticates the poster as being the same as the poster or the original article(s) ) it MUST add a "Cancel-Key: " header with the cancel-key(s) that correspond to those article(s). Other Agents MUST NOT alter this header. 4. Creating the cancel-lock It is suggested that when creating a cancel-lock the function HMAC(message-id+secret) be used, where HMAC is outlined in [HMAC], message-id is the message-id of the article and secret is a secret key held locally. This method removes the need for a per-article database containing the cancel-lock used with every article. 5. Security Issues General security issues with hash functions are discussed elsewhere, see the references in [HMAC] for some pointers. The method outlined in Section 4 is also vulnerable to the secret key being compromised or guessed. 6. Examples The following are Cancel-Lock headers along with a Cancel-Key header that matches them: Cancel-Lock: sha1:bNXHc6ohSmeHaRHHW56BIWZJt+4= Cancel-Key: sha1:aaaBBBcccDDDeeeFFF Cancel-Lock: SHA1:H7/zsCUemvbvSDyARDaMs6AQu5s= Cancel-Key: sha1:chW8hNeDx3iNUsGBU6/ezDk88P4= sha1:4srkWaRIzvK51ArAP:Hc Cancel-Lock: sha1:JyEBL4w9/abCBuzCxMIE/E73GM4= sha1:2Bmg+zWaY1noRiCdy8k3IapwSDU= Cancel-Key: sha1:K4rkWRjRcXmIzvK51ArAP:Jy 7. References [ARTICLE] News Article Format. D Ritter. Internet Draft draft-ietf-usefor-article-01 . 1998. [HMAC] Keyed-Hashing for Message Authentication. H. Krawczyk, M. Bellare, R. Canetti. February 1997. RFC 2104. [SHA1] NIST, FIPS PUB 180-1: Secure Hash Standard, Apr 1995. [RFC-2045] MIME, part 1 Freed, Ned; Borenstein, Nathaniel S.: Multipurpose Internet mail extensions (MIME), part 1: format of Internet message bodies. RFC 2045, Nov 1996. 8. Author's Address Simon Lyall PO Box 6616, Auckland, New Zealand. Phone: +64 9 358 5067 ext 701 Email: simon@darkmere.gen.nz -- Simon J. Lyall. | Very Busy | Mail: simon@darkmere.gen.nz "To stay awake all night adds a day to your life" - Stilgar | MT.