idnits 2.17.1 draft-baeuerle-netnews-cancel-lock-07.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 1 character in excess of 72. 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 19, 2017) is 2343 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Downref: Normative reference to an Informational RFC: RFC 6234 Summary: 3 errors (**), 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 19, 2017 5 Intended status: Standards Track 6 Expires: May 23, 2018 8 Cancel-Locks in Netnews articles 9 draft-baeuerle-netnews-cancel-lock-07 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 23, 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 -06 . . . . . . . . . . . . . . . . . . . . 20 83 B.2. Changes since -05 . . . . . . . . . . . . . . . . . . . . 21 84 B.3. Changes since -04 . . . . . . . . . . . . . . . . . . . . 22 85 B.4. Changes since -03 . . . . . . . . . . . . . . . . . . . . 23 86 B.5. Changes since -02 . . . . . . . . . . . . . . . . . . . . 23 87 B.6. Changes since -01 . . . . . . . . . . . . . . . . . . . . 24 88 B.7. Changes since -00 . . . . . . . . . . . . . . . . . . . . 25 89 B.8. Changes since draft-ietf-usefor-cancel-lock-01 . . . . . 26 90 B.9. Changes since draft-ietf-usefor-cancel-lock-00 . . . . . 26 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27 93 1. Introduction 95 The authentication system defined in this document is intended to be 96 used as a simple method to verify that the withdrawal of an article 97 is valid, that is to say either the poster, posting agent, moderator 98 or injecting agent that processed the original article has requested 99 to withdraw it via the use of a cancel control article ([RFC5537] 100 Section 5.3) or a Supersedes header field ([RFC5537] Section 5.4). 102 This document defines two new header fields: Cancel-Lock and Cancel- 103 Key. The Cancel-Lock header field contains hashes of secret data. 104 The preimages can later be used in the Cancel-Key header field to 105 authenticate a cancel or supersede request. 107 One property of this system is that it prevents tracking of 108 individual users. 110 There are other authentication systems available with different 111 properties. When everybody should be able to verify who the 112 originator is, e.g. for control articles to add or remove newsgroups 113 ([RFC5537] Section 5.2), an OpenPGP [RFC4880] signature is suited. 115 1.1. Conventions Used in This Document 117 Any term not defined in this document has the same meaning as it does 118 in [RFC5536] or [RFC5537]. 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 122 "OPTIONAL" in this document are to be interpreted as described in 123 [RFC2119]. 125 1.2. Author's Note 127 Please write the letters "ae" in "Baeuerle" as an a-umlaut (U+00E4, 128 "ä" in XML), the first letter in "Elie" with an acute accent 129 (U+00C9, "É" in XML), the letters "ss" in Janssen as an eszett 130 (U+00DF, "ß" in XML) and the letters "ue" in Baden-Wuerttemberg 131 as an u-umlaut (U+00FC, "ü" in XML) wherever this is possible. 133 2. Header Fields 135 This section describes the formal syntax of the new header fields 136 using ABNF [RFC5234]. It extends the syntax in Section 3 of 137 [RFC5536] and non-terminals not defined in this document are defined 138 there. 140 The new header fields Cancel-Lock and Cancel-Key are defined by this 141 document, extended the list of article header fields defined in 142 [RFC5536]. 144 Each of these header fields MUST NOT occur more than once in an 145 article. 147 Both new header field bodies contain lists of encoded values. Every 148 entry is based on a : 150 scheme = "sha256" / "sha512" / 1*scheme-char / obs-scheme 151 scheme-char = ALPHA / DIGIT / "-" / "/" 153 The hash algorithms for are defined in [RFC6234], see also 154 [RFC1321] and [RFC6151] for MD5, [RFC3174] for SHA1 and [SHA] for the 155 SHA2 family. The Base64 encoding used is defined in Section 4 of 156 [RFC4648]. 158 This document defines two values for : "sha256" and "sha512". 159 The hash algorithm "sha256" is mandatory to implement. 161 Because the hash algorithm for cannot be negotiated, 162 unnecessary proliferation of hash algorithms should be avoided. The 163 hash algorithms "sha224" and "sha384" are only added to the Netnews 164 Cancel-Lock hash algorithm registry (Section 8.3) because 165 implementations exist that supports them. Implementations SHOULD NOT 166 use the hash algorithms "sha224" and "sha384" to generate . 168 2.1. Cancel-Lock 170 cancel-lock = "Cancel-Lock:" SP c-lock-list CRLF 171 c-lock-list = [CFWS] c-lock *(CFWS c-lock) [CFWS] 172 c-lock = scheme ":" c-lock-string 173 c-lock-string = *(4base64-char) [base64-terminal] 174 base64-char = ALPHA / DIGIT / "+" / "/" 175 base64-terminal = 2base64-char "==" / 3base64-char "=" 177 Comments in CFWS can cause interoperability problems, so comments 178 SHOULD NOT be generated but MUST be accepted. 180 If is not supported by an implementation, the corresponding 181 element MUST be skipped and potential following 182 elements MUST NOT be ignored. 184 is the Base64 encoded output of a hash operation 185 (defined by ) of the Base64 encoded key "K" that is intended 186 to authenticate the person or agent that created or processed 187 respectively the proto-article up to injection (inclusively): 189 Base64(hash(Base64(K))) 191 Because of the one-way nature of the hash operation the key "K" is 192 not revealed. 194 2.2. Cancel-Key 196 cancel-key = "Cancel-Key:" SP c-key-list CRLF 197 c-key-list = [CFWS] c-key *(CFWS c-lock) [CFWS] 198 c-key = scheme ":" c-key-string 199 c-key-string = c-lock-string / obs-c-key-string 201 Comments in CFWS can cause interoperability problems, so comments 202 SHOULD NOT be generated but MUST be accepted. 204 If is not supported by an implementation, the corresponding 205 element MUST be skipped and potential following 206 elements MUST NOT be ignored. 208 is the Base64 encoded key "K" that was used to create 209 the element in the Cancel-Lock header field body (as defined 210 in Section 2.1 of this document) of the original article: 212 Base64(K) 214 The relaxed syntax definition of above is required for 215 backward compatibility with implementations that are not compliant 216 with this specification. Compliant implementations SHOULD generate 217 valid Base64 (that is to say the syntax of as defined 218 in Section 2.1 of this document) and MUST accept strings of 219 characters (that is to say the syntax of as defined in Section 6 of this document). 222 3. Use 224 Use cases: 226 o The poster of an article wants to cancel or supersede existing 227 articles. 229 o A moderator wants the ability to cancel articles after approving 230 them. 232 o An injecting agent wants to act representative for a posting agent 233 that has no support for the authentication system described in 234 this document. 236 o A news administrator wants the ability to cancel articles that 237 were injected by its system (because e.g., they violate its abuse 238 policy). 240 3.1. Adding an initial Cancel-Lock header field to a proto-article 242 A Cancel-Lock header field MAY be added to a proto-article by the 243 poster or posting agent which will include one or more 244 elements. 246 If the poster or posting agent doesn't add a Cancel-Lock header field 247 to a proto-article, then an injecting agent (or moderator) MAY add 248 one, including one or more elements. 250 If multiple elements are added to the Cancel-Lock header 251 field by a single agent, each element MUST use a unique key 252 K to improve security. 254 If an injecting agent (or moderator) wants to act representative for 255 a posting agent without support for the authentication system 256 described in this document, then it MUST be able to positively 257 authenticate the poster and it MUST be able to automatically add a 258 working Cancel-Key header field for all proto-articles with 259 cancelling or superseding attempts from that poster. 261 Other agents MUST NOT add this header field to articles or proto- 262 articles that they process. 264 3.2. Extending the Cancel-Lock header field of a proto-article 266 If a Cancel-Lock header field has already been added to a proto- 267 article then any agent further processing the proto-article up to the 268 injecting agent (inclusively) MAY append additional elements 269 to those already in the header field body. 271 If multiple elements are appended to the Cancel-Lock header 272 field by a single agent, each element MUST use a unique key 273 K to improve security. 275 If an injecting agent (or moderator) wants to act representative for 276 a posting agent without support for the authentication system 277 described in this document, then the same requirements apply as 278 mentioned in Section 3.1. 280 Once an article is injected then this header field MUST NOT be 281 altered. In particular, relaying agents beyond the injecting agent 282 MUST NOT alter it. 284 3.3. Adding a Cancel-Key header field to a proto-article 286 The Cancel-Key header field contains one or more of the secret 287 strings that were used to create the Cancel-Lock header field of the 288 original article. Knowledge of at least one of the secret strings is 289 required to create a match for successful authentication. 291 A Cancel-Key header field MAY be added to a proto-article containing 292 a Control or Supersedes header field by the poster or posting agent 293 which will include one or more elements. They will 294 correspond to some or all of the elements in the article 295 referenced by the Control (with a "cancel" command as defined in 296 [RFC5537]) or Supersedes header field. 298 If, as mentioned in Section 3.1, an injecting agent (or moderator) 299 has added a Cancel-Lock header field to an article listed in the 300 Control (with "cancel" command as defined in [RFC5537]) or Supersedes 301 header field - representative for the posting agent - then (given 302 that it authenticates the poster as being the same as the poster of 303 the original article) it MUST add the Cancel-Key header field with at 304 least one element that corresponds to that article. 306 Other agents MUST NOT alter this header field. 308 3.4. Extending the Cancel-Key header field of a proto-article 310 If a Cancel-Key header field has already been added to a proto- 311 article then any agent further processing the proto-article up to the 312 injecting agent (inclusively) MAY append additional elements 313 to those already in the header field body. 315 If, as mentioned in Section 3.2 an injecting agent (or moderator) has 316 extended the Cancel-Lock header field in an article listed in the 317 Control (with "cancel" command as defined in [RFC5537]) or Supersedes 318 header field - representative for the posting agent - then (given 319 that it authenticates the poster as being the same as the poster of 320 the original article) it MUST extend the Cancel-Key header field body 321 with at least one element that corresponds to that article. 323 Once an article is injected then this header field MUST NOT be 324 altered. In particular, relaying agents beyond the injecting agent 325 MUST NOT alter it. 327 3.5. Check a Cancel-Key header field 329 When a serving agent receives an article that attempts to cancel or 330 supersede a previous article via Control (with a "cancel" command as 331 defined in [RFC5537]) or Supersedes header field, the system defined 332 in this document can be used for authentication. The general 333 handling of articles containing such attempts as defined in [RFC5537] 334 is not changed by this document. 336 To process the authentication, the received article must contain a 337 Cancel-Key header field and the original article a Cancel-Lock header 338 field. If this is not the case, the authentication is not possible 339 (failed). 341 For the authentication check, every supported element from 342 the received article is processed as follows: 344 1. The part of the element is hashed using 345 the algorithm defined by its part. 347 2. For all elements with the same in the original 348 article their part is compared to the calculated 349 hash. 351 3. If one is equal, the authentication is passed and the processing 352 of further elements can be aborted. 354 4. If no match was found and there are no more elements to 355 process, the authentication failed. 357 4. Calculating the key data 359 The following algorithm is RECOMMENDED to calculate the key "K" based 360 on a local secret . 362 The result of the function: 364 K = HMAC(sec, uid+mid) 366 is the key "K" for an article with Message-ID that belongs to 367 the User-ID (e.g. the login name of the user). HMAC is 368 outlined in [RFC2104]. HMAC is computed over the data 369 (with '+' representing the concatenation operation), using as a 370 secret key held locally that can be used for multiple articles. This 371 method removes the need for a per-article database containing the 372 keys used for every article. 374 A posting agent must add the Message-ID header field to the proto- 375 article itself and use the content of the header field body as 376 (including literal angle brackets). 378 The User-ID must not contain angle brackets (to ensure that 379 concatenation of different and elements cannot give the 380 same results). 382 A posting agent, that uses a dedicated local secret for every 383 user, should use an empty string for the part. 385 In general different values for the secret must be used if 386 multiple elements are added by a single agent. 388 The local secret should have a length of at least the output 389 size of the hash function that is used by HMAC (256 bit / 32 octets 390 for SHA256) and must be a cryptographically random value [RFC4086]. 392 Note that the hash algorithm used as base for the HMAC operation is 393 not required to be the same as specified by . An agent that 394 verifies a Cancel-Key header field body simply checks whether one of 395 its elements matches one of the elements with the 396 same in the Cancel-Lock header field body of the original 397 article. 399 Common libraries like OpenSSL can be used for the cryptographic 400 operations. 402 5. Examples 404 5.1. Without UID 406 Example data for creation of a element with HMAC-SHA256 and 407 empty string as (as suggested in Section 4 for posting agents): 409 Message-ID: <12345@mid.example> 411 mid: <12345@mid.example> 412 sec: ExampleSecret 413 K : HMAC-SHA256(mid, sec) ;mid used as data, sec as secret key 415 Calculation of Base64(K) using the OpenSSL command line tools in a 416 POSIX shell: 418 $ printf "%s" "<12345@mid.example>" \ 419 | openssl dgst -sha256 -hmac "ExampleSecret" -binary \ 420 | openssl enc -base64 421 qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA= 423 This can be used as for cancelling or superseding the 424 article <12345@mid.example>. 426 Calculation of Base64(SHA256(Base64(K))) required for 427 using the OpenSSL command line tools in a POSIX shell: 429 $ printf "%s" "qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA=" \ 430 | openssl dgst -sha256 -binary \ 431 | openssl enc -base64 432 s/pmK/3grrz++29ce2/mQydzJuc7iqHn1nqcJiQTPMc= 434 Inserted into the Cancel-Lock header field body of article 435 <12345@mid.example> it looks like this: 437 Cancel-Lock: sha256:s/pmK/3grrz++29ce2/mQydzJuc7iqHn1nqcJiQTPMc= 439 Inserted into the Cancel-Key header field body of an article that 440 should cancel or supersede article <12345@mid.example> it looks like 441 this: 443 Cancel-Key: sha256:qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA= 445 5.2. With UID 447 Example data for creation of a element with HMAC-SHA256 and 448 "JaneDoe" as (as suggested in Section 4): 450 Message-ID: <12345@mid.example> 452 uid: JaneDoe 453 mid: <12345@mid.example> 454 sec: AnotherSecret 455 K : HMAC-SHA256(uid+mid, sec) ;uid+mid as data, sec as secret key 457 Calculation of Base64(K) using the OpenSSL command line tools in a 458 POSIX shell: 460 $ printf "%s" "JaneDoe<12345@mid.example>" \ 461 | openssl dgst -sha256 -hmac "AnotherSecret" -binary \ 462 | openssl enc -base64 463 yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys= 465 This can be used as for cancelling or superseding the 466 article <12345@mid.example>. 468 Calculation of Base64(SHA256(Base64(K))) required for 469 using the OpenSSL command line tools in a POSIX shell: 471 $ printf "%s" "yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys=" \ 472 | openssl dgst -sha256 -binary \ 473 | openssl enc -base64 474 NSBTz7BfcQFTCen+U4lQ0VS8VIlZao2b8mxD/xJaaeE= 476 Inserted into the Cancel-Lock header field body of article 477 <12345@mid.example> it looks like this: 479 Cancel-Lock: sha256:NSBTz7BfcQFTCen+U4lQ0VS8VIlZao2b8mxD/xJaaeE= 481 Inserted into the Cancel-Key header field body of an article that 482 should cancel or supersede article <12345@mid.example> it looks like 483 this: 485 Cancel-Key: sha256:yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys= 487 5.3. Other examples 489 Other matching pair of Cancel-Lock and Cancel-Key header fields: 491 Cancel-Lock: sha256:RrKLp7YCQc9T8HmgSbxwIDlnCDWsgy1awqtiDuhedRo= 492 Cancel-Key: sha256:sSkDke97Dh78/d+Diu1i3dQ2Fp/EMK3xE2GfEqZlvK8= 494 With obsolete syntax (uses a with invalid/missing 495 Base64 padding): 497 Cancel-Lock: sha1:bNXHc6ohSmeHaRHHW56BIWZJt+4= 498 Cancel-Key: ShA1:aaaBBBcccDDDeeeFFF 500 Let's assume that all the examples above are associated to the same 501 article (e.g. created by different agents): 503 Cancel-Lock: sha256:s/pmK/3grrz++29ce2/mQydzJuc7iqHn1nqcJiQTPMc= 504 sha256:NSBTz7BfcQFTCen+U4lQ0VS8VIlZao2b8mxD/xJaaeE= 505 sha256:RrKLp7YCQc9T8HmgSbxwIDlnCDWsgy1awqtiDuhedRo= 506 sha1:bNXHc6ohSmeHaRHHW56BIWZJt+4= 507 Cancel-Key: sha256:qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA= 508 sha256:yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys= 509 sha256:sSkDke97Dh78/d+Diu1i3dQ2Fp/EMK3xE2GfEqZlvK8= 510 ShA1:aaaBBBcccDDDeeeFFF 512 Remember that must be parsed case insensitive. 514 5.4. Manual checks 516 Manual checks using the OpenSSL command line tools in a POSIX shell: 518 $ printf "%s" "qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA=" \ 519 | openssl dgst -sha256 -binary \ 520 | openssl enc -base64 521 s/pmK/3grrz++29ce2/mQydzJuc7iqHn1nqcJiQTPMc= 523 $ printf "%s" "yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys=" \ 524 | openssl dgst -sha256 -binary \ 525 | openssl enc -base64 526 NSBTz7BfcQFTCen+U4lQ0VS8VIlZao2b8mxD/xJaaeE= 528 $ printf "%s" "sSkDke97Dh78/d+Diu1i3dQ2Fp/EMK3xE2GfEqZlvK8=" \ 529 | openssl dgst -sha256 -binary \ 530 | openssl enc -base64 531 RrKLp7YCQc9T8HmgSbxwIDlnCDWsgy1awqtiDuhedRo= 533 $ printf "%s" "aaaBBBcccDDDeeeFFF" \ 534 | openssl dgst -sha1 -binary \ 535 | openssl enc -base64 536 bNXHc6ohSmeHaRHHW56BIWZJt+4= 538 6. Obsolete Syntax 540 Implementations of earlier drafts of this specification defined a 541 different value for than this version. The following value 542 for is now deprecated and SHOULD NOT be generated anymore. 543 Serving agents SHOULD still accept it for a transition period as long 544 as the corresponding hash function is not considered unsafe (see 545 Section 7 for details), or already marked as OBSOLETE in the Netnews 546 Cancel-Lock hash algorithm registry (Section 8.3). 548 obs-scheme = "sha1" 550 It is important for backward compatibility that the deprecated value 551 for is not phased out too early. Security and compatibility 552 concerns should be carefully weighed before choosing to remove from existing implementations (or not implementing it in new 554 ones). 556 Earlier drafts of this specification allowed more liberal syntax for 557 : 559 obs-c-key-string = 1*base64-octet 560 base64-octet = ALPHA / DIGIT / "+" / "/" / "=" 562 SHOULD NOT be generated but MUST be accepted. 564 7. Security Considerations 566 The authentication system defined in this document provides no 567 integrity checking properties. Arbitrary modifications can be 568 applied to an article on its way through the network, regardless of 569 the presence of a Cancel-Key header field. A serving agent, who 570 receives an article that contains a Cancel-Key header field with a 571 matching element, only get the information that the 572 withdrawal of the target article was approved by a legitimate person 573 or agent. 575 Example: A valid element is extracted from a cancel control 576 article and inserted into a forged supersede article. All servers on 577 the network that receive the forged supersede article before the 578 cancel control article should accept the forged supersede. But 579 because everybody can post articles with forged identity information 580 in the header (same as with spam e-mail), the same result can be 581 achieved by sending a forged new article using no authentication 582 system at all. 584 For originator and integrity checks a signature based authentication 585 system is required (normally OpenPGP [RFC4880] is used for this 586 purpose). Both systems can be combined. 588 The important property of the hash function used for is the 589 preimage resistance. A successful preimage attack either reveals the 590 real Cancel-Key (that was used to create the Cancel-Lock of the 591 original article) or gives a different Cancel-Key (that matches a 592 Cancel-Lock too). This would break the authentication system defined 593 in this document. 595 Collision resistance of the hash function used for is less 596 important. Finding two elements for the Cancel-Key header 597 field that match to a element of an arbitrary Cancel-Lock 598 header field is not helpful to break the authentication system 599 defined in this document (if a specific article is defined as 600 target). Only collateral damage by arbitrary cancel or supersede is 601 possible. 603 Currently there is no known practicable preimage and second preimage 604 attack against the hash function SHA1. Therefore there is no hurry 605 to replace it. The reasons why this document specifies hash 606 functions from the SHA2 family are: 608 o The last draft for the authentication system defined in this 609 document is nearly two decades old. The client side 610 implementations are moving forward extremely slowly too 611 (newsreaders from the last millennium are still in heavy use). 613 What is defined today should be strong enough for at least the 614 next decades. 616 o The collision resistance of SHA1 is already broken, therefore it 617 is now obsolete for digital signatures as used in TLS. It is 618 intended that an implementation of the authentication system 619 defined in this document can share the same cryptographic library 620 functions that are used for TLS. 622 o It is intended that the same hash function can be used for 623 and (as base) for the HMAC that is suggested in 624 Section 4. See notes below for HMAC-MD5 and HMAC-SHA1. 626 o The SHA2 family of hash algorithms is widely supported by 627 cryptographic libraries. In contrast, SHA3 is currently not 628 supported by e.g. OpenSSL. 630 The operation HMAC(uid+mid, sec) as suggested in Section 4 must be 631 able to protect the local secret . The Message-ID is 632 public (in the Message-ID header field body) and is optional. 633 An attacker who wants to steal/use a local secret only need to break 634 this algorithm (regardless of ), because Cancel-Key header 635 fields are explicitly published for every request to cancel or 636 supersede existing articles. 638 Even if HMAC-MD5 and HMAC-SHA1 are not considered broken today, it is 639 desired to have some more security margin here. Breaking 640 only allows to authenticate a single forged cancel or supersede 641 request. With in hand it is possible to forge such requests 642 for all articles that contain Cancel-Lock header field bodies with 643 elements that are generated with this in the past. Changing 644 in regular intervals can be used to mitigate the potential 645 damage. 647 If an agent adds or appends multiple elements, it must not 648 use the same K for them (by using different secrets ). Adding 649 multiple elements with the same and the same K 650 makes no sense (would result in identical elements), 651 therefore the case with different is relevant: A preimage 652 attack on the different hash algorithms may be easier if the attacker 653 knows that the output of them was created with the same input. 655 If an implementation chooses to not implement the key calculation 656 algorithm recommended in Section 4, or to implement it with HMAC 657 based on a different hash function than , the key size used 658 should match the output size of the hash function used for . 660 8. IANA Considerations 662 IANA has registered the following header fields in the Permanent 663 Message Header Field Repository, in accordance with the procedures 664 set out in [RFC3864]: 666 Header field name: Cancel-Lock 667 Applicable protocol: netnews 668 Status: standard 669 Author/change controller: IETF 670 Specification document(s): This document 672 Header field name: Cancel-Key 673 Applicable protocol: netnews 674 Status: standard 675 Author/change controller: IETF 676 Specification document(s): This document 678 The Netnews Cancel-Lock hash algorithm registry will be maintained by 679 IANA. 681 The registry will be available at . 685 8.1. Algorithm Name Registration Procedure 687 IANA will register new Cancel-Lock hash algorithm names on a First 688 Come First Served basis, as defined in BCP 26 [RFC5226]. IANA has 689 the right to reject obviously bogus registration requests, but will 690 perform no review of claims made in the registration form. 692 Registration of a Netnews Cancel-Lock hash algorithm is requested by 693 filling in the following template and sending it via electronic mail 694 to IANA at : 696 Subject: Registration of Netnews Cancel-Lock hash algorithm X 697 Netnews Cancel-Lock hash algorithm name: 698 Security considerations: 699 Published specification (recommended): 700 Contact for further information: 701 Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE) 702 Owner/Change controller: 703 Note: (Any other information that the author deems relevant may be 704 added here.) 706 Any name that conforms to the syntax of a Netnews Cancel-Lock hash 707 algorithm (see definition of in Section 2) can be used. 709 Especially, Netnews Cancel-Lock algorithms are named by strings 710 consisting of letters, digits, hyphens and/or slashes. 712 Authors may seek community review by posting a specification of their 713 proposed algorithm as an Internet-Draft. Netnews Cancel-Lock hash 714 algorithms intended for widespread use should be standardized through 715 the normal IETF process, when appropriate. 717 The IESG is considered to be the owner of all Netnews Cancel-Lock 718 hash algorithms that are on the IETF Standards Track. 720 8.2. Change control 722 Once a Netnews Cancel-Lock hash algorithm registration has been 723 published by IANA, the owner may request a change to its definition. 724 The change request follows the same procedure as the initial 725 registration request. 727 The owner of a Netnews Cancel-Lock hash algorithm may pass 728 responsibility for the algorithm to another person or agency by 729 informing IANA; this can be done without discussion or review. 731 The IESG may reassign responsibility for a Netnews Cancel-Lock hash 732 algorithm. The most common case of this will be to enable changes to 733 be made to algorithms where the owner of the registration has died, 734 has moved out of contact, or is otherwise unable to make changes that 735 are important to the community. 737 Netnews Cancel-Lock hash algorithm registrations MUST NOT be deleted; 738 algorithms that are no longer believed appropriate for use can be 739 declared OBSOLETE by a change to their "intended usage" field; such 740 algorithms will be clearly marked in the registry published by IANA. 742 The IESG is considered to be the owner of all Netnews Cancel-Lock 743 hash algorithms that are on the IETF Standards Track. 745 8.3. Registration of the Netnews Cancel-Lock hash algorithms 747 This section gives a formal definition of the Netnews Cancel-Lock 748 hash algorithms as required by Section 8.1 for the IANA registry. 750 Netnews Cancel-Lock hash algorithm name: md5 751 Security considerations: See corresponding section of this document 752 Published specification: This document 753 Contact for further information: Author of this document 754 Intended usage: OBSOLETE 755 Owner/Change controller: IESG 756 Note: Do not use this algorithm anymore 757 Netnews Cancel-Lock hash algorithm name: sha1 758 Security considerations: See corresponding section of this document 759 Published specification: This document 760 Contact for further information: Author of this document 761 Intended usage: LIMITED USE 762 Owner/Change controller: IESG 763 Note: This algorithm is intended for backward compatibility 765 Netnews Cancel-Lock hash algorithm name: sha224 766 Security considerations: See corresponding section of this document 767 Published specification: This document 768 Contact for further information: Author of this document 769 Intended usage: LIMITED USE 770 Owner/Change controller: IESG 771 Note: sha256 should be used instead, this is a truncated variant of it 773 Netnews Cancel-Lock hash algorithm name: sha256 774 Security considerations: See corresponding section of this document 775 Published specification: This document 776 Contact for further information: Author of this document 777 Intended usage: COMMON 778 Owner/Change controller: IESG 779 Note: This algorithm is mandatory to implement 781 Netnews Cancel-Lock hash algorithm name: sha384 782 Security considerations: See corresponding section of this document 783 Published specification: This document 784 Contact for further information: Author of this document 785 Intended usage: LIMITED USE 786 Owner/Change controller: IESG 787 Note: sha512 should be used instead, this is a truncated variant of it 789 Netnews Cancel-Lock hash algorithm name: sha512 790 Security considerations: See corresponding section of this document 791 Published specification: This document 792 Contact for further information: Author of this document 793 Intended usage: COMMON 794 Owner/Change controller: IESG 795 Note: This algorithm is optional 797 9. References 799 9.1. Normative References 801 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 802 Requirement Levels", BCP 14, RFC 2119, 803 DOI 10.17487/RFC2119, March 1997, 804 . 806 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 807 Procedures for Message Header Fields", BCP 90, RFC 3864, 808 DOI 10.17487/RFC3864, September 2004, 809 . 811 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 812 "Randomness Requirements for Security", BCP 106, RFC 4086, 813 DOI 10.17487/RFC4086, June 2005, 814 . 816 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 817 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 818 . 820 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 821 IANA Considerations Section in RFCs", RFC 5226, 822 DOI 10.17487/RFC5226, May 2008, 823 . 825 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 826 Specifications: ABNF", STD 68, RFC 5234, 827 DOI 10.17487/RFC5234, January 2008, 828 . 830 [RFC5536] Murchison, K., Ed., Lindsey, C., and D. Kohn, "Netnews 831 Article Format", RFC 5536, DOI 10.17487/RFC5536, November 832 2009, . 834 [RFC5537] Allbery, R., Ed. and C. Lindsey, "Netnews Architecture and 835 Protocols", RFC 5537, DOI 10.17487/RFC5537, November 2009, 836 . 838 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 839 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 840 DOI 10.17487/RFC6234, May 2011, 841 . 843 9.2. Informative References 845 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 846 DOI 10.17487/RFC1321, April 1992, 847 . 849 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 850 Hashing for Message Authentication", RFC 2104, 851 DOI 10.17487/RFC2104, February 1997, 852 . 854 [RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 855 (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001, 856 . 858 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 859 Thayer, "OpenPGP Message Format", RFC 4880, 860 DOI 10.17487/RFC4880, November 2007, 861 . 863 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 864 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 865 RFC 6151, DOI 10.17487/RFC6151, March 2011, 866 . 868 [SHA] National Institute of Standards and Technology, "Secure 869 Hash Standard (SHS)", FIPS 180-4, DOI 10.6028/FIPS.180-4, 870 August 2015, . 873 [USEFOR-CANCEL-LOCK] 874 Lyall, S., "Cancel-Locks in Usenet articles.", Work in 875 Progress, November 1998. 877 Appendix A. Acknowledgements 879 The author acknowledges the original author of the Cancel-Lock 880 authentication system as documented in draft-ietf-usefor-cancel-lock: 881 Simon Lyall. He has written the original draft and former version 882 [USEFOR-CANCEL-LOCK] and approved the usage of his work for this 883 document. This document is mostly based on his work and was 884 originally intended as revision 02. It must be renamed because the 885 USEFOR IETF WG is now closed. 887 The author would like to thank the following individuals for 888 contributing their ideas and reviewing this specification: Russ 889 Allbery, Urs Janssen, Richard Kettlewell, Marcel Logen, Holger 890 Marzen, Dennis Preiser, Emil Schuster. And Peter Faust and Alfred 891 Peters for providing statistic data about the algorithms currently in 892 use. 894 Special thanks to the Document Shepherd, Julien Elie and to the 895 Responsible Area Director, Alexey Melnikov. 897 Appendix B. Document History (to be removed by RFC Editor before 898 publication) 900 B.1. Changes since -06 902 o Changed paragraph about key size in section Section 7. 904 o Added RFC4086 as normative reference. Changed wording from 905 "random" to "cryptographically random" with reference to RFC4086" 906 in section Section 4 (suggested by Eric Rescorla). 908 o Swapped parameters of HMAC() function in section Section 4 for 909 consistency with other RFCs (suggested by Eric Rescorla). 911 o Moved general description from section Section 3 to section 912 Section 1 (suggested by Eric Rescorla). 914 o Changed wording in Section 3 (suggested by Eric Rescorla). 916 o Replaced the word "required" with "requested" in section Section 1 917 (reported by Warren Kumari). 919 o Syntax definition modified in section Section 2 because of erratum 920 5116 in RFC5536 (reported by Paul Kyzivat, using words suggested 921 by Alexey Melnikov). 923 o Fixed spelling in different sections (reported by Julien Elie). 925 o Added text why agents must use different K values if they add 926 multiple elements to Section 7. 928 o Modified text for unique K in Section 4 to make it clear that the 929 requirement targets single agents that add multiple 930 elements (suggested by Julien Elie). 932 o Moved text for unique K from Section 2.1 to Section 3.1 and 933 Section 3.2 to make it clear that the requirement targets single 934 agents that add multiple elements (suggested by Julien 935 Elie). 937 B.2. Changes since -05 939 o Modified text in Section 3.1 and Section 3.2 to make it clear that 940 an injecting agent only must be able to authenticate the poster if 941 it wants to act representative for him. 943 o Added/moved general description text to Section 3 to make things 944 easier to understand (suggested by GEN-Art Last Call review). 946 o Removed text for importance of second preimage resistance in 947 Section 7 (suggested by Secdir review). 949 o Added note that local secret must be random in Section 4 950 (suggested by Secdir review). 952 o Added note that is not allowed to contain angle brackets in 953 Section 4 (suggested by Secdir review). 955 o Changed copyright notice (because Simon Lyall has licensed his 956 work to the IETF Trust in the meantime). 958 o Fixed spelling in Section 3.3, Section 3.4, Section 7 and 959 Section 8.1 (reported by Julien Elie). 961 o Changed proposed location of IANA registry in Section 8. Should 962 be more consistent with existing registries now (suggested by 963 Julien Elie). 965 o Added note to not use the same secret if multiple 966 elements are added in Section 2.1 and Section 4 (suggested by 967 Secdir review). 969 o Unified the term "cancel control article". 971 o Added notes for impersonation and content forging attacks in 972 Section 7. 974 o Description text modified in Section 1. 976 B.3. Changes since -04 978 o Added note that the IESG is the owner of all Netnews Cancel-Lock 979 hash algorithms that are on the IETF Standards Track in 980 Section 8.1. 982 o Changed the algorithm from informative to RECOMMENDED in 983 Section 4. 985 o Replaced "code-string" with "c-lock-string" for Step 2 in 986 Section 3.5. 988 o Replaced "code-string" with "c-key-string" for Step 1 in 989 Section 3.5. 991 o Added a short explanation in Section 3.3. 993 o Added a short explanation in Section 3.1. 995 o Replaced link to RFC2045 with link to RFC4648 in Section 2. 997 o Replaced normative reference RFC2045 (for Base64 algorithm) with 998 RFC4648. 1000 o Added case insensitivity note in Section 5.3. 1002 o RFC6234 (listed in the downref registry) is now a normative 1003 reference (formerly informative) as recommended by Shepherd Write- 1004 Up. 1006 o NIST SHS standard is now an informative reference (formerly 1007 normative) as recommended by Shepherd Write-Up. 1009 o Added "sha224" and "sha384" schemes in Section 8.3 (because 1010 implementations exists that supports them). 1012 o Refer to Section 8.3 instead of Section 8.1 for hash algorithm 1013 registry. 1015 o Fixed some typos. 1017 o Fixed line length in Section 5.1. 1019 B.4. Changes since -03 1021 o Added note for change interval of in Section 7. 1023 o Changed wording in Section 7. 1025 o Splitted Section 5 into multiple subsections. 1027 o Added example with UID in Section 5. 1029 o Changed "SHOULD NOT" to uppercase in Section 6. 1031 o Reformatted Section 8, Section 8.1 and Section 8.3. 1033 o Fixed spelling in Section 4. 1035 B.5. Changes since -02 1037 o Added Section 8.2. 1039 o Added note about algorithm names in Section 8.1. 1041 o Added "/" to scheme-char in Section 2. 1043 o Removed case sensitivity of scheme and normative reference to 1044 RFC7405 in Section 2 again. 1046 o Added "sha512" scheme in Section 2. 1048 o Changed wording in Section 8.3. 1050 o Fixed typo "canceling" in Section 5. 1052 o Changed calculation formulas to use "Base64" in Section 2.1 and 1053 Section 2.2. 1055 o Added obsolete algorithm "md5" in Section 8.3. 1057 o Added note that posting agents should add the Message-ID header 1058 field to proto-articles and use its content for in 1059 Section 4. 1061 o Added part to key calculation in Section 4. 1063 o Added note to generate CFWS without comments in Section 2.1 and 1064 Section 2.2. 1066 o Changed ABNF to allow CFWS at the beginning of header fields in 1067 Section 2.1 and Section 2.2. 1069 o Changed wording for "header"/"header field"/"header field body". 1071 o Added Section 3.4. 1073 o Changed wording in Section 3.1. 1075 o Allowed additional whitespace at the beginning of header fields in 1076 Section 2.1 and Section 2.2. 1078 o Changed definition of "c-key-string" in Section 2.2. 1080 o Added "obs-c-key-string" to Section 6. 1082 o Fixed typo in Section 2.2 ("c-lock" replaced by "c-key"). 1084 o Added key length recommendation in Section 7. 1086 o Renamed "sha-256" scheme to "sha256". 1088 o Modified header and abstract section to list RFC5537 as updated by 1089 this document again. 1091 o Added "USEFOR-CANCEL-LOCK" as informative reference. 1093 o Changed wording in Section 4. 1095 B.6. Changes since -01 1097 o Changed wording in Section 7. 1099 o Added example for HMAC calculation in Section 5. 1101 o Changed wording in Section 4. 1103 o Added use cases to Section 3.2. 1105 o Replaced wording "injecting-agent" by "injecting agent". 1107 o Added Definition for "LOWER" in Section 2. 1109 o Added Section 8.3. 1111 o Added Section 8.1. 1113 o Added new entries for header field registry in Section 8. 1115 o Removed recommendation that moderators and injecting agents should 1116 add only one Cancel-Lock or Cancel-Key resprectively to the list 1117 in Section 3.1, Section 3.2 and Section 3.3. 1119 o Added missing headerfield termination to Section 2.1 and 1120 Section 2.2. 1122 o Removed definition for "code-string" from Section 2. Added 1123 stricter definition "c-lock-string" to Section 2.1. Added 1124 backward compatible definition "c-key-string" to Section 2.2. 1126 o Use different wording in Section 2.2. 1128 o Changed wording to reflect that an injecting agent is allowed to 1129 create Cancel-Lock headerfields in Section 2.1. 1131 o Fixed wording and typo in Section 2. 1133 o Added normative reference to RFC7405 because case-sensitivity is 1134 used in ABNF. 1136 o Added reference to RFC5536 (Section 2.2) in Section 2. 1138 o Added references to RFC4880 and RFC5537 in Section 1. 1140 o Replaced the wordings "remove" by "cancel" and "replace" by 1141 "supersede". 1143 o Modified header and abstract section to no longer list RFC5536 and 1144 RFC5537 as updated by this document. 1146 B.7. Changes since -00 1148 o Added additional note that deprecated "scheme" values should be 1149 preserved for backward compatibility as long as reasonable. 1151 o Removed deprectated scheme "md5" (not in use anymore). 1153 o Added descriptions how to generate "code-string" to Section 2.1 1154 and Section 2.2. 1156 o Removed length limitiation in ABNF of "scheme". 1158 o Changed copyright notice to use text from TLP section 6.c.iii. 1160 o Removed references from "abstract" section. 1162 o Changed "SHOULD NOT" to uppercase in Section 6. 1164 o Added line wraps to CLI commands in Section 5. 1166 B.8. Changes since draft-ietf-usefor-cancel-lock-01 1168 o Renamed document because the USEFOR IETF WG is now closed. 1170 o Added more details how to check Cancel-Key header fields in 1171 Section 3.5. 1173 o Added more details to Section 7. 1175 o Added updated ABNF for Cancel-Lock and Cancel-Key header fields. 1177 o Deprecated "md5" and "sha1" schemes. 1179 o Added "sha-256" scheme. 1181 o Reworded the abstract section and added references. 1183 o Added note to other authentication systems to Section 1. 1185 o Added command line check examples to Section 5. 1187 B.9. Changes since draft-ietf-usefor-cancel-lock-00 1189 o References to SHA-160 changed to SHA1 1191 o "scheme" is now a case insensitive token and the number "1" has 1192 been changed to "sha1". 1194 o Added some examples and fixed the section numbering. 1196 o Updated 2nd paragraph on section 2.2 to make clear what exactly is 1197 being hashed and how. 1199 o Changed paragraph 2 of 3.1 to discourage injection agents from 1200 adding the header. 1202 o Removed the Clue-string as this complicated the scheme without 1203 adding realistic functionality 1205 o Moderators can now add these headers under the same conditions as 1206 injection agents. 1208 Author's Address 1210 Michael Baeuerle 1211 STZ Elektronik 1212 Hofener Weg 33C 1213 Remseck, Baden-Wuerttemberg 71686 1214 Germany 1216 Fax: +49 7146 999061 1217 EMail: michael.baeuerle@stz-e.de