idnits 2.17.1 draft-baeuerle-netnews-cancel-lock-05.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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 30, 2017) is 2520 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) May 30, 2017 5 Intended status: Standards Track 6 Expires: December 1, 2017 8 Cancel-Locks in Netnews articles 9 draft-baeuerle-netnews-cancel-lock-05 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 http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on December 1, 2017. 34 Copyright Notice 36 Copyright (c) 2017 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 This document may contain material from IETF Documents or IETF 50 Contributions published or made publicly available before November 51 10, 2008. The person(s) controlling the copyright in some of this 52 material may not have granted the IETF Trust the right to allow 53 modifications of such material outside the IETF Standards Process. 54 Without obtaining an adequate license from the person(s) controlling 55 the copyright in such materials, this document may not be modified 56 outside the IETF Standards Process, and derivative works of it may 57 not be created outside the IETF Standards Process, except to format 58 it for publication as an RFC or to translate it into languages other 59 than English. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 65 1.2. Author's Note . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2.1. Cancel-Lock . . . . . . . . . . . . . . . . . . . . . . . 4 68 2.2. Cancel-Key . . . . . . . . . . . . . . . . . . . . . . . 5 69 3. Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.1. Adding an initial Cancel-Lock header field to a proto- 71 article . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 3.2. Extending the Cancel-Lock header field of a proto-article 6 73 3.3. Adding a Cancel-Key header field to a proto-article . . . 6 74 3.4. Extending the Cancel-Key header field of a proto-article 7 75 3.5. Check a Cancel-Key header field . . . . . . . . . . . . . 7 76 4. Calculating the key data . . . . . . . . . . . . . . . . . . 8 77 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 5.1. Without UID . . . . . . . . . . . . . . . . . . . . . . . 9 79 5.2. With UID . . . . . . . . . . . . . . . . . . . . . . . . 10 80 5.3. Other examples . . . . . . . . . . . . . . . . . . . . . 10 81 5.4. Manual checks . . . . . . . . . . . . . . . . . . . . . . 11 82 6. Obsolete Syntax . . . . . . . . . . . . . . . . . . . . . . . 12 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 85 8.1. Algorithm Name Registration Procedure . . . . . . . . . . 14 86 8.2. Change control . . . . . . . . . . . . . . . . . . . . . 15 87 8.3. Registration of the Netnews Cancel-Lock hash algorithms . 15 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 89 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 90 9.2. Informative References . . . . . . . . . . . . . . . . . 17 91 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19 92 Appendix B. Document History (to be removed by RFC Editor before 93 publication) . . . . . . . . . . . . . . . . . . . . 19 94 B.1. Changes since -04 . . . . . . . . . . . . . . . . . . . . 19 95 B.2. Changes since -03 . . . . . . . . . . . . . . . . . . . . 20 96 B.3. Changes since -02 . . . . . . . . . . . . . . . . . . . . 20 97 B.4. Changes since -01 . . . . . . . . . . . . . . . . . . . . 22 98 B.5. Changes since -00 . . . . . . . . . . . . . . . . . . . . 23 99 B.6. Changes since draft-ietf-usefor-cancel-lock-01 . . . . . 23 100 B.7. Changes since draft-ietf-usefor-cancel-lock-00 . . . . . 24 101 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24 103 1. Introduction 105 The authentication system defined in this document is intended to be 106 used as a simple method to verify that the author of an article which 107 cancels ([RFC5537] Section 5.3) or supersedes ([RFC5537] Section 5.4) 108 another one is either the poster, posting agent, moderator or 109 injecting agent that processed the original article when it was in 110 its proto-article form. 112 One property of this system is that it prevents tracking of 113 individual users. 115 There are other authentication systems available with different 116 properties. When everybody should be able to verify who the 117 originator is, e.g. for control messages to add or remove newsgroups 118 ([RFC5537] Section 5.2), an OpenPGP [RFC4880] signature is suited. 120 1.1. Conventions Used in This Document 122 Any term not defined in this document has the same meaning as it does 123 in [RFC5536] or [RFC5537]. 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 127 "OPTIONAL" in this document are to be interpreted as described in 128 [RFC2119]. 130 1.2. Author's Note 132 Please write the letters "ae" in "Baeuerle" as an a-umlaut (U+00E4, 133 "ä" in XML), the first letter in "Elie" with an acute accent 134 (U+00C9, "É" in XML), the letters "ss" in Janssen as an eszett 135 (U+00DF, "ß" in XML) and the letters "ue" in Baden-Wuerttemberg 136 as an u-umlaut (U+00FC, "ü" in XML) wherever this is possible. 138 2. Header Fields 140 This section describes the formal syntax of the new header fields 141 using ABNF [RFC5234]. It extends the syntax in Section 3 of 142 [RFC5536] and non-terminals not defined in this document are defined 143 there. The [RFC5536] ABNF should be imported first before attempting 144 to validate these rules. 146 The new header fields Cancel-Lock and Cancel-Key are defined by this 147 document, they follow the rules described in [RFC5536] Section 2.2: 149 fields =/ *( cancel-lock / cancel-key ) 151 Each of these header fields MUST NOT occur more than once in an 152 article. 154 Both new header field bodies contain lists of encoded values. Every 155 entry is based on a : 157 scheme = "sha256" / "sha512" / 1*scheme-char / obs-scheme 158 scheme-char = ALPHA / DIGIT / "-" / "/" 160 The hash algorithms for are defined in [RFC6234], see also 161 [RFC1321] and [RFC6151] for MD5, [RFC3174] for SHA1 and [SHA] for the 162 SHA2 family. The Base64 encoding used is defined in Section 4 of 163 [RFC4648]. 165 This document defines two values for : "sha256" and "sha512". 166 The hash algorithm "sha256" is mandatory to implement. 168 Because the hash algorithm for cannot be negotiated, 169 unnecessary proliferation of hash algorithms should be avoided. The 170 hash algorithms "sha224" and "sha384" are only added to the Netnews 171 Cancel-Lock hash algorithm registry (Section 8.3) because 172 implementations exist that supports them. Implementations SHOULD NOT 173 use the hash algorithms "sha224" and "sha384" to generate . 175 2.1. Cancel-Lock 177 cancel-lock = "Cancel-Lock:" SP c-lock-list CRLF 178 c-lock-list = [CFWS] c-lock *(CFWS c-lock) [CFWS] 179 c-lock = scheme ":" c-lock-string 180 c-lock-string = *(4base64-char) [base64-terminal] 181 base64-char = ALPHA / DIGIT / "+" / "/" 182 base64-terminal = 2base64-char "==" / 3base64-char "=" 184 Comments in CFWS can cause interoperability problems, so comments 185 SHOULD NOT be generated but MUST be accepted. 187 If is not supported by an implementation, the corresponding 188 element MUST be skipped and potential following 189 elements MUST NOT be ignored. 191 is the Base64 encoded output of a hash operation 192 (defined by ) of the Base64 encoded key "K" that is intended 193 to authenticate the person or agent that created or processed 194 respectively the proto-article up to injection (inclusively): 196 Base64(hash(Base64(K))) 198 Because of the one-way nature of the hash operation the key "K" is 199 not revealed. 201 2.2. Cancel-Key 203 cancel-key = "Cancel-Key:" SP c-key-list CRLF 204 c-key-list = [CFWS] c-key *(CFWS c-lock) [CFWS] 205 c-key = scheme ":" c-key-string 206 c-key-string = c-lock-string / obs-c-key-string 208 Comments in CFWS can cause interoperability problems, so comments 209 SHOULD NOT be generated but MUST be accepted. 211 If is not supported by an implementation, the corresponding 212 element MUST be skipped and potential following 213 elements MUST NOT be ignored. 215 is the Base64 encoded key "K" that was used to create 216 the element in the Cancel-Lock header field body (as defined 217 in Section 2.1 of this document) of the original article: 219 Base64(K) 221 The relaxed syntax definition of above is required for 222 backward compatibility with implementations that are not compliant 223 with this specification. Compliant implementations SHOULD generate 224 valid Base64 (that is to say the syntax of as defined 225 in Section 2.1 of this document) and MUST accept strings of 226 characters (that is to say the syntax of as defined in Section 6 of this document). 229 3. Use 231 3.1. Adding an initial Cancel-Lock header field to a proto-article 233 The Cancel-Lock header field contains hashes of secret strings. This 234 secret strings can later be used to authenticate a cancel or 235 supersede request. 237 A Cancel-Lock header field MAY be added to a proto-article by the 238 poster or posting agent which will include one or more 239 elements. 241 If the poster or posting agent doesn't add a Cancel-Lock header field 242 to a proto-article, then an injecting agent (or moderator) MAY add 243 one or more provided that it positively authenticates the author. 244 The injecting agent (or moderator) MUST NOT add this header field to 245 a proto-article unless it is able to authenticate all cancelling or 246 superseding attempts from the poster and automatically add a working 247 Cancel-Key header field or extend an existing one for such proto- 248 articles. 250 Other agents MUST NOT add this header field to articles or proto- 251 articles that they process. 253 3.2. Extending the Cancel-Lock header field of a proto-article 255 If a Cancel-Lock header field has already been added to a proto- 256 article then any agent further processing the proto-article up to the 257 injecting agent (inclusively) MAY append additional elements 258 to those already in the header field body. 260 Use cases for extending the Cancel-Lock header field body: 262 o A moderator wants the ability to cancel articles after approving 263 them. 265 o An injecting agent acts representitive for posting agents without 266 support for the autentication system described in this document. 268 o A news administrator wants the ability to cancel articles that 269 were injected by its system (because they e.g. violate its abuse 270 policy). 272 Once an article is injected then this header field MUST NOT be 273 altered. In particular, relaying agents beyond the injecting agent 274 MUST NOT alter it. 276 3.3. Adding a Cancel-Key header field to a proto-article 278 The Cancel-Key header field contains one or more of the secret 279 strings that were used to create the Cancel-Lock header field of the 280 original article. Knowledge of at least one of the secret strings is 281 required to create a match for successful authentication. 283 A Cancel-Key header field MAY be added to a proto-article containing 284 a Control or Supersedes header field by the poster or posting agent 285 which will include one or more elements. They will 286 correspond to some or all of the elements in the article 287 referenced by the Control (with a "cancel" command as defined in 288 [RFC5537]) or Supersedes header field. 290 If, as mentioned in Section 3.1 an injecting agent (or moderator) has 291 added a Cancel-Lock header field to an article listed in the Control 292 (with "cancel" command as defined in [RFC5537]) or Supersedes header 293 field then (given that it authenticates the poster as being the same 294 as the poster of the original article) it MUST add the Cancel-Key 295 header field with at least one element that correspond to 296 that article. 298 Other agents MUST NOT alter this header field. 300 3.4. Extending the Cancel-Key header field of a proto-article 302 If a Cancel-Key header field has already been added to a proto- 303 article then any agent further processing the proto-article up to the 304 injecting agent (inclusively) MAY append additional elements 305 to those already in the header field body. 307 If, as mentioned in Section 3.2 an injecting agent (or moderator) has 308 extended the Cancel-Lock header field in an article listed in the 309 Control (with "cancel" command as defined in [RFC5537]) or Supersedes 310 header field then (given that it authenticates the poster as being 311 the same as the poster of the original article) it MUST extend the 312 Cancel-Key header field body with at least one element that 313 correspond to that article. 315 Once an article is injected then this header field MUST NOT be 316 altered. In particular, relaying agents beyond the injecting agent 317 MUST NOT alter it. 319 3.5. Check a Cancel-Key header field 321 When a serving agent receives an article that attempts to cancel or 322 supersede a previous article via Control (with a "cancel" command as 323 defined in [RFC5537]) or Supersedes header field, the system defined 324 in this document can be used for authentication. The general 325 handling of articles containing such attempts as defined in [RFC5537] 326 is not changed by this document. 328 To process the authentication, the received article must contain a 329 Cancel-Key header field and the original article a Cancel-Lock header 330 field. If this is not the case, the authentication is not possible 331 (failed). 333 For the authentication check, every supported element from 334 the received article is processed as follows: 336 1. The part of the element is hashed using 337 the algorithm defined by its part. 339 2. For all elements with the same in the original 340 article their part is compared to the calculated 341 hash. 343 3. If one is equal, the authentication is passed and the processing 344 of further elements can be aborted. 346 4. If no match was found and there are no more elements to 347 process, the authentication failed. 349 4. Calculating the key data 351 The following algorithm is RECOMMENDED to calculate the key "K" based 352 on a local secret . 354 The result of the function: 356 K = HMAC(uid+mid, sec) 358 is the key "K" for an article with Message-ID that belongs to 359 the User-ID (e.g. the login name of the user). HMAC is 360 outlined in [RFC2104]. HMAC is computed over the data 361 (with '+' representing the concatenation operation), using as a 362 secret key held locally that can be used for multiple articles. This 363 method removes the need for a per-article database containing the 364 keys used for every article. [[Q1: Security review: Some existing 365 implementations concatenates the part with instead of 366 . This variant was not used to ensure that is directly 367 used as HMAC key (to avoid confusion with the length considerations 368 below). ]] 370 A posting agent must add the Message-ID header field to the proto- 371 article itself and use the content of the header field body as 372 (including literal angle brackets). 374 A posting agent, that uses a dedicated local secret for every 375 user, should use an empty string for the part. 377 The local secret should have a length of at least the output 378 size of the hash function that is used by HMAC (256 bit / 32 octets 379 for SHA256). If the secret is not a random value, but e.g. some sort 380 of human readable password, it should be much longer. In any case it 381 is important that this secret can not be guessed. 383 Note that the hash algorithm used as base for the HMAC operation is 384 not required to be the same as specified by . An agent that 385 verifies a Cancel-Key header field body simply checks whether one of 386 its elements matches one of the elements with the 387 same in the Cancel-Lock header field body of the original 388 article. 390 Common libraries like OpenSSL can be used for the cryptographic 391 operations. 393 5. Examples 395 5.1. Without UID 397 Example data for creation of a element with HMAC-SHA256 and 398 empty string as (as suggested in Section 4 for posting agents): 400 Message-ID: <12345@mid.example> 402 mid: <12345@mid.example> 403 sec: ExampleSecret 404 K : HMAC-SHA256(mid, sec) ;mid used as data, sec as secret key 406 Calculation of Base64(K) using the OpenSSL command line tools in a 407 POSIX shell: 409 $ printf "%s" "<12345@mid.example>" \ 410 | openssl dgst -sha256 -hmac "ExampleSecret" -binary \ 411 | openssl enc -base64 412 qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA= 414 This can be used as for cancelling or superseding the 415 article <12345@mid.example>. 417 Calculation of Base64(SHA256(Base64(K))) required for 418 using the OpenSSL command line tools in a POSIX shell: 420 $ printf "%s" "qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA=" \ 421 | openssl dgst -sha256 -binary \ 422 | openssl enc -base64 423 s/pmK/3grrz++29ce2/mQydzJuc7iqHn1nqcJiQTPMc= 425 Inserted into the Cancel-Lock header field body of article 426 <12345@mid.example> it looks like this: 428 Cancel-Lock: sha256:s/pmK/3grrz++29ce2/mQydzJuc7iqHn1nqcJiQTPMc= 430 Inserted into the Cancel-Key header field body of an article that 431 should cancel or supersede article <12345@mid.example> it looks like 432 this: 434 Cancel-Key: sha256:qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA= 436 5.2. With UID 438 Example data for creation of a element with HMAC-SHA256 and 439 "JaneDoe" as (as suggested in Section 4): 441 Message-ID: <12345@mid.example> 443 uid: JaneDoe 444 mid: <12345@mid.example> 445 sec: AnotherSecret 446 K : HMAC-SHA256(uid+mid, sec) ;uid+mid as data, sec as secret key 448 Calculation of Base64(K) using the OpenSSL command line tools in a 449 POSIX shell: 451 $ printf "%s" "JaneDoe<12345@mid.example>" \ 452 | openssl dgst -sha256 -hmac "AnotherSecret" -binary \ 453 | openssl enc -base64 454 yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys= 456 This can be used as for cancelling or superseding the 457 article <12345@mid.example>. 459 Calculation of Base64(SHA256(Base64(K))) required for 460 using the OpenSSL command line tools in a POSIX shell: 462 $ printf "%s" "yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys=" \ 463 | openssl dgst -sha256 -binary \ 464 | openssl enc -base64 465 NSBTz7BfcQFTCen+U4lQ0VS8VIlZao2b8mxD/xJaaeE= 467 Inserted into the Cancel-Lock header field body of article 468 <12345@mid.example> it looks like this: 470 Cancel-Lock: sha256:NSBTz7BfcQFTCen+U4lQ0VS8VIlZao2b8mxD/xJaaeE= 472 Inserted into the Cancel-Key header field body of an article that 473 should cancel or supersede article <12345@mid.example> it looks like 474 this: 476 Cancel-Key: sha256:yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys= 478 5.3. Other examples 480 Other matching pair of Cancel-Lock and Cancel-Key header fields: 482 Cancel-Lock: sha256:RrKLp7YCQc9T8HmgSbxwIDlnCDWsgy1awqtiDuhedRo= 483 Cancel-Key: sha256:sSkDke97Dh78/d+Diu1i3dQ2Fp/EMK3xE2GfEqZlvK8= 485 With obsolete syntax (uses a with invalid/missing 486 Base64 padding): 488 Cancel-Lock: sha1:bNXHc6ohSmeHaRHHW56BIWZJt+4= 489 Cancel-Key: ShA1:aaaBBBcccDDDeeeFFF 491 Let's assume that all the examples above are associated to the same 492 article (e.g. created by different agents): 494 Cancel-Lock: sha256:s/pmK/3grrz++29ce2/mQydzJuc7iqHn1nqcJiQTPMc= 495 sha256:NSBTz7BfcQFTCen+U4lQ0VS8VIlZao2b8mxD/xJaaeE= 496 sha256:RrKLp7YCQc9T8HmgSbxwIDlnCDWsgy1awqtiDuhedRo= 497 sha1:bNXHc6ohSmeHaRHHW56BIWZJt+4= 498 Cancel-Key: sha256:qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA= 499 sha256:yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys= 500 sha256:sSkDke97Dh78/d+Diu1i3dQ2Fp/EMK3xE2GfEqZlvK8= 501 ShA1:aaaBBBcccDDDeeeFFF 503 Remember that must be parsed case insensitive. 505 5.4. Manual checks 507 Manual checks using the OpenSSL command line tools in a POSIX shell: 509 $ printf "%s" "qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA=" \ 510 | openssl dgst -sha256 -binary \ 511 | openssl enc -base64 512 s/pmK/3grrz++29ce2/mQydzJuc7iqHn1nqcJiQTPMc= 514 $ printf "%s" "yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys=" \ 515 | openssl dgst -sha256 -binary \ 516 | openssl enc -base64 517 NSBTz7BfcQFTCen+U4lQ0VS8VIlZao2b8mxD/xJaaeE= 519 $ printf "%s" "sSkDke97Dh78/d+Diu1i3dQ2Fp/EMK3xE2GfEqZlvK8=" \ 520 | openssl dgst -sha256 -binary \ 521 | openssl enc -base64 522 RrKLp7YCQc9T8HmgSbxwIDlnCDWsgy1awqtiDuhedRo= 524 $ printf "%s" "aaaBBBcccDDDeeeFFF" \ 525 | openssl dgst -sha1 -binary \ 526 | openssl enc -base64 527 bNXHc6ohSmeHaRHHW56BIWZJt+4= 529 6. Obsolete Syntax 531 Implementations of earlier drafts of this specification defined a 532 different value for than this version. The following value 533 for is now deprecated and SHOULD NOT be generated anymore. 534 Serving agents SHOULD still accept it for a transition period as long 535 as the corresponding hash function is not considered unsafe (see 536 Section 7 for details), or already marked as OBSOLETE in the Netnews 537 Cancel-Lock hash algorithm registry (Section 8.3). 539 obs-scheme = "sha1" 541 It is important for backward compatibility that the deprecated value 542 for is not phased out too early. Security and compatibility 543 concerns should be carefully weighed before choosing to remove from existing implementations (or not implementing it in new 545 ones). 547 Earlier drafts of this specification allowed more liberal syntax for 548 : 550 obs-c-key-string = 1*base64-octet 551 base64-octet = ALPHA / DIGIT / "+" / "/" / "=" 553 SHOULD NOT be generated but MUST be accepted. 555 7. Security Considerations 557 The important properties of the hash function used for are 558 the preimage and second preimage resistance. A successful preimage 559 attack would reveal the real element that was used to 560 create the Cancel-Lock header field body of the original article. A 561 successful second preimage attack would allow to create a new, 562 different element that, if used in the Cancel-Key 563 header field body, matches a element in the Cancel- 564 Lock header field body of the original article too. Both cases would 565 break the authentication system defined in this document. 567 Collision resistance of the hash function used for is less 568 important. Finding two elements for the Cancel-Key header 569 field that match to a element of an arbitrary Cancel-Lock 570 header field is not helpful to break the authentication system 571 defined in this document (if a specific article is defined as 572 target). Only collateral damage by arbitrary cancel or supersede is 573 possible. 575 Currently there is no known practicable preimage and second preimage 576 attack against the hash function SHA1. Therefore there is no hurry 577 to replace it. The reasons why this document specifies hash 578 functions from the SHA2 family are: 580 o The last draft for the authentication system defined in this 581 document is nearly two decades old. The client side 582 implementations are moving forward extremely slowly too 583 (newsreaders from the last millennium are still in heavy use). 584 What is defined today should be strong enough for at least the 585 next decades. 587 o The collision resistance of SHA1 is already broken, therefore it 588 is now obsolete for digital signatures as used in TLS. It is 589 intended that an implementation of the authentication system 590 defined in this document can share the same cryptographic library 591 functions that are used for TLS. 593 o It is intended that the same hash function can be used for 594 and (as base) for the HMAC that is suggested in 595 Section 4. See notes below for HMAC-MD5 and HMAC-SHA1. 597 o The SHA2 family of hash algorithms is widely supported by 598 cryptographic libraries. In contrast, SHA3 is currently not 599 supported by e.g. OpenSSL. 601 The operation HMAC(uid+mid, sec) as suggested in Section 4 must be 602 able to protect the local secret . The Message-ID is 603 public (in the Message-ID header field body) and is optional. 604 An attacker who wants to steal/use a local secret only need to break 605 this algorithm (regardless of ), because Cancel-Key header 606 fields are explicitly published for every request to cancel or 607 supersede existing articles. 609 Even if HMAC-MD5 and HMAC-SHA1 are not considered broken today, it is 610 desired to have some more security margin here. Breaking 611 only allows to authenticate a single forged cancel or supersede 612 request. With in hand it is possible to forge such requests 613 for all articles that contain Cancel-Lock header field bodies with 614 elements that are generated with this in the past. Changing 615 in regular intervals can be used to mitigate the potential 616 damage. 618 If an implementation chooses to not implement the key calculation 619 algorithm recommended in Section 4, or to implement it with HMAC 620 based on a different hash function than , the key size used 621 should be at least 128 bit with "sha256" for and at least 80 622 bit with "sha1" for . [[Q2: Security review: Should these 623 recommendations remain in the document, or does an RFC exist to refer 624 to with regards to security recommendations? ]] 626 8. IANA Considerations 628 IANA has registered the following header fields in the Permanent 629 Message Header Field Repository, in accordance with the procedures 630 set out in [RFC3864]: 632 Header field name: Cancel-Lock 633 Applicable protocol: netnews 634 Status: standard 635 Author/change controller: IETF 636 Specification document(s): This document 638 Header field name: Cancel-Key 639 Applicable protocol: netnews 640 Status: standard 641 Author/change controller: IETF 642 Specification document(s): This document 644 The Netnews Cancel-Lock hash algorithm registry will be maintained by 645 IANA. 647 The registry will be available at . 650 8.1. Algorithm Name Registration Procedure 652 IANA will register new Cancel-Lock hash algorithm names on a First 653 Come First Served basis, as defined in BCP 26 [RFC5226]. IANA has 654 the right to reject obviously bogus registration requests, but will 655 perform no review of claims made in the registration form. 657 Registration of a Netnews Cancel-Lock hash algorithm is requested by 658 filling in the following template and sending it via electronic mail 659 to IANA at : 661 Subject: Registration of Netnews Cancel-Lock hash algorithm X 662 Netnews Cancel-Lock hash algorithm name: 663 Security considerations: 664 Published specification (recommended): 665 Contact for further information: 666 Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE) 667 Owner/Change controller: 668 Note: (Any other information that the author deems relevant may be 669 added here.) 671 Any name that conforms to the syntax of a Netnews Cancel-Lock 672 algorithm Section 2 can be used. Especially, Netnews Cancel-Lock 673 algorithms are named by strings consisting of letters, digits, 674 hyphens and/or slashes. 676 Authors may seek community review by posting a specification of their 677 proposed algorithm as an Internet-Draft. Netnews Cancel-Lock hash 678 algorithms intended for widespread use should be standardized through 679 the normal IETF process, when appropriate. 681 The IESG is considered to be the owner of all Netnews Cancel-Lock 682 hash algorithms that are on the IETF Standards Track. 684 8.2. Change control 686 Once a Netnews Cancel-Lock hash algorithm registration has been 687 published by IANA, the owner may request a change to its definition. 688 The change request follows the same procedure as the initial 689 registration request. 691 The owner of a Netnews Cancel-Lock hash algorithm may pass 692 responsibility for the algorithm to another person or agency by 693 informing IANA; this can be done without discussion or review. 695 The IESG may reassign responsibility for a Netnews Cancel-Lock hash 696 algorithm. The most common case of this will be to enable changes to 697 be made to algorithms where the owner of the registration has died, 698 has moved out of contact, or is otherwise unable to make changes that 699 are important to the community. 701 Netnews Cancel-Lock hash algorithm registrations MUST NOT be deleted; 702 algorithms that are no longer believed appropriate for use can be 703 declared OBSOLETE by a change to their "intended usage" field; such 704 algorithms will be clearly marked in the registry published by IANA. 706 The IESG is considered to be the owner of all Netnews Cancel-Lock 707 hash algorithms that are on the IETF Standards Track. 709 8.3. Registration of the Netnews Cancel-Lock hash algorithms 711 This section gives a formal definition of the Netnews Cancel-Lock 712 hash algorithms as required by Section 8.1 for the IANA registry. 714 Netnews Cancel-Lock hash algorithm name: md5 715 Security considerations: See corresponding section of this document 716 Published specification: This document 717 Contact for further information: Author of this document 718 Intended usage: OBSOLETE 719 Owner/Change controller: IESG 720 Note: Do not use this algorithm anymore 721 Netnews Cancel-Lock hash algorithm name: sha1 722 Security considerations: See corresponding section of this document 723 Published specification: This document 724 Contact for further information: Author of this document 725 Intended usage: LIMITED USE 726 Owner/Change controller: IESG 727 Note: This algorithm is intended for backward compatibility 729 Netnews Cancel-Lock hash algorithm name: sha224 730 Security considerations: See corresponding section of this document 731 Published specification: This document 732 Contact for further information: Author of this document 733 Intended usage: LIMITED USE 734 Owner/Change controller: IESG 735 Note: sha256 should be used instead, this is a truncated variant of it 737 Netnews Cancel-Lock hash algorithm name: sha256 738 Security considerations: See corresponding section of this document 739 Published specification: This document 740 Contact for further information: Author of this document 741 Intended usage: COMMON 742 Owner/Change controller: IESG 743 Note: This algorithm is mandatory to implement 745 Netnews Cancel-Lock hash algorithm name: sha384 746 Security considerations: See corresponding section of this document 747 Published specification: This document 748 Contact for further information: Author of this document 749 Intended usage: LIMITED USE 750 Owner/Change controller: IESG 751 Note: sha512 should be used instead, this is a truncated variant of it 753 Netnews Cancel-Lock hash algorithm name: sha512 754 Security considerations: See corresponding section of this document 755 Published specification: This document 756 Contact for further information: Author of this document 757 Intended usage: COMMON 758 Owner/Change controller: IESG 759 Note: This algorithm is optional 761 9. References 763 9.1. Normative References 765 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 766 Requirement Levels", BCP 14, RFC 2119, 767 DOI 10.17487/RFC2119, March 1997, 768 . 770 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 771 Procedures for Message Header Fields", BCP 90, RFC 3864, 772 DOI 10.17487/RFC3864, September 2004, 773 . 775 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 776 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 777 . 779 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 780 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 781 DOI 10.17487/RFC5226, May 2008, 782 . 784 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 785 Specifications: ABNF", STD 68, RFC 5234, 786 DOI 10.17487/RFC5234, January 2008, 787 . 789 [RFC5536] Murchison, K., Ed., Lindsey, C., and D. Kohn, "Netnews 790 Article Format", RFC 5536, DOI 10.17487/RFC5536, November 791 2009, . 793 [RFC5537] Allbery, R., Ed. and C. Lindsey, "Netnews Architecture and 794 Protocols", RFC 5537, DOI 10.17487/RFC5537, November 2009, 795 . 797 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 798 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 799 DOI 10.17487/RFC6234, May 2011, 800 . 802 9.2. Informative References 804 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 805 DOI 10.17487/RFC1321, April 1992, 806 . 808 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 809 Hashing for Message Authentication", RFC 2104, 810 DOI 10.17487/RFC2104, February 1997, 811 . 813 [RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 814 (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001, 815 . 817 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 818 Thayer, "OpenPGP Message Format", RFC 4880, 819 DOI 10.17487/RFC4880, November 2007, 820 . 822 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 823 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 824 RFC 6151, DOI 10.17487/RFC6151, March 2011, 825 . 827 [SHA] National Institute of Standards and Technology, "Secure 828 Hash Standard (SHS)", FIPS 180-4, DOI 10.6028/FIPS.180-4, 829 August 2015, . 832 [USEFOR-CANCEL-LOCK] 833 Lyall, S., "Cancel-Locks in Usenet articles.", Work in 834 Progress, November 1998. 836 Appendix A. Acknowledgements 838 The author acknowledges the original author of the Cancel-Lock 839 authentication system as documented in draft-ietf-usefor-cancel-lock: 840 Simon Lyall. He has written the original draft and former version 841 [USEFOR-CANCEL-LOCK] and approved the usage of his work for this 842 document. This document is mostly based on his work and was 843 originally intended as revision 02. It must be renamed because the 844 USEFOR IETF WG is now closed. 846 The author would like to thank the following individuals for 847 contributing their ideas and reviewing this specification: Russ 848 Allbery, Urs Janssen, Richard Kettlewell, Marcel Logen, Holger 849 Marzen, Dennis Preiser, Emil Schuster. And Peter Faust and Alfred 850 Peters for providing statistic data about the algorithms currently in 851 use. 853 Special thanks to the Document Shepherd, Julien Elie. 855 Appendix B. Document History (to be removed by RFC Editor before 856 publication) 858 B.1. Changes since -04 860 o Added note that the IESG is the owner of all Netnews Cancel-Lock 861 hash algorithms that are on the IETF Standards Track in 862 Section 8.1. 864 o Changed the algorithm from informative to RECOMMENDED in 865 Section 4. 867 o Replaced "code-string" with "c-lock-string" for Step 2 in 868 Section 3.5. 870 o Replaced "code-string" with "c-key-string" for Step 1 in 871 Section 3.5. 873 o Added a short explanation in Section 3.3. 875 o Added a short explanation in Section 3.1. 877 o Replaced link to RFC2045 with link to RFC4648 in Section 2. 879 o Replaced normative reference RFC2045 (for Base64 algorithm) with 880 RFC4648. 882 o Added case insensitivity note in Section 5.3. 884 o RFC6234 (listed in the downref registry) is now a normative 885 reference (formerly informative) as recommended by Shepherd Write- 886 Up. 888 o NIST SHS standard is now an informative reference (formerly 889 normative) as recommended by Shepherd Write-Up. 891 o Added "sha224" and "sha384" schemes in Section 8.3 (because 892 implementations exists that supports them). 894 o Refer to Section 8.3 instead of Section 8.1 for hash algorithm 895 registry. 897 o Fixed some typos. 899 o Fixed line length in Section 5.1. 901 B.2. Changes since -03 903 o Added note for change interval of in Section 7. 905 o Changed wording in Section 7. 907 o Splitted Section 5 into multiple subsections. 909 o Added example with UID in Section 5. 911 o Changed "SHOULD NOT" to uppercase in Section 6. 913 o Reformatted Section 8, Section 8.1 and Section 8.3. 915 o Fixed spelling in Section 4. 917 B.3. Changes since -02 919 o Added Section 8.2. 921 o Added note about algorithm names in Section 8.1. 923 o Added "/" to scheme-char in Section 2. 925 o Removed case sensitivity of scheme and normative reference to 926 RFC7405 in Section 2 again. 928 o Added "sha512" scheme in Section 2. 930 o Changed wording in Section 8.3. 932 o Fixed typo "canceling" in Section 5. 934 o Changed calculation formulas to use "Base64" in Section 2.1 and 935 Section 2.2. 937 o Added obsolete algorithm "md5" in Section 8.3. 939 o Added note that posting agents should add the Message-ID header 940 field to proto-articles and use its content for in 941 Section 4. 943 o Added part to key calculation in Section 4. 945 o Added note to generate CFWS without comments in Section 2.1 and 946 Section 2.2. 948 o Changed ABNF to allow CFWS at the beginning of header fields in 949 Section 2.1 and Section 2.2. 951 o Changed wording for "header"/"header field"/"header field body". 953 o Added Section 3.4. 955 o Changed wording in Section 3.1. 957 o Allowed additional whitespace at the beginning of header fields in 958 Section 2.1 and Section 2.2. 960 o Changed definition of "c-key-string" in Section 2.2. 962 o Added "obs-c-key-string" to Section 6. 964 o Fixed typo in Section 2.2 ("c-lock" replaced by "c-key"). 966 o Added key length recommendation in Section 7. 968 o Renamed "sha-256" scheme to "sha256". 970 o Modified header and abstract section to list RFC5537 as updated by 971 this document again. 973 o Added "USEFOR-CANCEL-LOCK" as informative reference. 975 o Changed wording in Section 4. 977 B.4. Changes since -01 979 o Changed wording in Section 7. 981 o Added example for HMAC calculation in Section 5. 983 o Changed wording in Section 4. 985 o Added use cases to Section 3.2. 987 o Replaced wording "injecting-agent" by "injecting agent". 989 o Added Definition for "LOWER" in Section 2. 991 o Added Section 8.3. 993 o Added Section 8.1. 995 o Added new entries for header field registry in Section 8. 997 o Removed recommendation that moderators and injecting agents should 998 add only one Cancel-Lock or Cancel-Key resprectively to the list 999 in Section 3.1, Section 3.2 and Section 3.3. 1001 o Added missing headerfield termination to Section 2.1 and 1002 Section 2.2. 1004 o Removed definition for "code-string" from Section 2. Added 1005 stricter definition "c-lock-string" to Section 2.1. Added 1006 backward compatible definition "c-key-string" to Section 2.2. 1008 o Use different wording in Section 2.2. 1010 o Changed wording to reflect that an injecting agent is allowed to 1011 create Cancel-Lock headerfields in Section 2.1. 1013 o Fixed wording and typo in Section 2. 1015 o Added normative reference to RFC7405 because case-sensitivity is 1016 used in ABNF. 1018 o Added reference to RFC5536 (Section 2.2) in Section 2. 1020 o Added references to RFC4880 and RFC5537 in Section 1. 1022 o Replaced the wordings "remove" by "cancel" and "replace" by 1023 "supersede". 1025 o Modified header and abstract section to no longer list RFC5536 and 1026 RFC5537 as updated by this document. 1028 B.5. Changes since -00 1030 o Added additional note that deprecated "scheme" values should be 1031 preserved for backward compatibility as long as reasonable. 1033 o Removed deprectated scheme "md5" (not in use anymore). 1035 o Added descriptions how to generate "code-string" to Section 2.1 1036 and Section 2.2. 1038 o Removed length limitiation in ABNF of "scheme". 1040 o Changed copyright notice to use text from TLP section 6.c.iii. 1042 o Removed references from "abstract" section. 1044 o Changed "SHOULD NOT" to uppercase in Section 6. 1046 o Added line wraps to CLI commands in Section 5. 1048 B.6. Changes since draft-ietf-usefor-cancel-lock-01 1050 o Renamed document because the USEFOR IETF WG is now closed. 1052 o Added more details how to check Cancel-Key header fields in 1053 Section 3.5. 1055 o Added more details to Section 7. 1057 o Added updated ABNF for Cancel-Lock and Cancel-Key header fields. 1059 o Deprecated "md5" and "sha1" schemes. 1061 o Added "sha-256" scheme. 1063 o Reworded the abstract section and added references. 1065 o Added note to other authentication systems to Section 1. 1067 o Added command line check examples to Section 5. 1069 B.7. Changes since draft-ietf-usefor-cancel-lock-00 1071 o References to SHA-160 changed to SHA1 1073 o "scheme" is now a case insensitive token and the number "1" has 1074 been changed to "sha1". 1076 o Added some examples and fixed the section numbering. 1078 o Updated 2nd paragraph on section 2.2 to make clear what exactly is 1079 being hashed and how. 1081 o Changed paragraph 2 of 3.1 to discourage injection agents from 1082 adding the header. 1084 o Removed the Clue-string as this complicated the scheme without 1085 adding realistic functionality 1087 o Moderators can now add these headers under the same conditions as 1088 injection agents. 1090 Author's Address 1092 Michael Baeuerle 1093 STZ Elektronik 1094 Hofener Weg 33C 1095 Remseck, Baden-Wuerttemberg 71686 1096 Germany 1098 Fax: +49 7146 999061 1099 EMail: michael.baeuerle@stz-e.de