idnits 2.17.1 draft-baeuerle-netnews-cancel-lock-08.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 the creation date from RFC5537, updated by this document, for RFC5378 checks: 2004-08-31) -- 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 (November 20, 2017) is 2349 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) ** Downref: Normative reference to an Informational RFC: RFC 6234 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 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: 5537 (if approved) November 20, 2017 5 Intended status: Standards Track 6 Expires: May 24, 2018 8 Cancel-Locks in Netnews articles 9 draft-baeuerle-netnews-cancel-lock-08 11 Abstract 13 This document defines an extension to the Netnews Article Format that 14 may be used to authenticate the cancelling and superseding of 15 existing articles. If approved, this document updates 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 https://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 May 24, 2018. 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 (https://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 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 53 1.2. Author's Note . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Cancel-Lock . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.2. Cancel-Key . . . . . . . . . . . . . . . . . . . . . . . 5 57 3. Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3.1. Adding an initial Cancel-Lock header field to a proto- 59 article . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 3.2. Extending the Cancel-Lock header field of a proto-article 6 61 3.3. Adding a Cancel-Key header field to a proto-article . . . 7 62 3.4. Extending the Cancel-Key header field of a proto-article 7 63 3.5. Check a Cancel-Key header field . . . . . . . . . . . . . 7 64 4. Calculating the key data . . . . . . . . . . . . . . . . . . 8 65 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 5.1. Without UID . . . . . . . . . . . . . . . . . . . . . . . 9 67 5.2. With UID . . . . . . . . . . . . . . . . . . . . . . . . 10 68 5.3. Other examples . . . . . . . . . . . . . . . . . . . . . 11 69 5.4. Manual checks . . . . . . . . . . . . . . . . . . . . . . 11 70 6. Obsolete Syntax . . . . . . . . . . . . . . . . . . . . . . . 12 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 73 8.1. Algorithm Name Registration Procedure . . . . . . . . . . 15 74 8.2. Change control . . . . . . . . . . . . . . . . . . . . . 16 75 8.3. Registration of the Netnews Cancel-Lock hash algorithms . 16 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 77 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 78 9.2. Informative References . . . . . . . . . . . . . . . . . 18 79 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 20 80 Appendix B. Document History (to be removed by RFC Editor before 81 publication) . . . . . . . . . . . . . . . . . . . . 20 82 B.1. Changes since -07 . . . . . . . . . . . . . . . . . . . . 20 83 B.2. Changes since -06 . . . . . . . . . . . . . . . . . . . . 20 84 B.3. Changes since -05 . . . . . . . . . . . . . . . . . . . . 21 85 B.4. Changes since -04 . . . . . . . . . . . . . . . . . . . . 22 86 B.5. Changes since -03 . . . . . . . . . . . . . . . . . . . . 23 87 B.6. Changes since -02 . . . . . . . . . . . . . . . . . . . . 23 88 B.7. Changes since -01 . . . . . . . . . . . . . . . . . . . . 24 89 B.8. Changes since -00 . . . . . . . . . . . . . . . . . . . . 25 90 B.9. Changes since draft-ietf-usefor-cancel-lock-01 . . . . . 26 91 B.10. Changes since draft-ietf-usefor-cancel-lock-00 . . . . . 26 92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27 94 1. Introduction 96 The authentication system defined in this document is intended to be 97 used as a simple method to verify that the withdrawal of an article 98 is valid, that is to say either the poster, posting agent, moderator 99 or injecting agent that processed the original article has requested 100 to withdraw it via the use of a cancel control article ([RFC5537] 101 Section 5.3) or a Supersedes header field ([RFC5537] Section 5.4). 103 This document defines two new header fields: Cancel-Lock and Cancel- 104 Key. The Cancel-Lock header field contains hashes of secret data. 105 The preimages can later be used in the Cancel-Key header field to 106 authenticate a cancel or supersede request. 108 One property of this system is that it prevents tracking of 109 individual users. 111 There are other authentication systems available with different 112 properties. When everybody should be able to verify who the 113 originator is, e.g. for control articles to add or remove newsgroups 114 ([RFC5537] Section 5.2), an OpenPGP [RFC4880] signature is suited. 116 1.1. Conventions Used in This Document 118 Any term not defined in this document has the same meaning as it does 119 in [RFC5536] or [RFC5537]. 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 123 "OPTIONAL" in this document are to be interpreted as described in 124 [RFC2119]. 126 1.2. Author's Note 128 Please write the letters "ae" in "Baeuerle" as an a-umlaut (U+00E4, 129 "ä" in XML), the first letter in "Elie" with an acute accent 130 (U+00C9, "É" in XML), the letters "ss" in Janssen as an eszett 131 (U+00DF, "ß" in XML) and the letters "ue" in Baden-Wuerttemberg 132 as an u-umlaut (U+00FC, "ü" in XML) wherever this is possible. 134 2. Header Fields 136 This section describes the formal syntax of the new header fields 137 using ABNF [RFC5234]. It extends the syntax in Section 3 of 138 [RFC5536] and non-terminals not defined in this document are defined 139 there. 141 The new header fields Cancel-Lock and Cancel-Key are defined by this 142 document, extended the list of article header fields defined in 143 [RFC5536]. 145 Each of these header fields MUST NOT occur more than once in an 146 article. 148 Both new header field bodies contain lists of encoded values. Every 149 entry is based on a : 151 scheme = "sha256" / "sha512" / 1*scheme-char / obs-scheme 152 scheme-char = ALPHA / DIGIT / "-" / "/" 154 The hash algorithms for are defined in [RFC6234], see also 155 [RFC1321] and [RFC6151] for MD5, [RFC3174] for SHA1 and [SHA] for the 156 SHA2 family. The Base64 encoding used is defined in Section 4 of 157 [RFC4648]. 159 This document defines two values for : "sha256" and "sha512". 160 The hash algorithm "sha256" is mandatory to implement. 162 Because the hash algorithm for cannot be negotiated, 163 unnecessary proliferation of hash algorithms should be avoided. The 164 hash algorithms "sha224" and "sha384" are only added to the Netnews 165 Cancel-Lock hash algorithm registry (Section 8.3) because 166 implementations exist that supports them. Implementations SHOULD NOT 167 use the hash algorithms "sha224" and "sha384" to generate . 169 2.1. Cancel-Lock 171 cancel-lock = "Cancel-Lock:" SP c-lock-list CRLF 172 c-lock-list = [CFWS] c-lock *(CFWS c-lock) [CFWS] 173 c-lock = scheme ":" c-lock-string 174 c-lock-string = *(4base64-char) [base64-terminal] 175 base64-char = ALPHA / DIGIT / "+" / "/" 176 base64-terminal = 2base64-char "==" / 3base64-char "=" 178 Comments in CFWS can cause interoperability problems, so comments 179 SHOULD NOT be generated but MUST be accepted. 181 If is not supported by an implementation, the corresponding 182 element MUST be skipped and potential following 183 elements MUST NOT be ignored. 185 is the Base64 encoded output of a hash operation 186 (defined by ) of the Base64 encoded key "K" that is intended 187 to authenticate the person or agent that created or processed 188 respectively the proto-article up to injection (inclusively): 190 Base64(hash(Base64(K))) 192 Because of the one-way nature of the hash operation the key "K" is 193 not revealed. 195 2.2. Cancel-Key 197 cancel-key = "Cancel-Key:" SP c-key-list CRLF 198 c-key-list = [CFWS] c-key *(CFWS c-lock) [CFWS] 199 c-key = scheme ":" c-key-string 200 c-key-string = c-lock-string / obs-c-key-string 202 Comments in CFWS can cause interoperability problems, so comments 203 SHOULD NOT be generated but MUST be accepted. 205 If is not supported by an implementation, the corresponding 206 element MUST be skipped and potential following 207 elements MUST NOT be ignored. 209 is the Base64 encoded key "K" that was used to create 210 the element in the Cancel-Lock header field body (as defined 211 in Section 2.1 of this document) of the original article: 213 Base64(K) 215 The relaxed syntax definition of above is required for 216 backward compatibility with implementations that are not compliant 217 with this specification. Compliant implementations SHOULD generate 218 valid Base64 (that is to say the syntax of as defined 219 in Section 2.1 of this document) and MUST accept strings of 220 characters (that is to say the syntax of as defined in Section 6 of this document). 223 3. Use 225 Use cases: 227 o The poster of an article wants to cancel or supersede existing 228 articles. 230 o A moderator wants the ability to cancel articles after approving 231 them. 233 o An injecting agent wants to act representative for a posting agent 234 that has no support for the authentication system described in 235 this document. 237 o A news administrator wants the ability to cancel articles that 238 were injected by its system (because e.g., they violate its abuse 239 policy). 241 3.1. Adding an initial Cancel-Lock header field to a proto-article 243 A Cancel-Lock header field MAY be added to a proto-article by the 244 poster or posting agent which will include one or more 245 elements. 247 If the poster or posting agent doesn't add a Cancel-Lock header field 248 to a proto-article, then an injecting agent (or moderator) MAY add 249 one, including one or more elements. 251 If multiple elements are added to the Cancel-Lock header 252 field by a single agent, each element MUST use a unique key 253 K to improve security. 255 If an injecting agent (or moderator) wants to act representative for 256 a posting agent without support for the authentication system 257 described in this document, then it MUST be able to positively 258 authenticate the poster and it MUST be able to automatically add a 259 working Cancel-Key header field for all proto-articles with 260 cancelling or superseding attempts from that poster. 262 Other agents MUST NOT add this header field to articles or proto- 263 articles that they process. 265 3.2. Extending the Cancel-Lock header field of a proto-article 267 If a Cancel-Lock header field has already been added to a proto- 268 article then any agent further processing the proto-article up to the 269 injecting agent (inclusively) MAY append additional elements 270 to those already in the header field body. 272 If multiple elements are appended to the Cancel-Lock header 273 field by a single agent, each element MUST use a unique key 274 K to improve security. 276 If an injecting agent (or moderator) wants to act representative for 277 a posting agent without support for the authentication system 278 described in this document, then the same requirements apply as 279 mentioned in Section 3.1. 281 Once an article is injected then this header field MUST NOT be 282 altered. In particular, relaying agents beyond the injecting agent 283 MUST NOT alter it. 285 3.3. Adding a Cancel-Key header field to a proto-article 287 The Cancel-Key header field contains one or more of the secret 288 strings that were used to create the Cancel-Lock header field of the 289 original article. Knowledge of at least one of the secret strings is 290 required to create a match for successful authentication. 292 A Cancel-Key header field MAY be added to a proto-article containing 293 a Control or Supersedes header field by the poster or posting agent 294 which will include one or more elements. They will 295 correspond to some or all of the elements in the article 296 referenced by the Control (with a "cancel" command as defined in 297 [RFC5537]) or Supersedes header field. 299 If, as mentioned in Section 3.1, an injecting agent (or moderator) 300 has added a Cancel-Lock header field to an article listed in the 301 Control (with "cancel" command as defined in [RFC5537]) or Supersedes 302 header field - representative for the posting agent - then (given 303 that it authenticates the poster as being the same as the poster of 304 the original article) it MUST add the Cancel-Key header field with at 305 least one element that corresponds to that article. 307 Other agents MUST NOT alter this header field. 309 3.4. Extending the Cancel-Key header field of a proto-article 311 If a Cancel-Key header field has already been added to a proto- 312 article then any agent further processing the proto-article up to the 313 injecting agent (inclusively) MAY append additional elements 314 to those already in the header field body. 316 If, as mentioned in Section 3.2 an injecting agent (or moderator) has 317 extended the Cancel-Lock header field in an article listed in the 318 Control (with "cancel" command as defined in [RFC5537]) or Supersedes 319 header field - representative for the posting agent - then (given 320 that it authenticates the poster as being the same as the poster of 321 the original article) it MUST extend the Cancel-Key header field body 322 with at least one element that corresponds to that article. 324 Once an article is injected then this header field MUST NOT be 325 altered. In particular, relaying agents beyond the injecting agent 326 MUST NOT alter it. 328 3.5. Check a Cancel-Key header field 330 When a serving agent receives an article that attempts to cancel or 331 supersede a previous article via Control (with a "cancel" command as 332 defined in [RFC5537]) or Supersedes header field, the system defined 333 in this document can be used for authentication. The general 334 handling of articles containing such attempts as defined in [RFC5537] 335 is not changed by this document. 337 To process the authentication, the received article must contain a 338 Cancel-Key header field and the original article a Cancel-Lock header 339 field. If this is not the case, the authentication is not possible 340 (failed). 342 For the authentication check, every supported element from 343 the received article is processed as follows: 345 1. The part of the element is hashed using 346 the algorithm defined by its part. 348 2. For all elements with the same in the original 349 article their part is compared to the calculated 350 hash. 352 3. If one is equal, the authentication is passed and the processing 353 of further elements can be aborted. 355 4. If no match was found and there are no more elements to 356 process, the authentication failed. 358 4. Calculating the key data 360 The following algorithm is RECOMMENDED to calculate the key "K" based 361 on a local secret . 363 The result of the function: 365 K = HMAC(sec, uid+mid) 367 is the key "K" for an article with Message-ID that belongs to 368 the User-ID (e.g. the login name of the user). HMAC is 369 outlined in [RFC2104]. HMAC is computed over the data 370 (with '+' representing the concatenation operation), using as a 371 secret key held locally that can be used for multiple articles. This 372 method removes the need for a per-article database containing the 373 keys used for every article. 375 A posting agent must add the Message-ID header field to the proto- 376 article itself and use the content of the header field body as 377 (including literal angle brackets). 379 The User-ID must not contain angle brackets (to ensure that 380 concatenation of different and elements cannot give the 381 same results). 383 A posting agent, that uses a dedicated local secret for every 384 user, should use an empty string for the part. 386 In general different values for the secret must be used if 387 multiple elements are added by a single agent. 389 The local secret should have a length of at least the output 390 size of the hash function that is used by HMAC (256 bit / 32 octets 391 for SHA256) and must be a cryptographically random value [RFC4086]. 393 Note that the hash algorithm used as base for the HMAC operation is 394 not required to be the same as specified by . An agent that 395 verifies a Cancel-Key header field body simply checks whether one of 396 its elements matches one of the elements with the 397 same in the Cancel-Lock header field body of the original 398 article. 400 Common libraries like OpenSSL can be used for the cryptographic 401 operations. 403 5. Examples 405 5.1. Without UID 407 Example data for creation of a element with HMAC-SHA256 and 408 empty string as (as suggested in Section 4 for posting agents): 410 Message-ID: <12345@mid.example> 412 mid: <12345@mid.example> 413 sec: ExampleSecret 414 K : HMAC-SHA256(sec, mid) ;mid used as data, sec as secret key 416 Calculation of Base64(K) using the OpenSSL command line tools in a 417 POSIX shell: 419 $ printf "%s" "<12345@mid.example>" \ 420 | openssl dgst -sha256 -hmac "ExampleSecret" -binary \ 421 | openssl enc -base64 422 qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA= 424 This can be used as for cancelling or superseding the 425 article <12345@mid.example>. 427 Calculation of Base64(SHA256(Base64(K))) required for 428 using the OpenSSL command line tools in a POSIX shell: 430 $ printf "%s" "qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA=" \ 431 | openssl dgst -sha256 -binary \ 432 | openssl enc -base64 433 s/pmK/3grrz++29ce2/mQydzJuc7iqHn1nqcJiQTPMc= 435 Inserted into the Cancel-Lock header field body of article 436 <12345@mid.example> it looks like this: 438 Cancel-Lock: sha256:s/pmK/3grrz++29ce2/mQydzJuc7iqHn1nqcJiQTPMc= 440 Inserted into the Cancel-Key header field body of an article that 441 should cancel or supersede article <12345@mid.example> it looks like 442 this: 444 Cancel-Key: sha256:qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA= 446 5.2. With UID 448 Example data for creation of a element with HMAC-SHA256 and 449 "JaneDoe" as (as suggested in Section 4): 451 Message-ID: <12345@mid.example> 453 uid: JaneDoe 454 mid: <12345@mid.example> 455 sec: AnotherSecret 456 K : HMAC-SHA256(sec, uid+mid) ;uid+mid as data, sec as secret key 458 Calculation of Base64(K) using the OpenSSL command line tools in a 459 POSIX shell: 461 $ printf "%s" "JaneDoe<12345@mid.example>" \ 462 | openssl dgst -sha256 -hmac "AnotherSecret" -binary \ 463 | openssl enc -base64 464 yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys= 466 This can be used as for cancelling or superseding the 467 article <12345@mid.example>. 469 Calculation of Base64(SHA256(Base64(K))) required for 470 using the OpenSSL command line tools in a POSIX shell: 472 $ printf "%s" "yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys=" \ 473 | openssl dgst -sha256 -binary \ 474 | openssl enc -base64 475 NSBTz7BfcQFTCen+U4lQ0VS8VIlZao2b8mxD/xJaaeE= 477 Inserted into the Cancel-Lock header field body of article 478 <12345@mid.example> it looks like this: 480 Cancel-Lock: sha256:NSBTz7BfcQFTCen+U4lQ0VS8VIlZao2b8mxD/xJaaeE= 482 Inserted into the Cancel-Key header field body of an article that 483 should cancel or supersede article <12345@mid.example> it looks like 484 this: 486 Cancel-Key: sha256:yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys= 488 5.3. Other examples 490 Other matching pair of Cancel-Lock and Cancel-Key header fields: 492 Cancel-Lock: sha256:RrKLp7YCQc9T8HmgSbxwIDlnCDWsgy1awqtiDuhedRo= 493 Cancel-Key: sha256:sSkDke97Dh78/d+Diu1i3dQ2Fp/EMK3xE2GfEqZlvK8= 495 With obsolete syntax (uses a with invalid/missing 496 Base64 padding): 498 Cancel-Lock: sha1:bNXHc6ohSmeHaRHHW56BIWZJt+4= 499 Cancel-Key: ShA1:aaaBBBcccDDDeeeFFF 501 Let's assume that all the examples above are associated to the same 502 article (e.g. created by different agents): 504 Cancel-Lock: sha256:s/pmK/3grrz++29ce2/mQydzJuc7iqHn1nqcJiQTPMc= 505 sha256:NSBTz7BfcQFTCen+U4lQ0VS8VIlZao2b8mxD/xJaaeE= 506 sha256:RrKLp7YCQc9T8HmgSbxwIDlnCDWsgy1awqtiDuhedRo= 507 sha1:bNXHc6ohSmeHaRHHW56BIWZJt+4= 508 Cancel-Key: sha256:qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA= 509 sha256:yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys= 510 sha256:sSkDke97Dh78/d+Diu1i3dQ2Fp/EMK3xE2GfEqZlvK8= 511 ShA1:aaaBBBcccDDDeeeFFF 513 Remember that must be parsed case insensitive. 515 5.4. Manual checks 517 Manual checks using the OpenSSL command line tools in a POSIX shell: 519 $ printf "%s" "qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA=" \ 520 | openssl dgst -sha256 -binary \ 521 | openssl enc -base64 522 s/pmK/3grrz++29ce2/mQydzJuc7iqHn1nqcJiQTPMc= 524 $ printf "%s" "yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys=" \ 525 | openssl dgst -sha256 -binary \ 526 | openssl enc -base64 527 NSBTz7BfcQFTCen+U4lQ0VS8VIlZao2b8mxD/xJaaeE= 529 $ printf "%s" "sSkDke97Dh78/d+Diu1i3dQ2Fp/EMK3xE2GfEqZlvK8=" \ 530 | openssl dgst -sha256 -binary \ 531 | openssl enc -base64 532 RrKLp7YCQc9T8HmgSbxwIDlnCDWsgy1awqtiDuhedRo= 534 $ printf "%s" "aaaBBBcccDDDeeeFFF" \ 535 | openssl dgst -sha1 -binary \ 536 | openssl enc -base64 537 bNXHc6ohSmeHaRHHW56BIWZJt+4= 539 6. Obsolete Syntax 541 Implementations of earlier drafts of this specification defined a 542 different value for than this version. The following value 543 for is now deprecated and SHOULD NOT be generated anymore. 544 Serving agents SHOULD still accept it for a transition period as long 545 as the corresponding hash function is not considered unsafe (see 546 Section 7 for details), or already marked as OBSOLETE in the Netnews 547 Cancel-Lock hash algorithm registry (Section 8.3). 549 obs-scheme = "sha1" 551 It is important for backward compatibility that the deprecated value 552 for is not phased out too early. Security and compatibility 553 concerns should be carefully weighed before choosing to remove from existing implementations (or not implementing it in new 555 ones). 557 Earlier drafts of this specification allowed more liberal syntax for 558 : 560 obs-c-key-string = 1*base64-octet 561 base64-octet = ALPHA / DIGIT / "+" / "/" / "=" 563 SHOULD NOT be generated but MUST be accepted. 565 7. Security Considerations 567 The authentication system defined in this document provides no 568 integrity checking properties. Arbitrary modifications can be 569 applied to an article on its way through the network, regardless of 570 the presence of a Cancel-Key header field. A serving agent, who 571 receives an article that contains a Cancel-Key header field with a 572 matching element, only get the information that the 573 withdrawal of the target article was approved by a legitimate person 574 or agent. 576 Example: A valid element is extracted from a cancel control 577 article and inserted into a forged supersede article. All servers on 578 the network that receive the forged supersede article before the 579 cancel control article should accept the forged supersede. But 580 because everybody can post articles with forged identity information 581 in the header (same as with spam e-mail), the same result can be 582 achieved by sending a forged new article using no authentication 583 system at all. 585 For originator and integrity checks a signature based authentication 586 system is required (normally OpenPGP [RFC4880] is used for this 587 purpose). Both systems can be combined. 589 The important property of the hash function used for is the 590 preimage resistance. A successful preimage attack either reveals the 591 real Cancel-Key (that was used to create the Cancel-Lock of the 592 original article) or gives a different Cancel-Key (that matches a 593 Cancel-Lock too). This would break the authentication system defined 594 in this document. 596 Collision resistance of the hash function used for is less 597 important. Finding two elements for the Cancel-Key header 598 field that match to a element of an arbitrary Cancel-Lock 599 header field is not helpful to break the authentication system 600 defined in this document (if a specific article is defined as 601 target). Only collateral damage by arbitrary cancel or supersede is 602 possible. 604 Currently there is no known practicable preimage and second preimage 605 attack against the hash function SHA1. Therefore there is no hurry 606 to replace it. The reasons why this document specifies hash 607 functions from the SHA2 family are: 609 o The last draft for the authentication system defined in this 610 document is nearly two decades old. The client side 611 implementations are moving forward extremely slowly too 612 (newsreaders from the last millennium are still in heavy use). 614 What is defined today should be strong enough for at least the 615 next decades. 617 o The collision resistance of SHA1 is already broken, therefore it 618 is now obsolete for digital signatures as used in TLS. It is 619 intended that an implementation of the authentication system 620 defined in this document can share the same cryptographic library 621 functions that are used for TLS. 623 o It is intended that the same hash function can be used for 624 and (as base) for the HMAC that is suggested in 625 Section 4. See notes below for HMAC-MD5 and HMAC-SHA1. 627 o The SHA2 family of hash algorithms is widely supported by 628 cryptographic libraries. In contrast, SHA3 is currently not 629 supported by e.g. OpenSSL. 631 The operation HMAC(sec, uid+mid) as suggested in Section 4 must be 632 able to protect the local secret . The Message-ID is 633 public (in the Message-ID header field body) and is optional. 634 An attacker who wants to steal/use a local secret only need to break 635 this algorithm (regardless of ), because Cancel-Key header 636 fields are explicitly published for every request to cancel or 637 supersede existing articles. 639 Even if HMAC-MD5 and HMAC-SHA1 are not considered broken today, it is 640 desired to have some more security margin here. Breaking 641 only allows to authenticate a single forged cancel or supersede 642 request. With in hand it is possible to forge such requests 643 for all articles that contain Cancel-Lock header field bodies with 644 elements that are generated with this in the past. Changing 645 in regular intervals can be used to mitigate the potential 646 damage. 648 If an agent adds or appends multiple elements, it must not 649 use the same K for them (by using different secrets ). Adding 650 multiple elements with the same and the same K 651 makes no sense (would result in identical elements), 652 therefore the case with different is relevant: A preimage 653 attack on the different hash algorithms may be easier if the attacker 654 knows that the output of them was created with the same input. 656 If an implementation chooses to not implement the key calculation 657 algorithm recommended in Section 4, or to implement it with HMAC 658 based on a different hash function than , the key size used 659 should match the output size of the hash function used for . 661 8. IANA Considerations 663 IANA has registered the following header fields in the Permanent 664 Message Header Field Repository, in accordance with the procedures 665 set out in [RFC3864]: 667 Header field name: Cancel-Lock 668 Applicable protocol: netnews 669 Status: standard 670 Author/change controller: IETF 671 Specification document(s): This document 673 Header field name: Cancel-Key 674 Applicable protocol: netnews 675 Status: standard 676 Author/change controller: IETF 677 Specification document(s): This document 679 The Netnews Cancel-Lock hash algorithm registry will be maintained by 680 IANA. 682 The registry will be available at . 686 8.1. Algorithm Name Registration Procedure 688 IANA will register new Cancel-Lock hash algorithm names on a First 689 Come First Served basis, as defined in BCP 26 [RFC8126]. IANA has 690 the right to reject obviously bogus registration requests, but will 691 perform no review of claims made in the registration form. 693 Registration of a Netnews Cancel-Lock hash algorithm is requested by 694 filling in the following template and sending it via electronic mail 695 to IANA at : 697 Subject: Registration of Netnews Cancel-Lock hash algorithm X 698 Netnews Cancel-Lock hash algorithm name: 699 Security considerations: 700 Published specification (recommended): 701 Contact for further information: 702 Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE) 703 Owner/Change controller: 704 Note: (Any other information that the author deems relevant may be 705 added here.) 707 Any name that conforms to the syntax of a Netnews Cancel-Lock hash 708 algorithm (see definition of in Section 2) can be used. 710 Especially, Netnews Cancel-Lock algorithms are named by strings 711 consisting of letters, digits, hyphens and/or slashes. 713 Authors may seek community review by posting a specification of their 714 proposed algorithm as an Internet-Draft. Netnews Cancel-Lock hash 715 algorithms intended for widespread use should be standardized through 716 the normal IETF process, when appropriate. 718 The IESG is considered to be the owner of all Netnews Cancel-Lock 719 hash algorithms that are on the IETF Standards Track. 721 8.2. Change control 723 Once a Netnews Cancel-Lock hash algorithm registration has been 724 published by IANA, the owner may request a change to its definition. 725 The change request follows the same procedure as the initial 726 registration request. 728 The owner of a Netnews Cancel-Lock hash algorithm may pass 729 responsibility for the algorithm to another person or agency by 730 informing IANA; this can be done without discussion or review. 732 The IESG may reassign responsibility for a Netnews Cancel-Lock hash 733 algorithm. The most common case of this will be to enable changes to 734 be made to algorithms where the owner of the registration has died, 735 has moved out of contact, or is otherwise unable to make changes that 736 are important to the community. 738 Netnews Cancel-Lock hash algorithm registrations MUST NOT be deleted; 739 algorithms that are no longer believed appropriate for use can be 740 declared OBSOLETE by a change to their "intended usage" field; such 741 algorithms will be clearly marked in the registry published by IANA. 743 The IESG is considered to be the owner of all Netnews Cancel-Lock 744 hash algorithms that are on the IETF Standards Track. 746 8.3. Registration of the Netnews Cancel-Lock hash algorithms 748 This section gives a formal definition of the Netnews Cancel-Lock 749 hash algorithms as required by Section 8.1 for the IANA registry. 751 Netnews Cancel-Lock hash algorithm name: md5 752 Security considerations: See corresponding section of this document 753 Published specification: This document 754 Contact for further information: Author of this document 755 Intended usage: OBSOLETE 756 Owner/Change controller: IESG 757 Note: Do not use this algorithm anymore 758 Netnews Cancel-Lock hash algorithm name: sha1 759 Security considerations: See corresponding section of this document 760 Published specification: This document 761 Contact for further information: Author of this document 762 Intended usage: LIMITED USE 763 Owner/Change controller: IESG 764 Note: This algorithm is intended for backward compatibility 766 Netnews Cancel-Lock hash algorithm name: sha224 767 Security considerations: See corresponding section of this document 768 Published specification: This document 769 Contact for further information: Author of this document 770 Intended usage: LIMITED USE 771 Owner/Change controller: IESG 772 Note: sha256 should be used instead, this is a truncated variant 774 Netnews Cancel-Lock hash algorithm name: sha256 775 Security considerations: See corresponding section of this document 776 Published specification: This document 777 Contact for further information: Author of this document 778 Intended usage: COMMON 779 Owner/Change controller: IESG 780 Note: This algorithm is mandatory to implement 782 Netnews Cancel-Lock hash algorithm name: sha384 783 Security considerations: See corresponding section of this document 784 Published specification: This document 785 Contact for further information: Author of this document 786 Intended usage: LIMITED USE 787 Owner/Change controller: IESG 788 Note: sha512 should be used instead, this is a truncated variant 790 Netnews Cancel-Lock hash algorithm name: sha512 791 Security considerations: See corresponding section of this document 792 Published specification: This document 793 Contact for further information: Author of this document 794 Intended usage: COMMON 795 Owner/Change controller: IESG 796 Note: This algorithm is optional 798 9. References 800 9.1. Normative References 802 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 803 Requirement Levels", BCP 14, RFC 2119, 804 DOI 10.17487/RFC2119, March 1997, 805 . 807 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 808 Procedures for Message Header Fields", BCP 90, RFC 3864, 809 DOI 10.17487/RFC3864, September 2004, 810 . 812 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 813 "Randomness Requirements for Security", BCP 106, RFC 4086, 814 DOI 10.17487/RFC4086, June 2005, 815 . 817 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 818 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 819 . 821 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 822 Specifications: ABNF", STD 68, RFC 5234, 823 DOI 10.17487/RFC5234, January 2008, 824 . 826 [RFC5536] Murchison, K., Ed., Lindsey, C., and D. Kohn, "Netnews 827 Article Format", RFC 5536, DOI 10.17487/RFC5536, November 828 2009, . 830 [RFC5537] Allbery, R., Ed. and C. Lindsey, "Netnews Architecture and 831 Protocols", RFC 5537, DOI 10.17487/RFC5537, November 2009, 832 . 834 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 835 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 836 DOI 10.17487/RFC6234, May 2011, 837 . 839 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 840 Writing an IANA Considerations Section in RFCs", BCP 26, 841 RFC 8126, DOI 10.17487/RFC8126, June 2017, 842 . 844 9.2. Informative References 846 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 847 DOI 10.17487/RFC1321, April 1992, 848 . 850 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 851 Hashing for Message Authentication", RFC 2104, 852 DOI 10.17487/RFC2104, February 1997, 853 . 855 [RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 856 (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001, 857 . 859 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 860 Thayer, "OpenPGP Message Format", RFC 4880, 861 DOI 10.17487/RFC4880, November 2007, 862 . 864 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 865 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 866 RFC 6151, DOI 10.17487/RFC6151, March 2011, 867 . 869 [SHA] National Institute of Standards and Technology, "Secure 870 Hash Standard (SHS)", FIPS 180-4, DOI 10.6028/FIPS.180-4, 871 August 2015, . 874 [USEFOR-CANCEL-LOCK] 875 Lyall, S., "Cancel-Locks in Usenet articles.", Work in 876 Progress, November 1998. 878 Appendix A. Acknowledgements 880 The author acknowledges the original author of the Cancel-Lock 881 authentication system as documented in draft-ietf-usefor-cancel-lock: 882 Simon Lyall. He has written the original draft and former version 883 [USEFOR-CANCEL-LOCK] and approved the usage of his work for this 884 document. This document is mostly based on his work and was 885 originally intended as revision 02. It must be renamed because the 886 USEFOR IETF WG is now closed. 888 The author would like to thank the following individuals for 889 contributing their ideas and reviewing this specification: Russ 890 Allbery, Urs Janssen, Richard Kettlewell, Marcel Logen, Holger 891 Marzen, Dennis Preiser, Emil Schuster. And Peter Faust and Alfred 892 Peters for providing statistic data about the algorithms currently in 893 use. 895 Special thanks to the Document Shepherd, Julien Elie and to the 896 Responsible Area Director, Alexey Melnikov. 898 Appendix B. Document History (to be removed by RFC Editor before 899 publication) 901 B.1. Changes since -07 903 o Fixed line length problems in section Section 8.3. 905 o Use NBSP for "e.g. OpenSSL" in Section 7 to prevent insertion of 906 additional space by file format converters (suggested by Julien 907 Elie). 909 o Replaced reference to obsolete RFC5226 with reference to successor 910 RFC8216 (reported by Julien Elie). 912 o Swapped parameters of HMAC() function in sections Section 5 and 913 Section 7 too (reported by Julien Elie). 915 B.2. Changes since -06 917 o Changed paragraph about key size in section Section 7. 919 o Added RFC4086 as normative reference. Changed wording from 920 "random" to "cryptographically random" with reference to RFC4086" 921 in section Section 4 (suggested by Eric Rescorla). 923 o Swapped parameters of HMAC() function in section Section 4 for 924 consistency with other RFCs (suggested by Eric Rescorla). 926 o Moved general description from section Section 3 to section 927 Section 1 (suggested by Eric Rescorla). 929 o Changed wording in Section 3 (suggested by Eric Rescorla). 931 o Replaced the word "required" with "requested" in section Section 1 932 (reported by Warren Kumari). 934 o Syntax definition modified in section Section 2 because of erratum 935 5116 in RFC5536 (reported by Paul Kyzivat, using words suggested 936 by Alexey Melnikov). 938 o Fixed spelling in different sections (reported by Julien Elie). 940 o Added text why agents must use different K values if they add 941 multiple elements to Section 7. 943 o Modified text for unique K in Section 4 to make it clear that the 944 requirement targets single agents that add multiple 945 elements (suggested by Julien Elie). 947 o Moved text for unique K from Section 2.1 to Section 3.1 and 948 Section 3.2 to make it clear that the requirement targets single 949 agents that add multiple elements (suggested by Julien 950 Elie). 952 B.3. Changes since -05 954 o Modified text in Section 3.1 and Section 3.2 to make it clear that 955 an injecting agent only must be able to authenticate the poster if 956 it wants to act representative for him. 958 o Added/moved general description text to Section 3 to make things 959 easier to understand (suggested by GEN-Art Last Call review). 961 o Removed text for importance of second preimage resistance in 962 Section 7 (suggested by Secdir review). 964 o Added note that local secret must be random in Section 4 965 (suggested by Secdir review). 967 o Added note that is not allowed to contain angle brackets in 968 Section 4 (suggested by Secdir review). 970 o Changed copyright notice (because Simon Lyall has licensed his 971 work to the IETF Trust in the meantime). 973 o Fixed spelling in Section 3.3, Section 3.4, Section 7 and 974 Section 8.1 (reported by Julien Elie). 976 o Changed proposed location of IANA registry in Section 8. Should 977 be more consistent with existing registries now (suggested by 978 Julien Elie). 980 o Added note to not use the same secret if multiple 981 elements are added in Section 2.1 and Section 4 (suggested by 982 Secdir review). 984 o Unified the term "cancel control article". 986 o Added notes for impersonation and content forging attacks in 987 Section 7. 989 o Description text modified in Section 1. 991 B.4. Changes since -04 993 o Added note that the IESG is the owner of all Netnews Cancel-Lock 994 hash algorithms that are on the IETF Standards Track in 995 Section 8.1. 997 o Changed the algorithm from informative to RECOMMENDED in 998 Section 4. 1000 o Replaced "code-string" with "c-lock-string" for Step 2 in 1001 Section 3.5. 1003 o Replaced "code-string" with "c-key-string" for Step 1 in 1004 Section 3.5. 1006 o Added a short explanation in Section 3.3. 1008 o Added a short explanation in Section 3.1. 1010 o Replaced link to RFC2045 with link to RFC4648 in Section 2. 1012 o Replaced normative reference RFC2045 (for Base64 algorithm) with 1013 RFC4648. 1015 o Added case insensitivity note in Section 5.3. 1017 o RFC6234 (listed in the downref registry) is now a normative 1018 reference (formerly informative) as recommended by Shepherd Write- 1019 Up. 1021 o NIST SHS standard is now an informative reference (formerly 1022 normative) as recommended by Shepherd Write-Up. 1024 o Added "sha224" and "sha384" schemes in Section 8.3 (because 1025 implementations exists that supports them). 1027 o Refer to Section 8.3 instead of Section 8.1 for hash algorithm 1028 registry. 1030 o Fixed some typos. 1032 o Fixed line length in Section 5.1. 1034 B.5. Changes since -03 1036 o Added note for change interval of in Section 7. 1038 o Changed wording in Section 7. 1040 o Splitted Section 5 into multiple subsections. 1042 o Added example with UID in Section 5. 1044 o Changed "SHOULD NOT" to uppercase in Section 6. 1046 o Reformatted Section 8, Section 8.1 and Section 8.3. 1048 o Fixed spelling in Section 4. 1050 B.6. Changes since -02 1052 o Added Section 8.2. 1054 o Added note about algorithm names in Section 8.1. 1056 o Added "/" to scheme-char in Section 2. 1058 o Removed case sensitivity of scheme and normative reference to 1059 RFC7405 in Section 2 again. 1061 o Added "sha512" scheme in Section 2. 1063 o Changed wording in Section 8.3. 1065 o Fixed typo "canceling" in Section 5. 1067 o Changed calculation formulas to use "Base64" in Section 2.1 and 1068 Section 2.2. 1070 o Added obsolete algorithm "md5" in Section 8.3. 1072 o Added note that posting agents should add the Message-ID header 1073 field to proto-articles and use its content for in 1074 Section 4. 1076 o Added part to key calculation in Section 4. 1078 o Added note to generate CFWS without comments in Section 2.1 and 1079 Section 2.2. 1081 o Changed ABNF to allow CFWS at the beginning of header fields in 1082 Section 2.1 and Section 2.2. 1084 o Changed wording for "header"/"header field"/"header field body". 1086 o Added Section 3.4. 1088 o Changed wording in Section 3.1. 1090 o Allowed additional whitespace at the beginning of header fields in 1091 Section 2.1 and Section 2.2. 1093 o Changed definition of "c-key-string" in Section 2.2. 1095 o Added "obs-c-key-string" to Section 6. 1097 o Fixed typo in Section 2.2 ("c-lock" replaced by "c-key"). 1099 o Added key length recommendation in Section 7. 1101 o Renamed "sha-256" scheme to "sha256". 1103 o Modified header and abstract section to list RFC5537 as updated by 1104 this document again. 1106 o Added "USEFOR-CANCEL-LOCK" as informative reference. 1108 o Changed wording in Section 4. 1110 B.7. Changes since -01 1112 o Changed wording in Section 7. 1114 o Added example for HMAC calculation in Section 5. 1116 o Changed wording in Section 4. 1118 o Added use cases to Section 3.2. 1120 o Replaced wording "injecting-agent" by "injecting agent". 1122 o Added Definition for "LOWER" in Section 2. 1124 o Added Section 8.3. 1126 o Added Section 8.1. 1128 o Added new entries for header field registry in Section 8. 1130 o Removed recommendation that moderators and injecting agents should 1131 add only one Cancel-Lock or Cancel-Key resprectively to the list 1132 in Section 3.1, Section 3.2 and Section 3.3. 1134 o Added missing headerfield termination to Section 2.1 and 1135 Section 2.2. 1137 o Removed definition for "code-string" from Section 2. Added 1138 stricter definition "c-lock-string" to Section 2.1. Added 1139 backward compatible definition "c-key-string" to Section 2.2. 1141 o Use different wording in Section 2.2. 1143 o Changed wording to reflect that an injecting agent is allowed to 1144 create Cancel-Lock headerfields in Section 2.1. 1146 o Fixed wording and typo in Section 2. 1148 o Added normative reference to RFC7405 because case-sensitivity is 1149 used in ABNF. 1151 o Added reference to RFC5536 (Section 2.2) in Section 2. 1153 o Added references to RFC4880 and RFC5537 in Section 1. 1155 o Replaced the wordings "remove" by "cancel" and "replace" by 1156 "supersede". 1158 o Modified header and abstract section to no longer list RFC5536 and 1159 RFC5537 as updated by this document. 1161 B.8. Changes since -00 1163 o Added additional note that deprecated "scheme" values should be 1164 preserved for backward compatibility as long as reasonable. 1166 o Removed deprectated scheme "md5" (not in use anymore). 1168 o Added descriptions how to generate "code-string" to Section 2.1 1169 and Section 2.2. 1171 o Removed length limitiation in ABNF of "scheme". 1173 o Changed copyright notice to use text from TLP section 6.c.iii. 1175 o Removed references from "abstract" section. 1177 o Changed "SHOULD NOT" to uppercase in Section 6. 1179 o Added line wraps to CLI commands in Section 5. 1181 B.9. Changes since draft-ietf-usefor-cancel-lock-01 1183 o Renamed document because the USEFOR IETF WG is now closed. 1185 o Added more details how to check Cancel-Key header fields in 1186 Section 3.5. 1188 o Added more details to Section 7. 1190 o Added updated ABNF for Cancel-Lock and Cancel-Key header fields. 1192 o Deprecated "md5" and "sha1" schemes. 1194 o Added "sha-256" scheme. 1196 o Reworded the abstract section and added references. 1198 o Added note to other authentication systems to Section 1. 1200 o Added command line check examples to Section 5. 1202 B.10. Changes since draft-ietf-usefor-cancel-lock-00 1204 o References to SHA-160 changed to SHA1 1206 o "scheme" is now a case insensitive token and the number "1" has 1207 been changed to "sha1". 1209 o Added some examples and fixed the section numbering. 1211 o Updated 2nd paragraph on section 2.2 to make clear what exactly is 1212 being hashed and how. 1214 o Changed paragraph 2 of 3.1 to discourage injection agents from 1215 adding the header. 1217 o Removed the Clue-string as this complicated the scheme without 1218 adding realistic functionality 1220 o Moderators can now add these headers under the same conditions as 1221 injection agents. 1223 Author's Address 1225 Michael Baeuerle 1226 STZ Elektronik 1227 Hofener Weg 33C 1228 Remseck, Baden-Wuerttemberg 71686 1229 Germany 1231 Fax: +49 7146 999061 1232 EMail: michael.baeuerle@stz-e.de