idnits 2.17.1 draft-ietf-usefor-cancel-lock-00.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-19) 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 215 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 13 instances of too long lines in the document, the longest one being 4 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 78: '...SHA algorithm [SHA-160]. Other schemes MAY be defined by further IETF...' RFC 2119 keyword, line 93: '...onal element that MAY be included in a...' RFC 2119 keyword, line 104: '...k the replacing article MUST contain a...' (10 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 142 has weird spacing: '...the cancel-l...' -- 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 (February 1999) is 9195 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. 'SHA-160' Summary: 12 errors (**), 0 flaws (~~), 5 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 August 1998 4 Expires February 1999 6 Cancel-Locks in Usenet articles. 7 draft-ietf-usefor-cancel-lock-00.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 pre-injected 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 they 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 included a "Cancel-Lock: " header and contents in an 53 article. Further articles that wish to cancel, supersede or replace this 54 article are required to include a "Cancel-Key: " header which contains 55 a code-string that when hashed yields one of the code-strings in the 56 "Cancel-Lock: " header of the original article. 58 These headers are intended to be used as a simple method to verify that 59 the author of a 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 = [CFWS] cancel-lock *( CFWS cancel-lock ) [CFWS] 66 Cancel-Key-content = [CFWS] cancel-key *( CFWS cancel-key ) [CFWS] 67 cancel-lock = scheme ":" code-string 68 cancel-key = scheme ":" code-string [ ":" clue-string ] 69 scheme = 1*DIGIT 70 code-string = 1*base64-octet 71 clue-string = 2base64-octet 72 base64-octet = ALPHA / DIGIT / "+" / "/" / "=" 74 2.1 The "scheme" element 76 The scheme is the format that is used to encode the code-string. This 77 document only defines the scheme of "1" which corresponds to the 78 SHA algorithm [SHA-160]. Other schemes MAY be defined by further IETF 79 standards. 81 2.2 The "code-string" element 83 The code-string is a series of base-64-octets. The code-string in a 84 cancel-lock is the hash of the corresponding code-string in a cancel-key. 85 The encoding of the binary key or lock is performed in accordance with the 86 Base64 Transfer Encoding defined in [RFC-2045]. 88 Under Scheme 1 the code-string element of a cancel-lock is the output hash 89 of the SHA algorithm. 91 2.3 The "clue-string" element 93 The clue-string is an optional element that MAY be included in a 94 cancel-key. It consists of the first two base64-octets of the code-string 95 of the cancel-lock to which the cancel-key corresponds. 97 The clue-string is intended the reduce searching time where multiple 98 cancel-lock's may be referred to by a single cancel-key. 100 3. Use 102 When an serving agent receives an article that attempts to remove a 103 previous article via Cancel, Supersedes or Replaces, then if the original 104 article contains a valid cancel-lock the replacing article MUST contain a 105 valid cancel-key (or keys) that corresponds to one (or more) of the 106 cancel-lock's in the original article. 108 3.1 Adding an initial "Cancel-Lock: " header to a proto-article 110 A Cancel-Lock header MAY be added to a proto-article by the poster 111 or posting agent which will include one or more cancel-locks in its 112 Cancel-Lock-content. 114 If the poster or posting agent does not add a Cancel-Lock header to an 115 article then an injecting-agent MAY add one provided that it 116 positively authenticates the author. However this practice is NOT 117 recommended since the poster will be unable to create a cancel-key to 118 remove the article later without the co-operation of the injecting agent. 120 Other agents MUST NOT add this header to articles or proto-articles that 121 they process. 123 3.2 Extending the "Cancel-Lock: " header of a proto-article 125 If a "Cancel-Lock: " header has already been added to a proto-article then 126 any agent (prior to the article being injected) further processing the 127 proto-article MAY append a single cancel-lock to those already in the 128 header. 130 No more than one cancel-lock SHOULD be added by each agent that 131 processes the proto-article. 133 Once an article in injected then this header MUST NOT be altered. In 134 particular, relaying agents beyond the injecting agent MUST NOT alter it. 136 3.3 Adding a "Cancel-Key: " header to a proto-article. 138 The Cancel-Key header MAY be added to a proto-article containing a 139 "Cancel: ", "Replaces: " or "Supersedes: " header by the poster 140 or posting agent which will include one or more cancel-keys in its 141 Cancel-Key-content. These cancel-keys will correspond to some or all of 142 the cancel-locks in articles listed in the "Cancel: " , "Replaces: " 143 and "Supersedes: " headers. 145 If, as mentioned in 3.1 an injecting agent has added a "Cancel-Lock: " 146 header to an article listed in the "Cancel: " , "Replaces: " or 147 "Supersedes: " headers then (assuming it authenticates the poster as being 148 the same as the poster or the original article(s) ) it MUST add a 149 "Cancel-Key: " header with the cancel-key(s) that correspond to those 150 article(s). 152 Other Agents MUST NOT alter this header. 154 4. Creating the cancel-lock 156 It is suggested that when creating a cancel-lock the function 157 HMAC(message-id+secret) be used, where HMAC is outlined in [HMAC], 158 message-id is the message-id of the article and secret is a secret key 159 held locally. 161 This method removes the need for a per-article database containing the 162 cancel-lock used with every article.. 164 5. Security Issues 166 General security issues with hash functions are discussed elsewhere, see the 167 references in [HMAC] for some pointers. The method outlined in Section 4 168 is also vulnerable to the secret key being compromised or guessed. 170 5. References 172 [ARTICLE] News Article Format. D Ritter. Internet Draft 173 draft-ietf-usefor-article-01 . 1998. 175 [HMAC] Keyed-Hashing for Message Authentication. H. Krawczyk, M. 176 Bellare, R. Canetti. February 1997. RFC 2104. 178 [SHA-160] NIST, FIPS PUB 180-1: Secure Hash Standard, Apr 1995. 180 [RFC-2045] MIME, part 1 Freed, Ned; Borenstein, Nathaniel S.: 181 Multipurpose Internet mail extensions (MIME), part 1: format of 182 Internet message bodies. RFC 2045, Nov 1996. 184 6. Author's Address 186 Simon Lyall, 187 PO Box 6616, 188 Auckland, 189 New Zealand. 191 Phone: +64 9 358 5067 ext 701 192 Email: simon@darkmere.gen.nz