idnits 2.17.1 draft-baeuerle-netnews-cancel-lock-04.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 is 1 instance of too long lines in the document, the longest one being 2 characters 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 (April 8, 2017) is 2568 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA' Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Independent Submission M. Baeuerle 3 Internet-Draft STZ Elektronik 4 Updates: 5537 (if approved) April 8, 2017 5 Intended status: Standards Track 6 Expires: October 10, 2017 8 Cancel-Locks in Netnews articles 9 draft-baeuerle-netnews-cancel-lock-04 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 October 10, 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 6 75 3.5. Check a Cancel-Key header field . . . . . . . . . . . . . 7 76 4. Calculating the key data . . . . . . . . . . . . . . . . . . 7 77 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 5.1. Without UID . . . . . . . . . . . . . . . . . . . . . . . 8 79 5.2. With UID . . . . . . . . . . . . . . . . . . . . . . . . 9 80 5.3. Other examples . . . . . . . . . . . . . . . . . . . . . 10 81 5.4. Manual checks . . . . . . . . . . . . . . . . . . . . . . 11 82 6. Obsolete Syntax . . . . . . . . . . . . . . . . . . . . . . . 11 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 85 8.1. Algorithm Name Registration Procedure . . . . . . . . . . 14 86 8.2. Change control . . . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . 18 92 Appendix B. Document History (to be removed by RFC Editor before 93 publication) . . . . . . . . . . . . . . . . . . . . 18 94 B.1. Changes since -03 . . . . . . . . . . . . . . . . . . . . 18 95 B.2. Changes since -02 . . . . . . . . . . . . . . . . . . . . 18 96 B.3. Changes since -01 . . . . . . . . . . . . . . . . . . . . 20 97 B.4. Changes since -00 . . . . . . . . . . . . . . . . . . . . 21 98 B.5. Changes since draft-ietf-usefor-cancel-lock-01 . . . . . 21 99 B.6. Changes since draft-ietf-usefor-cancel-lock-00 . . . . . 22 100 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 102 1. Introduction 104 The authentication system defined in this document is intended to be 105 used as a simple method to verify that the author of an article which 106 cancels ([RFC5537] Section 5.3) or supersedes ([RFC5537] Section 5.4) 107 another one is either the poster, posting agent, moderator or 108 injecting agent that processed the original article when it was in 109 its proto-article form. 111 One property of this system is that it prevents tracking of 112 individual users. 114 There are other authentication systems available with different 115 properties. When everybody should be able to verify who the 116 originator is, e.g. for control messages to add or remove newsgroups 117 ([RFC5537] Section 5.2), an OpenPGP [RFC4880] signature is suited. 119 1.1. Conventions Used in This Document 121 Any term not defined in this document has the same meaning as it does 122 in [RFC5536] or [RFC5537]. 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in 127 [RFC2119]. 129 1.2. Author's Note 131 Please write the letters "ae" in "Baeuerle" as an a-umlaut (U+00E4, 132 "ä" in XML), the first letter in "Elie" with an acute accent 133 (U+00C9, "É" in XML), the letters "ss" in Janssen as an eszett 134 (U+00DF, "ß" in XML) and the letters "ue" in Baden-Wuerttemberg 135 as an u-umlaut (U+00FC, "ü" in XML) wherever this is possible. 137 2. Header Fields 139 This section describes the formal syntax of the new header fields 140 using ABNF [RFC5234]. It extends the syntax in Section 3 of 141 [RFC5536] and non-terminals not defined in this document are defined 142 there. The [RFC5536] ABNF should be imported first before attempting 143 to validate these rules. 145 The new header fields Cancel-Lock and Cancel-Key are defined by this 146 document, they follow the rules described in [RFC5536] Section 2.2: 148 fields =/ *( cancel-lock / cancel-key ) 150 Each of these header fields MUST NOT occur more than once in an 151 article. 153 Both new header field bodies contain lists of encoded values. Every 154 entry is based on a : 156 scheme = "sha256" / "sha512" / 1*scheme-char / obs-scheme 157 scheme-char = ALPHA / DIGIT / "-" / "/" 159 The hash algorithms for are defined in [SHA], see also 160 [RFC1321] and [RFC6151] for MD5, [RFC3174] for SHA1 and [RFC6234] for 161 the SHA2 family. The Base64 encoding used is defined in Section 6.8 162 of [RFC2045]. 164 This document defines two values for : "sha256" and "sha512". 165 The scheme "sha256" is mandatory to implement. 167 2.1. Cancel-Lock 169 cancel-lock = "Cancel-Lock:" SP c-lock-list CRLF 170 c-lock-list = [CFWS] c-lock *(CFWS c-lock) [CFWS] 171 c-lock = scheme ":" c-lock-string 172 c-lock-string = *(4base64-char) [base64-terminal] 173 base64-char = ALPHA / DIGIT / "+" / "/" 174 base64-terminal = 2base64-char "==" / 3base64-char "=" 176 Comments in CFWS can cause interoperability problems, so comments 177 SHOULD NOT be generated but MUST be accepted. 179 If is not supported by an implementation, the corresponding 180 element MUST be skipped and potential following 181 elements MUST NOT be ignored. 183 is the Base64 encoded output of a hash operation 184 (defined by ) of the Base64 encoded key "K" that is intended 185 to authenticate the person or agent that created or processed 186 respectively the proto-article up to injection (inclusively): 188 Base64(hash(Base64(K))) 190 Because of the one-way nature of the hash operation the key "K" is 191 not revealed. 193 2.2. Cancel-Key 195 cancel-key = "Cancel-Key:" SP c-key-list CRLF 196 c-key-list = [CFWS] c-key *(CFWS c-lock) [CFWS] 197 c-key = scheme ":" c-key-string 198 c-key-string = c-lock-string / obs-c-key-string 200 Comments in CFWS can cause interoperability problems, so comments 201 SHOULD NOT be generated but MUST be accepted. 203 If is not supported by an implementation, the corresponding 204 element MUST be skipped and potential following 205 elements MUST NOT be ignored. 207 is the Base64 encoded key "K" that was used to create 208 the element in the Cancel-Lock header field body (as defined 209 in Section 2.1 of this document) of the original article: 211 Base64(K) 213 The relaxed syntax definition of above is required for 214 backward compatibility with implementations that are not compliant 215 with this specification. Compliant implementations SHOULD generate 216 valid Base64 (that is to say the syntax of as defined 217 in Section 2.1 of this document) and MUST accept strings of 218 characters (that is to say the syntax of as defined in Section 6 of this document). 221 3. Use 223 3.1. Adding an initial Cancel-Lock header field to a proto-article 225 A Cancel-Lock header field MAY be added to a proto-article by the 226 poster or posting agent which will include one or more 227 elements. 229 If the poster or posting agent doesn't add a Cancel-Lock header field 230 to a proto-article, then an injecting agent (or moderator) MAY add 231 one or more provided that it positively authenticates the author. 232 The injecting agent (or moderator) MUST NOT add this header field to 233 a proto-article unless it is able to authenticate all cancelling or 234 superseding attempts from the poster and automatically add a working 235 Cancel-Key header field or extend an existing one for such proto- 236 articles. 238 Other agents MUST NOT add this header field to articles or proto- 239 articles that they process. 241 3.2. Extending the Cancel-Lock header field of a proto-article 243 If a Cancel-Lock header field has already been added to a proto- 244 article then any agent further processing the proto-article up to the 245 injecting agent (inclusively) MAY append additional elements 246 to those already in the header field body. 248 Use cases for extending the Cancel-Lock header field body: 250 o A moderator wants the ability to cancel articles after approving 251 them. 253 o An injecting agent acts representitive for posting agents without 254 support for the autentication system described in this document. 256 o A news administrator wants the ability to cancel articles that 257 were injected by its system (because they e.g. violate its abuse 258 policy). 260 Once an article is injected then this header field MUST NOT be 261 altered. In particular, relaying agents beyond the injecting agent 262 MUST NOT alter it. 264 3.3. Adding a Cancel-Key header field to a proto-article 266 A Cancel-Key header field MAY be added to a proto-article containing 267 a Control or Supersedes header field by the poster or posting agent 268 which will include one or more elements. They will 269 correspond to some or all of the elements in the article 270 referenced by the Control (with a "cancel" command as defined in 271 [RFC5537]) or Supersedes header field. 273 If, as mentioned in Section 3.1 an injecting agent (or moderator) has 274 added a Cancel-Lock header field to an article listed in the Control 275 (with "cancel" command as defined in [RFC5537]) or Supersedes header 276 field then (given that it authenticates the poster as being the same 277 as the poster of the original article) it MUST add the Cancel-Key 278 header field with at least one element that correspond to 279 that article. 281 Other agents MUST NOT alter this header field. 283 3.4. Extending the Cancel-Key header field of a proto-article 285 If a Cancel-Key header field has already been added to a proto- 286 article then any agent further processing the proto-article up to the 287 injecting agent (inclusively) MAY append additional elements 288 to those already in the header field body. 290 If, as mentioned in Section 3.2 an injecting agent (or moderator) has 291 extended the Cancel-Lock header field in an article listed in the 292 Control (with "cancel" command as defined in [RFC5537]) or Supersedes 293 header field then (given that it authenticates the poster as being 294 the same as the poster of the original article) it MUST extend the 295 Cancel-Key header field body with at least one element that 296 correspond to that article. 298 Once an article is injected then this header field MUST NOT be 299 altered. In particular, relaying agents beyond the injecting agent 300 MUST NOT alter it. 302 3.5. Check a Cancel-Key header field 304 When a serving agent receives an article that attempts to cancel or 305 supersede a previous article via Control (with a "cancel" command as 306 defined in [RFC5537]) or Supersedes header field, the system defined 307 in this document can be used for authentication. The general 308 handling of articles containing such attempts as defined in [RFC5537] 309 is not changed by this document. 311 To process the authentication, the received article must contain a 312 Cancel-Key header field and the original article a Cancel-Lock header 313 field. If this is not the case, the authentication is not possible 314 (failed). 316 For the authentication check, every supported element from 317 the received article is processed as follows: 319 1. The part of the element is hashed using the 320 algorithm defined by its part. 322 2. For all elements with the same in the original 323 article their part is compared to the calculated 324 hash. 326 3. If one is equal, the authentication is passed and the processing 327 of further elements can be aborted. 329 4. If no match was found and there are no more elements to 330 process, the authentication failed. 332 4. Calculating the key data 334 This section is informative, not normative. 336 It is suggested to use the function: 338 K = HMAC(uid+mid, sec) 340 to create the key "K" for an article with Message-ID that 341 belongs to the User-ID (e.g. the login name of the user). HMAC 342 is outlined in [RFC2104]. HMAC is computed over the data 343 (with '+' representing the concatenation operation), using as a 344 secret key held locally that can be used for multiple articles. This 345 method removes the need for a per-article database containing the 346 keys used for every article. [[Q1: Security review: Some existing 347 implementations concatenates the part with instead of 348 . This variant was not used to ensure that is directly 349 used as HMAC key (to avoid confusion with the length considerations 350 below). ]] 352 A posting agent should add the Message-ID header field to the proto- 353 article itself and use the content of the header field body as 354 (including literal angle brackets). 356 A posting agent, that uses a dedicated local secret for every 357 user, should use an empty string for the part. 359 The local secret should have a length of at least the output 360 size of the hash function that is used by HMAC (256 bit / 32 octets 361 for SHA256). If the secret is not a random value, but e.g. some sort 362 of human readable password, it should be much longer. In any case it 363 is important that this secret can not be guessed. 365 Note that the hash algorithm used as base for the HMAC operation is 366 not required to be the same as specified by . An agent that 367 verifies a Cancel-Key header field body simply checks whether one of 368 its elements matches one of the elements with the 369 same in the Cancel-Lock header field body of the original 370 article. 372 Common libraries like OpenSSL can be used for the cryptographic 373 operations. 375 5. Examples 377 5.1. Without UID 379 Example data for creation of a element with HMAC-SHA256 and 380 empty string as (as suggested in Section 4 for posting agents): 382 Message-ID: <12345@mid.example> 383 mid: <12345@mid.example> 384 sec: ExampleSecret 385 K : HMAC-SHA256(mid, sec) ;mid used as data, sec as secret key 387 Calculation of Base64(K) using the OpenSSL command line tools in a 388 POSIX shell: 390 $ printf "%s" "<12345@mid.example>" \ 391 | openssl dgst -sha256 -hmac "ExampleSecret" -binary \ 392 | openssl enc -base64 393 qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA= 395 This can be used as for cancelling or superseding the 396 article <12345@mid.example>. 398 Calculation of Base64(SHA256(Base64(K))) required for 399 using the OpenSSL command line tools in a POSIX shell: 401 $ printf "%s" "qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA=" \ 402 | openssl dgst -sha256 -binary \ 403 | openssl enc -base64 404 s/pmK/3grrz++29ce2/mQydzJuc7iqHn1nqcJiQTPMc= 406 Inserted into the Cancel-Lock header field body of article 407 <12345@mid.example> it looks like this: 409 Cancel-Lock: sha256:s/pmK/3grrz++29ce2/mQydzJuc7iqHn1nqcJiQTPMc= 411 Inserted into the Cancel-Key header field body of an article that 412 should cancel or supersede article <12345@mid.example> it looks like 413 this: 415 Cancel-Key: sha256:qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA= 417 5.2. With UID 419 Example data for creation of a element with HMAC-SHA256 and 420 "JaneDoe" as (as suggested in Section 4): 422 Message-ID: <12345@mid.example> 424 uid: JaneDoe 425 mid: <12345@mid.example> 426 sec: AnotherSecret 427 K : HMAC-SHA256(uid+mid, sec) ;uid+mid used as data, sec as secret key 429 Calculation of Base64(K) using the OpenSSL command line tools in a 430 POSIX shell: 432 $ printf "%s" "JaneDoe<12345@mid.example>" \ 433 | openssl dgst -sha256 -hmac "AnotherSecret" -binary \ 434 | openssl enc -base64 435 yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys= 437 This can be used as for cancelling or superseding the 438 article <12345@mid.example>. 440 Calculation of Base64(SHA256(Base64(K))) required for 441 using the OpenSSL command line tools in a POSIX shell: 443 $ printf "%s" "yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys=" \ 444 | openssl dgst -sha256 -binary \ 445 | openssl enc -base64 446 NSBTz7BfcQFTCen+U4lQ0VS8VIlZao2b8mxD/xJaaeE= 448 Inserted into the Cancel-Lock header field body of article 449 <12345@mid.example> it looks like this: 451 Cancel-Lock: sha256:NSBTz7BfcQFTCen+U4lQ0VS8VIlZao2b8mxD/xJaaeE= 453 Inserted into the Cancel-Key header field body of an article that 454 should cancel or supersede article <12345@mid.example> it looks like 455 this: 457 Cancel-Key: sha256:yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys= 459 5.3. Other examples 461 Other matching pair of Cancel-Lock and Cancel-Key header fields: 463 Cancel-Lock: sha256:RrKLp7YCQc9T8HmgSbxwIDlnCDWsgy1awqtiDuhedRo= 464 Cancel-Key: sha256:sSkDke97Dh78/d+Diu1i3dQ2Fp/EMK3xE2GfEqZlvK8= 466 With obsolete syntax (uses a with invalid/missing 467 Base64 padding): 469 Cancel-Lock: sha1:bNXHc6ohSmeHaRHHW56BIWZJt+4= 470 Cancel-Key: ShA1:aaaBBBcccDDDeeeFFF 472 Let's assume that all the examples above are associated to the same 473 article (e.g. created by different agents): 475 Cancel-Lock: sha256:s/pmK/3grrz++29ce2/mQydzJuc7iqHn1nqcJiQTPMc= 476 sha256:NSBTz7BfcQFTCen+U4lQ0VS8VIlZao2b8mxD/xJaaeE= 477 sha256:RrKLp7YCQc9T8HmgSbxwIDlnCDWsgy1awqtiDuhedRo= 478 sha1:bNXHc6ohSmeHaRHHW56BIWZJt+4= 479 Cancel-Key: sha256:qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA= 480 sha256:yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys= 481 sha256:sSkDke97Dh78/d+Diu1i3dQ2Fp/EMK3xE2GfEqZlvK8= 482 ShA1:aaaBBBcccDDDeeeFFF 484 5.4. Manual checks 486 Manual checks using the OpenSSL command line tools in a POSIX shell: 488 $ printf "%s" "qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA=" \ 489 | openssl dgst -sha256 -binary \ 490 | openssl enc -base64 491 s/pmK/3grrz++29ce2/mQydzJuc7iqHn1nqcJiQTPMc= 493 $ printf "%s" "yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys=" \ 494 | openssl dgst -sha256 -binary \ 495 | openssl enc -base64 496 NSBTz7BfcQFTCen+U4lQ0VS8VIlZao2b8mxD/xJaaeE= 498 $ printf "%s" "sSkDke97Dh78/d+Diu1i3dQ2Fp/EMK3xE2GfEqZlvK8=" \ 499 | openssl dgst -sha256 -binary \ 500 | openssl enc -base64 501 RrKLp7YCQc9T8HmgSbxwIDlnCDWsgy1awqtiDuhedRo= 503 $ printf "%s" "aaaBBBcccDDDeeeFFF" \ 504 | openssl dgst -sha1 -binary \ 505 | openssl enc -base64 506 bNXHc6ohSmeHaRHHW56BIWZJt+4= 508 6. Obsolete Syntax 510 Implementations of earlier drafts of this specification defined a 511 different value for than this version. The following value 512 for is now deprecated and SHOULD NOT be generated anymore. 513 Serving agents SHOULD still accept it for a transition period as long 514 as the corresponding hash function is not considered unsafe (see 515 Section 7 for details), or already marked as OBSOLETE in the Netnews 516 Cancel-Lock hash algorithm registry (Section 8.1). 518 obs-scheme = "sha1" 520 It is important for backward compatibility that the deprecated value 521 for is not phased out too early. Security and compatibility 522 concerns should be carefully weighed before choosing to remove from existing implementations (or not implementing it in new 524 ones). 526 Earlier drafts of this specification allowed more liberal syntax for 527 : 529 obs-c-key-string = 1*base64-octet 530 base64-octet = ALPHA / DIGIT / "+" / "/" / "=" 532 SHOULD NOT be generated but MUST be accepted. 534 7. Security Considerations 536 The important properties of the hash function used for are 537 the preimage and second preimage resistance. A successful preimage 538 attack would reveal the real element that was used to 539 create the Cancel-Lock header field body of the original article. A 540 successful second preimage attack would allow to create a new, 541 different element that, if used in the Cancel-Key 542 header field body, matches a element in the Cancel- 543 Lock header field body of the original article too. Both cases would 544 break the authentication system defined in this document. 546 Collision resistance of the hash function used for is less 547 important. Finding two elements for the Cancel-Key header 548 field that match to a element of an arbitary Cancel-Lock 549 header field is not helpful to break the authentication system 550 defined in this document (if a specific article is defined as 551 target). Only collateral damage by arbitrary cancel or supersede is 552 possible. 554 Currently there is no known practicable preimage and second preimage 555 attack against the hash function SHA1. Therefore there is no hurry 556 to replace it. The reasons why this document specifies hash 557 functions from the SHA2 family are: 559 o The last draft for the authentication system defined in this 560 document is nearly two decades old. The client side 561 implementations are moving forward extremely slowly too 562 (newsreaders from the last millenium are still in heavy use). 563 What is defined today should be strong enough for at least the 564 next decades. 566 o The collision resistance of SHA1 is already broken, therefore it 567 is now obsolete for digital signatures as used in TLS. It is 568 intended that an implementation of the authentication system 569 defined in this document can share the same cryptographic library 570 functions that are used for TLS. 572 o It is intended that the same hash function can be used for 573 and (as base) for the HMAC that is suggested in 574 Section 4. See notes below for HMAC-MD5 and HMAC-SHA1. 576 o The SHA2 family of hash algorithms is widely supported by 577 cryptographic libraries. In contrast, SHA3 is currently not 578 supported by e.g. OpenSSL. 580 The operation HMAC(uid+mid, sec) as suggested in Section 4 must be 581 able to protect the local secret . The Message-ID is 582 public (in the Message-ID header field body) and is optional. 583 An attacker who wants to steal/use a local secret only need to break 584 this algorithm (regardless of ), because Cancel-Key header 585 fields are explicitly published for every request to cancel or 586 supersede existing articles. 588 Even if HMAC-MD5 and HMAC-SHA1 are not considered broken today, it is 589 desired to have some more security margin here. Breaking 590 only allows to authenticate a single forged cancel or supersede 591 request. With in hand it is possible to forge such requests 592 for all articles that contain Cancel-Lock header field bodies with 593 elements that are generated with this in the past. Changing 594 in regular intervals can be used to mitigate the potential 595 damage. 597 If an implementation choose to not implement the key calculation 598 algorithm as suggested in Section 4, or to implement it with HMAC 599 based on a different hash function than , the key size used 600 should be at least 128 bit with "sha256" for and at least 80 601 bit with "sha1" for . [[Q2: Security review: Should these 602 recommendations remain in the document, or does an RFC exist to refer 603 to with regards to security recommendations? ]] 605 8. IANA Considerations 607 IANA has registered the following header fields in the Permanent 608 Message Header Field Repository, in accordance with the procedures 609 set out in [RFC3864]: 611 Header field name: Cancel-Lock 612 Applicable protocol: netnews 613 Status: standard 614 Author/change controller: IETF 615 Specification document(s): This document 616 Header field name: Cancel-Key 617 Applicable protocol: netnews 618 Status: standard 619 Author/change controller: IETF 620 Specification document(s): This document 622 The Netnews Cancel-Lock hash algorithm registry will be maintained by 623 IANA. 625 The registry will be available at . 628 8.1. Algorithm Name Registration Procedure 630 IANA will register new Cancel-Lock hash algorithm names on a First 631 Come First Served basis, as defined in BCP 26 [RFC5226]. IANA has 632 the right to reject obviously bogus registration requests, but will 633 perform no review of claims made in the registration form. 635 Registration of a Netnews Cancel-Lock hash algorithm is requested by 636 filling in the following template and sending it via electronic mail 637 to IANA at : 639 Subject: Registration of Netnews Cancel-Lock hash algorithm X 640 Netnews Cancel-Lock hash algorithm name: 641 Security considerations: 642 Published specification (recommended): 643 Contact for further information: 644 Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE) 645 Owner/Change controller: 646 Note: (Any other information that the author deems relevant may be 647 added here.) 649 Any name that conforms to the syntax of a Netnews Cancel-Lock 650 algorithm Section 2 can be used. Especially, Netnews Cancel-Lock 651 algorithms are named by strings consisting of letters, digits, 652 hyphens and/or slashes. 654 Authors may seek community review by posting a specification of their 655 proposed algorithm as an Internet-Draft. Netnews Cancel-Lock hash 656 algorithms intended for widespread use should be standardized through 657 the normal IETF process, when appropriate. 659 8.2. Change control 661 Once a Netnews Cancel-Lock hash algorithm registration has been 662 published by IANA, the owner may request a change to its definition. 664 The change request follows the same procedure as the initial 665 registration request. 667 The owner of a Netnews Cancel-Lock hash algorithm may pass 668 responsibility for the algorithm to another person or agency by 669 informing IANA; this can be done without discussion or review. 671 The IESG may reassign responsibility for a Netnews Cancel-Lock hash 672 algorithm. The most common case of this will be to enable changes to 673 be made to algorithms where the owner of the registration has died, 674 has moved out of contact, or is otherwise unable to make changes that 675 are important to the community. 677 Netnews Cancel-Lock hash algorithm registrations MUST NOT be deleted; 678 algorithms that are no longer believed appropriate for use can be 679 declared OBSOLETE by a change to their "intended usage" field; such 680 algorithms will be clearly marked in the registry published by IANA. 682 The IESG is considered to be the owner of all Netnews Cancel-Lock 683 hash algorithms that are on the IETF Standards Track. 685 8.3. Registration of the Netnews Cancel-Lock hash algorithms 687 This section gives a formal definition of the Netnews Cancel-Lock 688 hash algorithms as required by Section 8.1 for the IANA registry. 690 Netnews Cancel-Lock hash algorithm name: md5 691 Security considerations: See corresponding section of this document 692 Published specification: This document 693 Contact for further information: Author of this document 694 Intended usage: OBSOLETE 695 Owner/Change controller: IESG 696 Note: Do not use this algorithm anymore 698 Netnews Cancel-Lock hash algorithm name: sha1 699 Security considerations: See corresponding section of this document 700 Published specification: This document 701 Contact for further information: Author of this document 702 Intended usage: LIMITED USE 703 Owner/Change controller: IESG 704 Note: This algorithm is intended for backward compatibility 705 Netnews Cancel-Lock hash algorithm name: sha256 706 Security considerations: See corresponding section of this document 707 Published specification: This document 708 Contact for further information: Author of this document 709 Intended usage: COMMON 710 Owner/Change controller: IESG 711 Note: This algorithm is mandatory to implement 713 Netnews Cancel-Lock hash algorithm name: sha512 714 Security considerations: See corresponding section of this document 715 Published specification: This document 716 Contact for further information: Author of this document 717 Intended usage: COMMON 718 Owner/Change controller: IESG 719 Note: This algorithm is optional 721 9. References 723 9.1. Normative References 725 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 726 Extensions (MIME) Part One: Format of Internet Message 727 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 728 . 730 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 731 Requirement Levels", BCP 14, RFC 2119, 732 DOI 10.17487/RFC2119, March 1997, 733 . 735 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 736 Procedures for Message Header Fields", BCP 90, RFC 3864, 737 DOI 10.17487/RFC3864, September 2004, 738 . 740 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 741 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 742 DOI 10.17487/RFC5226, May 2008, 743 . 745 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 746 Specifications: ABNF", STD 68, RFC 5234, 747 DOI 10.17487/RFC5234, January 2008, 748 . 750 [RFC5536] Murchison, K., Ed., Lindsey, C., and D. Kohn, "Netnews 751 Article Format", RFC 5536, DOI 10.17487/RFC5536, November 752 2009, . 754 [RFC5537] Allbery, R., Ed. and C. Lindsey, "Netnews Architecture and 755 Protocols", RFC 5537, DOI 10.17487/RFC5537, November 2009, 756 . 758 [SHA] National Institute of Standards and Technology, "Secure 759 Hash Standard (SHS)", FIPS 180-4, DOI 10.6028/FIPS.180-4, 760 August 2015, . 763 9.2. Informative References 765 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 766 DOI 10.17487/RFC1321, April 1992, 767 . 769 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 770 Hashing for Message Authentication", RFC 2104, 771 DOI 10.17487/RFC2104, February 1997, 772 . 774 [RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 775 (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001, 776 . 778 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 779 Thayer, "OpenPGP Message Format", RFC 4880, 780 DOI 10.17487/RFC4880, November 2007, 781 . 783 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 784 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 785 RFC 6151, DOI 10.17487/RFC6151, March 2011, 786 . 788 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 789 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 790 DOI 10.17487/RFC6234, May 2011, 791 . 793 [USEFOR-CANCEL-LOCK] 794 Lyall, S., "Cancel-Locks in Usenet articles.", Work in 795 Progress, November 1998. 797 Appendix A. Acknowledgements 799 The author acknowledges the original author of the Cancel-Lock 800 authentication system as documented in draft-ietf-usefor-cancel-lock: 801 Simon Lyall. He has written the original draft and former version 802 [USEFOR-CANCEL-LOCK] and approved the usage of his work for this 803 document. This document is mostly based on his work and was 804 originally intended as revision 02. It must be renamed because the 805 USEFOR IETF WG is now closed. 807 The author would like to thank the following individuals for 808 contributing their ideas and reviewing this specification: Russ 809 Allbery, Julien Elie, Urs Janssen, Richard Kettlewell, Marcel Logen, 810 Holger Marzen, Dennis Preiser, Emil Schuster. And Peter Faust and 811 Alfred Peters for providing statistic data about the algorithms 812 currently in use. 814 Appendix B. Document History (to be removed by RFC Editor before 815 publication) 817 B.1. Changes since -03 819 o Added note for change interval of in Section 7. 821 o Changed wording in Section 7. 823 o Splitted Section 5 into multiple subsections. 825 o Added example with UID in Section 5. 827 o Changed "SHOULD NOT" to uppercase in Section 6. 829 o Reformatted Section 8, Section 8.1 and Section 8.3. 831 o Fixed spelling in Section 4. 833 B.2. Changes since -02 835 o Added Section 8.2. 837 o Added note about algorithm names in Section 8.1. 839 o Added "/" to scheme-char in Section 2. 841 o Removed case sensitivity of scheme and normative reference to 842 RFC7405 in Section 2 again. 844 o Added "sha512" scheme in Section 2. 846 o Changed wording in Section 8.3. 848 o Fixed typo "canceling" in Section 5. 850 o Changed calculation formulas to use "Base64" in Section 2.1 and 851 Section 2.2. 853 o Added obsolete algorithm "md5" in Section 8.3. 855 o Added note that posting agents should add the Message-ID header 856 field to proto-articles and use its content for in 857 Section 4. 859 o Added part to key calculation in Section 4. 861 o Added note to generate CFWS without comments in Section 2.1 and 862 Section 2.2. 864 o Changed ABNF to allow CFWS at the beginning of header fields in 865 Section 2.1 and Section 2.2. 867 o Changed wording for "header"/"header field"/"header field body". 869 o Added Section 3.4. 871 o Changed wording in Section 3.1. 873 o Allowed additional whitespace at the beginning of header fields in 874 Section 2.1 and Section 2.2. 876 o Changed definition of "c-key-string" in Section 2.2. 878 o Added "obs-c-key-string" to Section 6. 880 o Fixed typo in Section 2.2 ("c-lock" replaced by "c-key"). 882 o Added key length recommendation in Section 7. 884 o Renamed "sha-256" scheme to "sha256". 886 o Modified header and abstract section to list RFC5537 as updated by 887 this document again. 889 o Added "USEFOR-CANCEL-LOCK" as informative reference. 891 o Changed wording in Section 4. 893 B.3. Changes since -01 895 o Changed wording in Section 7. 897 o Added example for HMAC calculation in Section 5. 899 o Changed wording in Section 4. 901 o Added use cases to Section 3.2. 903 o Replaced wording "injecting-agent" by "injecting agent". 905 o Added Definition for "LOWER" in Section 2. 907 o Added Section 8.3. 909 o Added Section 8.1. 911 o Added new entries for header field registry in Section 8. 913 o Removed recommendation that moderators and injecting agents should 914 add only one Cancel-Lock or Cancel-Key resprectively to the list 915 in Section 3.1, Section 3.2 and Section 3.3. 917 o Added missing headerfield termination to Section 2.1 and 918 Section 2.2. 920 o Removed definition for "code-string" from Section 2. Added 921 stricter definition "c-lock-string" to Section 2.1. Added 922 backward compatible definition "c-key-string" to Section 2.2. 924 o Use different wording in Section 2.2. 926 o Changed wording to reflect that an injecting agent is allowed to 927 create Cancel-Lock headerfields in Section 2.1. 929 o Fixed wording and typo in Section 2. 931 o Added normative reference to RFC7405 because case-sensitivity is 932 used in ABNF. 934 o Added reference to RFC5536 (Section 2.2) in Section 2. 936 o Added references to RFC4880 and RFC5537 in Section 1. 938 o Replaced the wordings "remove" by "cancel" and "replace" by 939 "supersede". 941 o Modified header and abstract section to no longer list RFC5536 and 942 RFC5537 as updated by this document. 944 B.4. Changes since -00 946 o Added additional note that deprecated "scheme" values should be 947 preserved for backward compatibility as long as reasonable. 949 o Removed deprectated scheme "md5" (not in use anymore). 951 o Added descriptions how to generate "code-string" to Section 2.1 952 and Section 2.2. 954 o Removed length limitiation in ABNF of "scheme". 956 o Changed copyright notice to use text from TLP section 6.c.iii. 958 o Removed references from "abstract" section. 960 o Changed "SHOULD NOT" to uppercase in Section 6. 962 o Added line wraps to CLI commands in Section 5. 964 B.5. Changes since draft-ietf-usefor-cancel-lock-01 966 o Renamed document because the USEFOR IETF WG is now closed. 968 o Added more details how to check Cancel-Key header fields in 969 Section 3.5. 971 o Added more details to Section 7. 973 o Added updated ABNF for Cancel-Lock and Cancel-Key header fields. 975 o Deprecated "md5" and "sha1" schemes. 977 o Added "sha-256" scheme. 979 o Reworded the abstract section and added references. 981 o Added note to other authentication systems to Section 1. 983 o Added command line check examples to Section 5. 985 B.6. Changes since draft-ietf-usefor-cancel-lock-00 987 o References to SHA-160 changed to SHA1 989 o "scheme" is now a case insensitive token and the number "1" has 990 been changed to "sha1". 992 o Added some examples and fixed the section numbering. 994 o Updated 2nd paragraph on section 2.2 to make clear what exactly is 995 being hashed and how. 997 o Changed paragraph 2 of 3.1 to discourage injection agents from 998 adding the header. 1000 o Removed the Clue-string as this complicated the scheme without 1001 adding realistic functionality 1003 o Moderators can now add these headers under the same conditions as 1004 injection agents. 1006 Author's Address 1008 Michael Baeuerle 1009 STZ Elektronik 1010 Hofener Weg 33C 1011 Remseck, Baden-Wuerttemberg 71686 1012 Germany 1014 Fax: +49 7146 999061 1015 EMail: michael.baeuerle@stz-e.de