idnits 2.17.1 draft-baeuerle-netnews-cancel-lock-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 44 characters in excess of 72. ** The abstract seems to contain references ([RFC5536], [RFC5537]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Implementations of earlier drafts of this specification allowed other values and more liberal (case insensitive) syntax than is allowed in this version. The following values for are now deprecated and SHOULD not be generated anymore. Serving agents SHOULD still accept them for a transition period as long as the corresponding hash function is not considered unsafe. See Section 7 for details. (Using the creation date from RFC5536, updated by this document, for RFC5378 checks: 2004-07-12) -- 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 (March 6, 2017) is 2607 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA' Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Independent Submission M. Baeuerle 3 Internet-Draft STZ Elektronik 4 Updates: 5536,5537 (if approved) March 6, 2017 5 Intended status: Standards Track 6 Expires: September 7, 2017 8 Cancel-Locks in Netnews articles 9 draft-baeuerle-netnews-cancel-lock-00 11 Abstract 13 This document defines an extension to the Netnews Article Format that 14 may be used to authenticate the removal or replacement of existing 15 articles. If approved, this document updates [RFC5536] and 16 [RFC5537]. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 7, 2017. 35 Copyright Notice 37 Copyright (c) 2017 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 54 1.2. Author's Note . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Cancel-Lock . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.2. Cancel-Key . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Adding an initial Cancel-Lock header field to a proto- 60 article . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.2. Extending the Cancel-Lock header field of a proto-article 5 62 3.3. Adding a Cancel-Key header field to a proto-article . . . 5 63 3.4. Check a Cancel-Key header field . . . . . . . . . . . . . 5 64 4. Calculating the key data . . . . . . . . . . . . . . . . . . 6 65 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 6. Obsolete Syntax . . . . . . . . . . . . . . . . . . . . . . . 7 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 71 9.2. Informative References . . . . . . . . . . . . . . . . . 9 72 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 73 Appendix B. Document History (to be removed by RFC Editor before 74 publication) . . . . . . . . . . . . . . . . . . . . 11 75 B.1. Changes since draft-ietf-usefor-cancel-lock-01 . . . . . 11 76 B.2. Changes since draft-ietf-usefor-cancel-lock-00 . . . . . 11 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 79 1. Introduction 81 The authentication system defined in this document is intended to be 82 used as a simple method to verify that the author of an article which 83 removes or replaces another one is either the poster, posting agent, 84 moderator or injecting agent that processed the original article when 85 it was in its proto-article form. 87 One property of this system is that it prevents tracking of 88 individual users. 90 There are other authentication systems available with different 91 properties. When everybody should be able to verify who the 92 originator is (e.g. for control messages to add or remove newsgroups) 93 an OpenPGP signature is suited. 95 1.1. Conventions Used in This Document 97 Any term not defined in this document has the same meaning as it does 98 in [RFC5536] or [RFC5537]. 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 102 "OPTIONAL" in this document are to be interpreted as described in 103 [RFC2119]. 105 1.2. Author's Note 107 Please write the letters "ae" in "Baeuerle" as an a-umlaut (U+00E4, 108 "ä" in XML) and the letters "ue" in Baden-Wuerttemberg as an 109 u-umlaut (U+00FC, "ü" in XML). 111 2. Header Fields 113 This section describes the formal syntax of the new header fields 114 using ABNF [RFC5234]. It extends the syntax in Section 3 of 115 [RFC5536] and non-terminals not defined in this document are defined 116 there. The [RFC5536] ABNF should be imported first before attempting 117 to validate these rules. 119 The new header fields Cancel-Lock and Cancel-Key are defined by this 120 document: 122 fields =/ *( cancel-lock / cancel-key ) 124 Each of these header fields MUST NOT occur more than once in an 125 article. 127 Both new header fields contain lists of encoded values. Every entry 128 is a based on a : 130 scheme = %s"sha-256" / 1*20scheme-char / obs-scheme 131 scheme-char = LOWER / DIGIT / "-" 133 code-string = 1*base64-octet 134 base64-octet = ALPHA / DIGIT / "+" / "/" / "=" 136 The hash algorithms for are defined in [SHA], see also 137 [RFC1321] and [RFC6151] for MD5, [RFC3174] for SHA1 and [RFC6234] for 138 the SHA2 family. The Base64 encoding used is defined in Section 6.8 139 of [RFC2045]. 141 This document defines one value for : "sha-256". This value 142 is mandatory to implement 143 Note that the obsolete syntax was defined case- 144 insensitive. This is changed in this document and the scheme MUST 145 now be generated with lowercase letters. 147 Values for defined in future updates to this document are 148 length limited to 20 characters. This and the case-sensitivity are 149 defined to simplify the checks. 151 2.1. Cancel-Lock 153 cancel-lock = "Cancel-Lock:" SP c-lock *(CFWS c-lock) [CFWS] 154 c-lock = scheme ":" code-string 156 If is not supported by an implementation, the corresponding 157 element MUST be skipped and potential following 158 elements MUST NOT be ignored. 160 The in is the Base64 encoded output of a hash 161 operation (defined by ) of the Base64 encoded key that is 162 intended to authenticate the person or agent that created or 163 processed respectively the article before injection. Because of the 164 one-way nature of the hash operation the key is not revealed. 166 2.2. Cancel-Key 168 cancel-key = "Cancel-Key:" SP c-key *(CFWS c-key) [CFWS] 169 c-key = scheme ":" code-string 171 If is not supported by an implementation, the corresponding 172 element MUST be skipped and potential following 173 elements MUST NOT be ignored. 175 The in is the Base64 encoded key that was used 176 to create the Cancel-Lock header field as defined in Section 2.1 of 177 the original article. 179 3. Use 181 3.1. Adding an initial Cancel-Lock header field to a proto-article 183 A Cancel-Lock header field MAY be added to a proto-article by the 184 poster or posting agent which will include one or more 185 elements. 187 If the poster or posting agent doesn't add a Cancel-Lock header field 188 to an article, then an injecting-agent (or moderator) MAY add one 189 provided that it positively authenticates the author. The injecting- 190 agent (or moderator) MUST NOT add this header to an article unless it 191 is able to authenticate all remove or replace attempts from the 192 poster and automatically add a working Cancel-Key header field for 193 such articles. 195 Other agents MUST NOT add this header to articles or proto-articles 196 that they process. 198 3.2. Extending the Cancel-Lock header field of a proto-article 200 If a Cancel-Lock header field has already been added to a proto- 201 article then any agent (prior to the article being injected) further 202 processing the proto-article (moderators and injecting-agents) MAY 203 append a single element to those already in the header. 205 No more than one element SHOULD be added by each agent that 206 processes the proto-article. 208 Once an article is injected then this header MUST NOT be altered. In 209 particular, relaying agents beyond the injecting agent MUST NOT alter 210 it. 212 3.3. Adding a Cancel-Key header field to a proto-article 214 The Cancel-Key header field MAY be added to a proto-article 215 containing a Control or Supersedes header field by the poster or 216 posting agent which will include one or more elements. They 217 will correspond to some or all of the elements in the 218 article referenced by the Control (with "cancel" command as defined 219 in [RFC5537]) or Supersedes header field. 221 If, as mentioned in Section 3.2 an injecting agent (or moderator) has 222 added a Cancel-Lock header field to an article listed in the Control 223 (with "cancel" command as defined in [RFC5537]) or Supersedes header 224 field then (given that it authenticates the poster as being the same 225 as the poster of the original article) it MUST add (or extend, if 226 already present) the Cancel-Key header field with a element 227 that correspond to those article. 229 Other Agents MUST NOT alter this header. 231 3.4. Check a Cancel-Key header field 233 When a serving agent receives an article that attempts to remove or 234 replace a previous article via Control (with a "cancel" command as 235 defined in [RFC5537]) or Supersedes header field, the system defined 236 in this document can be used for authentication. The general 237 handling of articles containing such attempts as defined in [RFC5537] 238 is not changed by this document. 240 To process the authentication, the received article must contain a 241 Cancel-Key header field and the original article a Cancel-Lock header 242 field. If this is not the case, the authentication is not possible 243 (failed). 245 For the authentication check every supported element from the 246 received article is processed as follows: 248 1. The part of the element is hashed using the 249 algorithm defined by its part. 251 2. For all elements with the same in the original 252 article their part is compared to the calculated 253 hash. 255 3. If one is equal, the authentication is passed and the processing 256 of further elements can be aborted. 258 4. If no match was found and there are no more elements to 259 process, the authentication failed. 261 4. Calculating the key data 263 This section is informative, not normative. 265 It is suggested to use the function HMAC(mid+sec) to create the key 266 for an article with Message-ID , where HMAC is outlined in 267 [RFC2104]. is a secret held locally that can be used for 268 multiple articles. This method removes the need for a per-article 269 database containing the keys used for every article. 271 The local secret should have a length of at least the output 272 size of the hash function that is used by HMAC (32 octets for SHA- 273 256). If the secret is not a random value, but e.g. some sort of 274 human readable password, it should be much longer. In any case it is 275 important that this secret can not be guessed. 277 Note that the hash algorithm used as base for the HMAC operation is 278 not required to be the same as specified by . An agent that 279 verifies a Cancel-Key simply check whether it matches one of the 280 Cancel-Locks. 282 Common libraries like OpenSSL can be used for the cryptographic 283 operations. 285 5. Examples 287 Matching pair of Cancel-Lock and Cancel-Key header fields: 289 Cancel-Lock: sha-256:RrKLp7YCQc9T8HmgSbxwIDlnCDWsgy1awqtiDuhedRo= 290 Cancel-Key: sha-256:sSkDke97Dh78/d+Diu1i3dQ2Fp/EMK3xE2GfEqZlvK8= 292 Legacy variant: 294 Cancel-Lock: sha1:bNXHc6ohSmeHaRHHW56BIWZJt+4= 295 Cancel-Key: ShA1:aaaBBBcccDDDeeeFFF 297 Manual checks using the OpenSSL command line tools in a POSIX shell: 299 $ printf "%s" "sSkDke97Dh78/d+Diu1i3dQ2Fp/EMK3xE2GfEqZlvK8=" | openssl dgst -sha256 -binary | openssl enc -base64 300 RrKLp7YCQc9T8HmgSbxwIDlnCDWsgy1awqtiDuhedRo= 302 $ printf "%s" "aaaBBBcccDDDeeeFFF" | openssl dgst -sha1 -binary | openssl enc -base64 303 bNXHc6ohSmeHaRHHW56BIWZJt+4= 305 6. Obsolete Syntax 307 Implementations of earlier drafts of this specification allowed other 308 values and more liberal (case insensitive) syntax than is 309 allowed in this version. The following values for are now 310 deprecated and SHOULD not be generated anymore. Serving agents 311 SHOULD still accept them for a transition period as long as the 312 corresponding hash function is not considered unsafe. See Section 7 313 for details. 315 obs-scheme = "md5" / "sha1" 317 MUST be parsed case-insensitive. 319 7. Security Considerations 321 The important properties of the hash function used for are 322 the preimage and second preimage resistance. A successful preimage 323 attack would reveal the real Cancel-Key that was used to create the 324 Cancel-Lock of the original article. A successful second preimage 325 attack would allow to create a new, different Cancel-Key that matches 326 a Cancel-Lock too. Both cases would break the authentication system 327 defined in this document. 329 Collision resistance of the hash function used for is less 330 important. Finding two Cancel-Keys that matches an arbitary Cancel- 331 Lock is not helpful to break the authentication system defined in 332 this document (if a specific article is defined as target). Only 333 collateral damage like arbitrary deletion or spam is possible. 335 Currently there are no known practicable preimage and second preimage 336 attacks against the hash functions MD5 and SHA1. Therefore there is 337 no hurry to replace them. The reasons why this document specify 338 SHA-256 (aka SHA2-256) are: 340 o The last draft for the authentication system defined in this 341 document is nearly two decades old. The client side 342 implementations are moving forward extremly slowly too 343 (newsreaders from the last millenium are still in heavy use). 344 What is defined today should be strong enough for at least the 345 next decades. 347 o The collision resistance of MD5 and SHA1 is already broken, 348 therefore they are now obsolete for digital signatures as used in 349 TLS. It is intended that an implementation of the authentication 350 system defined in this document can share the same cryptographic 351 library functions that are used for TLS. 353 o It is intended that the same hash function can be used for 354 and (as base) for the HMAC that is suggested in 355 Section 4. See notes below for HMAC-MD5 and HMAC-SHA1. 357 o The SHA2 family of hash algorithms is widely supported by 358 cryptographic libraries. In contrast, SHA3 is currently not 359 supported by e.g. OpenSSL. 361 The operation HMAC(mid+sec) as suggested in Section 4 must be able to 362 protect the local secret . The Message-ID is public (in 363 the article header). An attacker who wants to steal/use a local 364 secret only need to break this algorithm (regardless of ), 365 because Cancel-Keys are explicitly published for every request to 366 modify or delete existing articles. 368 Even if HMAC-MD5 and HMAC-SHA1 are not considered broken today, it is 369 desired to have some more security margin here. Breaking 370 only allows to authenticate a single forged modify or delete request. 371 With in hand it is possible to forge such requests for all 372 articles that contain Cancel-Locks based on Cancel-Keys generated 373 with this in the past. 375 8. IANA Considerations 377 The Hash Algorithm registry is maintained by IANA. The registry is 378 available at . 381 9. References 383 9.1. Normative References 385 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 386 Extensions (MIME) Part One: Format of Internet Message 387 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 388 . 390 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 391 Requirement Levels", BCP 14, RFC 2119, 392 DOI 10.17487/RFC2119, March 1997, 393 . 395 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 396 Specifications: ABNF", STD 68, RFC 5234, 397 DOI 10.17487/RFC5234, January 2008, 398 . 400 [RFC5536] Murchison, K., Ed., Lindsey, C., and D. Kohn, "Netnews 401 Article Format", RFC 5536, DOI 10.17487/RFC5536, November 402 2009, . 404 [RFC5537] Allbery, R., Ed. and C. Lindsey, "Netnews Architecture and 405 Protocols", RFC 5537, DOI 10.17487/RFC5537, November 2009, 406 . 408 [SHA] National Institute of Standards and Technology, "Secure 409 Hash Standard (SHS)", FIPS 180-4, DOI 10.6028/FIPS.180-4, 410 August 2015, . 413 9.2. Informative References 415 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 416 DOI 10.17487/RFC1321, April 1992, 417 . 419 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 420 Hashing for Message Authentication", RFC 2104, 421 DOI 10.17487/RFC2104, February 1997, 422 . 424 [RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 425 (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001, 426 . 428 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 429 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 430 RFC 6151, DOI 10.17487/RFC6151, March 2011, 431 . 433 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 434 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 435 DOI 10.17487/RFC6234, May 2011, 436 . 438 Appendix A. Acknowledgements 440 The author acknowledges the original author of the Cancel-Lock 441 authentication system as documented in draft-ietf-usefor-cancel-lock: 442 Simon Lyall. 444 He has written the original draft and former version 445 . This 446 document is mostly based on his work and was originally intended as 447 revision 02. It must be renamed because the USEFOR IETF WG is now 448 closed. 450 Appendix B. Document History (to be removed by RFC Editor before 451 publication) 453 B.1. Changes since draft-ietf-usefor-cancel-lock-01 455 o Renamed document because the USEFOR IETF WG is now closed. 457 o Added more details how to check Cancel-Key header fields in 458 Section 3.4. 460 o Added more details to Section 7. 462 o Added updated ABNF for Cancel-Lock and Cancel-Key header fields. 464 o Deprecated "md5" and "sha1" schemes. 466 o Added "sha-256" scheme. 468 o Reworded the abstract section and added references. 470 o Added note to other authentication systems to Section 1. 472 o Added command line check examples to Section 5. 474 B.2. Changes since draft-ietf-usefor-cancel-lock-00 476 o References to SHA-160 changed to SHA1 478 o "scheme" is now a case insensitive token and the number "1" has 479 been changed to "sha1". 481 o Added some examples and fixed the section numbering. 483 o Updated 2nd paragraph on section 2.2 to make clear what exactly is 484 being hashed and how. 486 o Changed paragraph 2 of 3.1 to discourage injection-agents from 487 adding the header. 489 o Removed the Clue-string as this complicated the scheme without 490 adding realistic functionality 492 o Moderators can now add these headers under the same conditions as 493 injection-agents. 495 Author's Address 497 Michael Baeuerle 498 STZ Elektronik 499 Hofener Weg 33C 500 Remseck, Baden-Wuerttemberg 71686 501 Germany 503 Fax: +49 7146 999061 504 EMail: michael.baeuerle@stz-e.de