idnits 2.17.1 draft-ietf-usefor-cancel-lock-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 251 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 14 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([ARTICLE]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 46: '...hese two headers MAY be used by poster...' RFC 2119 keyword, line 49: '... originals. They MUST NOT be altered o...' RFC 2119 keyword, line 77: '...SHA1 algorithm [SHA1]. Other schemes MAY be defined by further IETF...' RFC 2119 keyword, line 98: '...k the replacing article MUST contain a...' RFC 2119 keyword, line 104: '...ncel-Lock header MAY be added to a pro...' (10 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 1999) is 9113 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'CFWS' is mentioned on line 66, but not defined == Outdated reference: A later version (-13) exists of draft-ietf-usefor-article-01 -- Possible downref: Normative reference to a draft: ref. 'ARTICLE' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA1' Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 USEFOR Working Group S. Lyall 3 INTERNET-DRAFT November 1998 4 Expires May 1999 6 Cancel-Locks in Usenet articles. 7 draft-ietf-usefor-cancel-lock-01.txt 9 Status of this memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet-Drafts 19 as reference material or to cite them other than as "work in 20 progress." 22 To view the entire list of current Internet-Drafts, please check 23 the "1id-abstracts.txt" listing contained in the Internet-Drafts 24 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 25 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 26 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 27 (US West Coast). 29 Abstract 31 This document outlines a method that may be used by authors of successor 32 (or canceling) articles to authenticate their authorship of the original 33 article. 35 As a proto-article article passes through various agents they may include 36 the hash of a secret string in a Cancel-Key header. Later if they wish to 37 use a standard mechanism to remove the original article (eg Cancel or 38 Supersede) they can include this string in the Cancel-Lock header to 39 verify that they are entitled to perform this operation. 41 Familiarity with the current News Article Format draft [ARTICLE] is 42 assumed. 44 1. Introduction: The Cancel-Key & Cancel-Lock headers 46 These two headers MAY be used by posters, posting agents, moderators and 47 injecting agents in order to mark articles they process and to verify 48 canceling, superseding and replacing articles that may subsequently be 49 issued for those originals. They MUST NOT be altered or created by any 50 other agents. 52 The scheme works by including a "Cancel-Lock: " header and contents in an 53 article. Further articles that wish to cancel, supersede or replace this 54 article can include a "Cancel-Key: " header which contains a code-string 55 that when hashed yields one of the code-strings in the "Cancel-Lock: " 56 header of the original article. 58 These headers are intended to be used as a simple method to verify that 59 the author of an article which removes another one is either the poster, 60 posting agent, moderator or injecting agent that processed the original 61 article when it was in its proto-article form. 63 2. Format 65 Cancel-Lock-content = cancel-lock *( CFWS cancel-lock ) [CFWS] 66 Cancel-Key-content = cancel-key *( CFWS cancel-key ) [CFWS] 67 cancel-lock = scheme ":" code-string 68 cancel-key = scheme ":" code-string 69 scheme = token 70 code-string = 1*base64-octet 71 base64-octet = ALPHA / DIGIT / "+" / "/" / "=" 73 2.1 The "scheme" element 75 The scheme is the format that is used to encode the code-string. This 76 document only defines the scheme of "SHA1" which corresponds to the 77 SHA1 algorithm [SHA1]. Other schemes MAY be defined by further IETF 78 standards. This element is case insensitive. 80 2.2 The "code-string" element 82 The code-string is a series of base-64-octets. The code-string in a 83 cancel-lock is the hash of the corresponding code-string in a cancel-key. 84 The encoding of the binary key or lock is performed in accordance with 85 the Base64 Transfer Encoding defined in [RFC-2045]. 87 Under scheme "sha1" the code-string element of a cancel-lock is the 88 output of a hash operation (using the SHA1 algorithm) performed on the 89 code-string of the cancel-key. 91 3. Use 93 In order for an article removal to be allowed under the Cancel-Lock method 94 the following takes place: 96 When a serving agent receives an article that attempts to remove a 97 previous article via Cancel, Supersedes or Replaces, then if the original 98 article contains a valid cancel-lock the replacing article MUST contain a 99 valid cancel-key (or keys) that corresponds to at least one of the 100 cancel-lock's in the original article. 102 3.1 Adding an initial "Cancel-Lock: " header to a proto-article 104 A Cancel-Lock header MAY be added to a proto-article by the poster 105 or posting agent which will include one or more cancel-locks in its 106 Cancel-Lock-content. 108 If the poster or posting agent does not add a Cancel-Lock header to an 109 article then an injecting-agent (or moderator) MAY add one provided that 110 it positively authenticates the author. The injecting-agent (or 111 moderator) MUST NOT add this header to an article unless it is able to 112 authenticate all cancels, replaces and supersedes from the poster and 113 automatically add the correct Cancel-Key header (and content) for such 114 articles. 116 Other agents MUST NOT add this header to articles or proto-articles that 117 they process. 119 3.2 Extending the "Cancel-Lock: " header of a proto-article 121 If a "Cancel-Lock: " header has already been added to a proto-article 122 then any agent (prior to the article being injected) further processing 123 the proto-article (ie moderators and injection-agents) MAY append a single 124 cancel-lock to those already in the header. 126 No more than one cancel-lock SHOULD be added by each agent that 127 processes the proto-article. 129 Once an article is injected then this header MUST NOT be altered. In 130 particular, relaying agents beyond the injecting agent MUST NOT alter it. 132 3.3 Adding a "Cancel-Key: " header to a proto-article. 134 The Cancel-Key header MAY be added to a proto-article containing a 135 "Cancel: ", "Replaces: " or "Supersedes: " header by the poster 136 or posting agent which will include one or more cancel-keys in its 137 Cancel-Key-content. These cancel-keys will correspond to some or all of 138 the cancel-locks in articles listed in the "Cancel: " , "Replaces: " and 139 "Supersedes: " headers. 141 If, as mentioned in 3.1 an injecting agent (or moderator) has added a 142 "Cancel-Lock: " header to an article listed in the "Cancel: " , "Replaces: 143 " or "Supersedes: " headers then (assuming it authenticates the poster as 144 being the same as the poster of the original article(s) ) it MUST add a 145 "Cancel-Key: " header with the cancel-key(s) that correspond to those 146 article(s). 148 Other Agents MUST NOT alter this header. 150 4. Creating the cancel-lock 152 It is suggested that when creating a cancel-lock the function 153 HMAC(message-id+secret) be used, where HMAC is outlined in [HMAC], 154 message-id is the message-id of the article and secret is a secret key 155 held locally. 157 This method removes the need for a per-article database containing the 158 cancel-lock used with every article. 160 5. Security Issues 162 General security issues with hash functions are discussed elsewhere, see 163 the references in [HMAC] for some pointers. The method outlined in 164 Section 4 is also vulnerable to the secret key being compromised or 165 guessed. 167 6. Examples 169 The following are Cancel-Lock headers along with a Cancel-Key header 170 that matches them: 172 Cancel-Lock: sha1:bNXHc6ohSmeHaRHHW56BIWZJt+4= 173 Cancel-Key: sha1:aaaBBBcccDDDeeeFFF 175 Cancel-Lock: SHA1:H7/zsCUemvbvSDyARDaMs6AQu5s= 176 Cancel-Key: sha1:chW8hNeDx3iNUsGBU6/ezDk88P4= sha1:4srkWaRIzvK51ArAP 178 Cancel-Lock: sha1:JyEBL4w9/abCBuzCxMIE/E73GM4= 179 sha1:2Bmg+zWaY1noRiCdy8k3IapwSDU= 180 Cancel-Key: sha1:K4rkWRjRcXmIzvK51ArAP 182 7. References 184 [ARTICLE] News Article Format. D Ritter. Internet Draft 185 draft-ietf-usefor-article-01 . 1998. 187 [HMAC] Keyed-Hashing for Message Authentication. H. Krawczyk, M. 188 Bellare, R. Canetti. February 1997. RFC 2104. 190 [SHA1] NIST, FIPS PUB 180-1: Secure Hash Standard, Apr 1995. 192 [RFC-2045] MIME, part 1 Freed, Ned; Borenstein, Nathaniel S.: 193 Multipurpose Internet mail extensions (MIME), part 1: format of 194 Internet message bodies. RFC 2045, Nov 1996. 196 8. Changes from previous draft. 198 - References to SHA-160 changed to SHA1 200 - "scheme" is now a case insensitive token and the number "1" has been 201 changed to "sha1". 203 - Added some examples and fixed the section numbering. 205 - Updated 2nd paragraph on section 2.2 to make clear what exactly is 206 being hashed and how. 208 - Changed paragraph 2 of 3.1 to discourage injection-agents from adding 209 the header. 211 - Removed the Clue-string as this complicated the scheme without adding 212 realistic functionality 214 - moderators can now add these headers under the same conditions as 215 injection-agents. 217 9. Author's Address 219 Simon Lyall 220 PO Box 6616, 221 Auckland, 222 New Zealand. 224 Phone: +64 9 358 5067 ext 701 225 Email: simon@darkmere.gen.nz