idnits 2.17.1 draft-baeuerle-netnews-cancel-lock-01.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 : ---------------------------------------------------------------------------- No issues found here. 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: o Changed "SHOULD not" into "SHOULD NOT" in Section 6. (Using the creation date from RFC5536, updated by this document, for RFC5378 checks: 2004-07-12) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 8, 2017) is 2600 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: 0 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 8, 2017 5 Intended status: Standards Track 6 Expires: September 9, 2017 8 Cancel-Locks in Netnews articles 9 draft-baeuerle-netnews-cancel-lock-01 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 RFC5537. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on September 9, 2017. 34 Copyright Notice 36 Copyright (c) 2017 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 This document may contain material from IETF Documents or IETF 50 Contributions published or made publicly available before November 51 10, 2008. The person(s) controlling the copyright in some of this 52 material may not have granted the IETF Trust the right to allow 53 modifications of such material outside the IETF Standards Process. 54 Without obtaining an adequate license from the person(s) controlling 55 the copyright in such materials, this document may not be modified 56 outside the IETF Standards Process, and derivative works of it may 57 not be created outside the IETF Standards Process, except to format 58 it for publication as an RFC or to translate it into languages other 59 than English. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 65 1.2. Author's Note . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2.1. Cancel-Lock . . . . . . . . . . . . . . . . . . . . . . . 4 68 2.2. Cancel-Key . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.1. Adding an initial Cancel-Lock header field to a proto- 71 article . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 3.2. Extending the Cancel-Lock header field of a proto-article 5 73 3.3. Adding a Cancel-Key header field to a proto-article . . . 5 74 3.4. Check a Cancel-Key header field . . . . . . . . . . . . . 6 75 4. Calculating the key data . . . . . . . . . . . . . . . . . . 6 76 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 6. Obsolete Syntax . . . . . . . . . . . . . . . . . . . . . . . 7 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 82 9.2. Informative References . . . . . . . . . . . . . . . . . 10 83 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 84 Appendix B. Document History (to be removed by RFC Editor before 85 publication) . . . . . . . . . . . . . . . . . . . . 11 86 B.1. Changes since -00 . . . . . . . . . . . . . . . . . . . . 11 87 B.2. Changes since draft-ietf-usefor-cancel-lock-01 . . . . . 11 88 B.3. Changes since draft-ietf-usefor-cancel-lock-00 . . . . . 12 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 91 1. Introduction 93 The authentication system defined in this document is intended to be 94 used as a simple method to verify that the author of an article which 95 removes or replaces another one is either the poster, posting agent, 96 moderator or injecting agent that processed the original article when 97 it was in its proto-article form. 99 One property of this system is that it prevents tracking of 100 individual users. 102 There are other authentication systems available with different 103 properties. When everybody should be able to verify who the 104 originator is (e.g. for control messages to add or remove newsgroups) 105 an OpenPGP signature is suited. 107 1.1. Conventions Used in This Document 109 Any term not defined in this document has the same meaning as it does 110 in [RFC5536] or [RFC5537]. 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 114 "OPTIONAL" in this document are to be interpreted as described in 115 [RFC2119]. 117 1.2. Author's Note 119 Please write the letters "ae" in "Baeuerle" as an a-umlaut (U+00E4, 120 "ä" in XML) and the letters "ue" in Baden-Wuerttemberg as an 121 u-umlaut (U+00FC, "ü" in XML). 123 2. Header Fields 125 This section describes the formal syntax of the new header fields 126 using ABNF [RFC5234]. It extends the syntax in Section 3 of 127 [RFC5536] and non-terminals not defined in this document are defined 128 there. The [RFC5536] ABNF should be imported first before attempting 129 to validate these rules. 131 The new header fields Cancel-Lock and Cancel-Key are defined by this 132 document: 134 fields =/ *( cancel-lock / cancel-key ) 136 Each of these header fields MUST NOT occur more than once in an 137 article. 139 Both new header fields contain lists of encoded values. Every entry 140 is a based on a : 142 scheme = %s"sha-256" / 1*scheme-char / obs-scheme 143 scheme-char = LOWER / DIGIT / "-" 145 code-string = 1*base64-octet 146 base64-octet = ALPHA / DIGIT / "+" / "/" / "=" 148 The hash algorithms for are defined in [SHA], see also 149 [RFC1321] and [RFC6151] for MD5, [RFC3174] for SHA1 and [RFC6234] for 150 the SHA2 family. The Base64 encoding used is defined in Section 6.8 151 of [RFC2045]. 153 This document defines one value for : "sha-256". This value 154 is mandatory to implement 156 Note that the obsolete syntax was defined case- 157 insensitive. This is changed in this document and the scheme MUST 158 now be generated with lowercase letters. 160 The case sensitivity of is defined to simplify the checks. 162 2.1. Cancel-Lock 164 cancel-lock = "Cancel-Lock:" SP c-lock *(CFWS c-lock) [CFWS] 165 c-lock = scheme ":" code-string 167 If is not supported by an implementation, the corresponding 168 element MUST be skipped and potential following 169 elements MUST NOT be ignored. 171 The in is the Base64 encoded output of a hash 172 operation (defined by ) of the Base64 encoded key "K" that is 173 intended to authenticate the person or agent that created or 174 processed respectively the article before injection: 176 base64(hash(base64(K))) 178 Because of the one-way nature of the hash operation the key "K" is 179 not revealed. 181 2.2. Cancel-Key 183 cancel-key = "Cancel-Key:" SP c-key *(CFWS c-key) [CFWS] 184 c-key = scheme ":" code-string 186 If is not supported by an implementation, the corresponding 187 element MUST be skipped and potential following 188 elements MUST NOT be ignored. 190 The in is the Base64 encoded key "K" that was 191 used to create the Cancel-Lock header field as defined in Section 2.1 192 of the original article: 194 base64(K) 196 3. Use 198 3.1. Adding an initial Cancel-Lock header field to a proto-article 200 A Cancel-Lock header field MAY be added to a proto-article by the 201 poster or posting agent which will include one or more 202 elements. 204 If the poster or posting agent doesn't add a Cancel-Lock header field 205 to an article, then an injecting-agent (or moderator) MAY add one 206 provided that it positively authenticates the author. The injecting- 207 agent (or moderator) MUST NOT add this header to an article unless it 208 is able to authenticate all remove or replace attempts from the 209 poster and automatically add a working Cancel-Key header field for 210 such articles. 212 Other agents MUST NOT add this header to articles or proto-articles 213 that they process. 215 3.2. Extending the Cancel-Lock header field of a proto-article 217 If a Cancel-Lock header field has already been added to a proto- 218 article then any agent (prior to the article being injected) further 219 processing the proto-article (moderators and injecting-agents) MAY 220 append a single element to those already in the header. 222 No more than one element SHOULD be added by each agent that 223 processes the proto-article. 225 Once an article is injected then this header MUST NOT be altered. In 226 particular, relaying agents beyond the injecting agent MUST NOT alter 227 it. 229 3.3. Adding a Cancel-Key header field to a proto-article 231 The Cancel-Key header field MAY be added to a proto-article 232 containing a Control or Supersedes header field by the poster or 233 posting agent which will include one or more elements. They 234 will correspond to some or all of the elements in the 235 article referenced by the Control (with "cancel" command as defined 236 in [RFC5537]) or Supersedes header field. 238 If, as mentioned in Section 3.2 an injecting agent (or moderator) has 239 added a Cancel-Lock header field to an article listed in the Control 240 (with "cancel" command as defined in [RFC5537]) or Supersedes header 241 field then (given that it authenticates the poster as being the same 242 as the poster of the original article) it MUST add (or extend, if 243 already present) the Cancel-Key header field with a element 244 that correspond to those article. 246 Other Agents MUST NOT alter this header. 248 3.4. Check a Cancel-Key header field 250 When a serving agent receives an article that attempts to remove or 251 replace a previous article via Control (with a "cancel" command as 252 defined in [RFC5537]) or Supersedes header field, the system defined 253 in this document can be used for authentication. The general 254 handling of articles containing such attempts as defined in [RFC5537] 255 is not changed by this document. 257 To process the authentication, the received article must contain a 258 Cancel-Key header field and the original article a Cancel-Lock header 259 field. If this is not the case, the authentication is not possible 260 (failed). 262 For the authentication check every supported element from the 263 received article is processed as follows: 265 1. The part of the element is hashed using the 266 algorithm defined by its part. 268 2. For all elements with the same in the original 269 article their part is compared to the calculated 270 hash. 272 3. If one is equal, the authentication is passed and the processing 273 of further elements can be aborted. 275 4. If no match was found and there are no more elements to 276 process, the authentication failed. 278 4. Calculating the key data 280 This section is informative, not normative. 282 It is suggested to use the function HMAC(mid+sec) to create the key 283 for an article with Message-ID , where HMAC is outlined in 284 [RFC2104]. is a secret held locally that can be used for 285 multiple articles. This method removes the need for a per-article 286 database containing the keys used for every article. 288 The local secret should have a length of at least the output 289 size of the hash function that is used by HMAC (32 octets for SHA- 290 256). If the secret is not a random value, but e.g. some sort of 291 human readable password, it should be much longer. In any case it is 292 important that this secret can not be guessed. 294 Note that the hash algorithm used as base for the HMAC operation is 295 not required to be the same as specified by . An agent that 296 verifies a Cancel-Key simply check whether it matches one of the 297 Cancel-Locks. 299 Common libraries like OpenSSL can be used for the cryptographic 300 operations. 302 5. Examples 304 Matching pair of Cancel-Lock and Cancel-Key header fields: 306 Cancel-Lock: sha-256:RrKLp7YCQc9T8HmgSbxwIDlnCDWsgy1awqtiDuhedRo= 307 Cancel-Key: sha-256:sSkDke97Dh78/d+Diu1i3dQ2Fp/EMK3xE2GfEqZlvK8= 309 Legacy variant: 311 Cancel-Lock: sha1:bNXHc6ohSmeHaRHHW56BIWZJt+4= 312 Cancel-Key: ShA1:aaaBBBcccDDDeeeFFF 314 Manual checks using the OpenSSL command line tools in a POSIX shell: 316 $ printf "%s" "sSkDke97Dh78/d+Diu1i3dQ2Fp/EMK3xE2GfEqZlvK8=" \ 317 | openssl dgst -sha256 -binary \ 318 | openssl enc -base64 319 RrKLp7YCQc9T8HmgSbxwIDlnCDWsgy1awqtiDuhedRo= 321 $ printf "%s" "aaaBBBcccDDDeeeFFF" \ 322 | openssl dgst -sha1 -binary \ 323 | openssl enc -base64 324 bNXHc6ohSmeHaRHHW56BIWZJt+4= 326 6. Obsolete Syntax 328 Implementations of earlier drafts of this specification allowed other 329 values and more liberal (case insensitive) syntax than is 330 allowed in this version. The following values for are now 331 deprecated and SHOULD NOT be generated anymore. Serving agents 332 SHOULD still accept them for a transition period as long as the 333 corresponding hash function is not considered unsafe. See Section 7 334 for details. 336 obs-scheme = "sha1" 338 MUST be parsed case-insensitive. 340 It is important for backward compatibility that the deprecated values 341 for are not phased out too early. Security and 342 compatibility concerns should be carefully weighed before choosing to 343 remove deprecated s from existing implementations (or not 344 implementing them in new ones). 346 7. Security Considerations 348 The important properties of the hash function used for are 349 the preimage and second preimage resistance. A successful preimage 350 attack would reveal the real Cancel-Key that was used to create the 351 Cancel-Lock of the original article. A successful second preimage 352 attack would allow to create a new, different Cancel-Key that matches 353 a Cancel-Lock too. Both cases would break the authentication system 354 defined in this document. 356 Collision resistance of the hash function used for is less 357 important. Finding two Cancel-Keys that matches an arbitary Cancel- 358 Lock is not helpful to break the authentication system defined in 359 this document (if a specific article is defined as target). Only 360 collateral damage like arbitrary deletion or spam is possible. 362 Currently there are no known practicable preimage and second preimage 363 attacks against the hash functions MD5 and SHA1. Therefore there is 364 no hurry to replace them. The reasons why this document specify 365 SHA-256 (aka SHA2-256) are: 367 o The last draft for the authentication system defined in this 368 document is nearly two decades old. The client side 369 implementations are moving forward extremly slowly too 370 (newsreaders from the last millenium are still in heavy use). 371 What is defined today should be strong enough for at least the 372 next decades. 374 o The collision resistance of MD5 and SHA1 is already broken, 375 therefore they are now obsolete for digital signatures as used in 376 TLS. It is intended that an implementation of the authentication 377 system defined in this document can share the same cryptographic 378 library functions that are used for TLS. 380 o It is intended that the same hash function can be used for 381 and (as base) for the HMAC that is suggested in 382 Section 4. See notes below for HMAC-MD5 and HMAC-SHA1. 384 o The SHA2 family of hash algorithms is widely supported by 385 cryptographic libraries. In contrast, SHA3 is currently not 386 supported by e.g. OpenSSL. 388 The operation HMAC(mid+sec) as suggested in Section 4 must be able to 389 protect the local secret . The Message-ID is public (in 390 the article header). An attacker who wants to steal/use a local 391 secret only need to break this algorithm (regardless of ), 392 because Cancel-Keys are explicitly published for every request to 393 modify or delete existing articles. 395 Even if HMAC-MD5 and HMAC-SHA1 are not considered broken today, it is 396 desired to have some more security margin here. Breaking 397 only allows to authenticate a single forged modify or delete request. 398 With in hand it is possible to forge such requests for all 399 articles that contain Cancel-Locks based on Cancel-Keys generated 400 with this in the past. 402 8. IANA Considerations 404 The Hash Algorithm registry is maintained by IANA. The registry is 405 available at . 408 9. References 410 9.1. Normative References 412 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 413 Extensions (MIME) Part One: Format of Internet Message 414 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 415 . 417 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 418 Requirement Levels", BCP 14, RFC 2119, 419 DOI 10.17487/RFC2119, March 1997, 420 . 422 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 423 Specifications: ABNF", STD 68, RFC 5234, 424 DOI 10.17487/RFC5234, January 2008, 425 . 427 [RFC5536] Murchison, K., Ed., Lindsey, C., and D. Kohn, "Netnews 428 Article Format", RFC 5536, DOI 10.17487/RFC5536, November 429 2009, . 431 [RFC5537] Allbery, R., Ed. and C. Lindsey, "Netnews Architecture and 432 Protocols", RFC 5537, DOI 10.17487/RFC5537, November 2009, 433 . 435 [SHA] National Institute of Standards and Technology, "Secure 436 Hash Standard (SHS)", FIPS 180-4, DOI 10.6028/FIPS.180-4, 437 August 2015, . 440 9.2. Informative References 442 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 443 DOI 10.17487/RFC1321, April 1992, 444 . 446 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 447 Hashing for Message Authentication", RFC 2104, 448 DOI 10.17487/RFC2104, February 1997, 449 . 451 [RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 452 (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001, 453 . 455 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 456 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 457 RFC 6151, DOI 10.17487/RFC6151, March 2011, 458 . 460 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 461 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 462 DOI 10.17487/RFC6234, May 2011, 463 . 465 Appendix A. Acknowledgements 467 The author acknowledges the original author of the Cancel-Lock 468 authentication system as documented in draft-ietf-usefor-cancel-lock: 469 Simon Lyall. He has written the original draft and former version 470 . This 471 document is mostly based on his work and was originally intended as 472 revision 02. It must be renamed because the USEFOR IETF WG is now 473 closed. 475 The author would like to thank the following individuals for 476 contributing their ideas and reviewing this specification: Richard 477 Kettlewell, Holger Marzen. And Peter Faust and Alfred Peters for 478 providing statistic data about the algorithms currently in use. 480 Appendix B. Document History (to be removed by RFC Editor before 481 publication) 483 B.1. Changes since -00 485 o Added additional note that deprecated "scheme" values should be 486 preserved for backward compatibility as long as reasonable. 488 o Removed deprectated scheme "md5" (not in use anymore). 490 o Added descriptions how to generate "code-string" to Section 2.1 491 and Section 2.2. 493 o Removed length limitiation in ABNF of "scheme". 495 o Changed copyright notice to use text from TLP section 6.c.iii. 497 o Removed references from "abstract" section. 499 o Changed "SHOULD not" into "SHOULD NOT" in Section 6. 501 o Added line wraps to CLI commands in Section 5. 503 B.2. Changes since draft-ietf-usefor-cancel-lock-01 505 o Renamed document because the USEFOR IETF WG is now closed. 507 o Added more details how to check Cancel-Key header fields in 508 Section 3.4. 510 o Added more details to Section 7. 512 o Added updated ABNF for Cancel-Lock and Cancel-Key header fields. 514 o Deprecated "md5" and "sha1" schemes. 516 o Added "sha-256" scheme. 518 o Reworded the abstract section and added references. 520 o Added note to other authentication systems to Section 1. 522 o Added command line check examples to Section 5. 524 B.3. Changes since draft-ietf-usefor-cancel-lock-00 526 o References to SHA-160 changed to SHA1 528 o "scheme" is now a case insensitive token and the number "1" has 529 been changed to "sha1". 531 o Added some examples and fixed the section numbering. 533 o Updated 2nd paragraph on section 2.2 to make clear what exactly is 534 being hashed and how. 536 o Changed paragraph 2 of 3.1 to discourage injection-agents from 537 adding the header. 539 o Removed the Clue-string as this complicated the scheme without 540 adding realistic functionality 542 o Moderators can now add these headers under the same conditions as 543 injection-agents. 545 Author's Address 547 Michael Baeuerle 548 STZ Elektronik 549 Hofener Weg 33C 550 Remseck, Baden-Wuerttemberg 71686 551 Germany 553 Fax: +49 7146 999061 554 EMail: michael.baeuerle@stz-e.de