idnits 2.17.1 draft-baeuerle-netnews-cancel-lock-02.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 8 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 lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: o Changed "SHOULD not" into "SHOULD NOT" in Section 6. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 10, 2017) is 2605 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 (~~), 3 warnings (==), 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 Intended status: Standards Track March 10, 2017 5 Expires: September 11, 2017 7 Cancel-Locks in Netnews articles 8 draft-baeuerle-netnews-cancel-lock-02 10 Abstract 12 This document defines an extension to the Netnews Article Format that 13 may be used to authenticate the cancelling and superseding of 14 existing articles. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on September 11, 2017. 33 Copyright Notice 35 Copyright (c) 2017 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 This document may contain material from IETF Documents or IETF 49 Contributions published or made publicly available before November 50 10, 2008. The person(s) controlling the copyright in some of this 51 material may not have granted the IETF Trust the right to allow 52 modifications of such material outside the IETF Standards Process. 53 Without obtaining an adequate license from the person(s) controlling 54 the copyright in such materials, this document may not be modified 55 outside the IETF Standards Process, and derivative works of it may 56 not be created outside the IETF Standards Process, except to format 57 it for publication as an RFC or to translate it into languages other 58 than English. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 64 1.2. Author's Note . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2.1. Cancel-Lock . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.2. Cancel-Key . . . . . . . . . . . . . . . . . . . . . . . 5 68 3. Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.1. Adding an initial Cancel-Lock header field to a proto- 70 article . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3.2. Extending the Cancel-Lock header field of a proto-article 5 72 3.3. Adding a Cancel-Key header field to a proto-article . . . 6 73 3.4. Check a Cancel-Key header field . . . . . . . . . . . . . 6 74 4. Calculating the key data . . . . . . . . . . . . . . . . . . 7 75 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 6. Obsolete Syntax . . . . . . . . . . . . . . . . . . . . . . . 9 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 79 8.1. Algorithm Name Registration Procedure . . . . . . . . . . 11 80 8.2. Registration of the Netnews Cancel-Lock hash algorithms . 12 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 83 9.2. Informative References . . . . . . . . . . . . . . . . . 14 84 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 85 Appendix B. Document History (to be removed by RFC Editor before 86 publication) . . . . . . . . . . . . . . . . . . . . 15 87 B.1. Changes since -01 . . . . . . . . . . . . . . . . . . . . 15 88 B.2. Changes since -00 . . . . . . . . . . . . . . . . . . . . 16 89 B.3. Changes since draft-ietf-usefor-cancel-lock-01 . . . . . 17 90 B.4. Changes since draft-ietf-usefor-cancel-lock-00 . . . . . 17 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 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 author of an article which 97 cancels ([RFC5537] Section 5.3) or supersedes ([RFC5537] Section 5.4) 98 another one is either the poster, posting agent, moderator or 99 injecting agent that processed the original article when it was in 100 its proto-article form. 102 One property of this system is that it prevents tracking of 103 individual users. 105 There are other authentication systems available with different 106 properties. When everybody should be able to verify who the 107 originator is, e.g. for control messages to add or remove newsgroups 108 ([RFC5537] Section 5.2), an OpenPGP [RFC4880] signature is suited. 110 1.1. Conventions Used in This Document 112 Any term not defined in this document has the same meaning as it does 113 in [RFC5536] or [RFC5537]. 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 117 "OPTIONAL" in this document are to be interpreted as described in 118 [RFC2119]. 120 1.2. Author's Note 122 Please write the letters "ae" in "Baeuerle" as an a-umlaut (U+00E4, 123 "ä" in XML), the first letter in "Elie" with an acute accent 124 (U+00C9, "É" in XML), the letters "ss" in Janssen as an eszett 125 (U+00DF, "ß" in XML) and the letters "ue" in Baden-Wuerttemberg 126 as an u-umlaut (U+00FC, "ü" in XML) wherever this is possible. 128 2. Header Fields 130 This section describes the formal syntax of the new header fields 131 using ABNF [RFC5234][RFC7405]. It extends the syntax in Section 3 of 132 [RFC5536] and non-terminals not defined in this document are defined 133 there. The [RFC5536] ABNF should be imported first before attempting 134 to validate these rules. 136 The new header fields Cancel-Lock and Cancel-Key are defined by this 137 document, they follow the rules described in [RFC5536] Section 2.2: 139 fields =/ *( cancel-lock / cancel-key ) 141 Each of these header fields MUST NOT occur more than once in an 142 article. 144 Both new header fields contain lists of encoded values. Every entry 145 is based on a : 147 scheme = %s"sha-256" / 1*scheme-char / obs-scheme 148 scheme-char = LOWER / DIGIT / "-" 149 LOWER = %x61-7A ; lowercase characters [a-z] 151 The hash algorithms for are defined in [SHA], see also 152 [RFC1321] and [RFC6151] for MD5, [RFC3174] for SHA1 and [RFC6234] for 153 the SHA2 family. The Base64 encoding used is defined in Section 6.8 154 of [RFC2045]. 156 This document defines one value for : "sha-256". This scheme 157 is mandatory to implement. 159 Note that the obsolete syntax was defined case- 160 insensitive. This is changed in this document and the scheme MUST 161 now be generated with lowercase letters. 163 The case sensitivity of is defined to simplify the checks. 165 2.1. Cancel-Lock 167 cancel-lock = "Cancel-Lock:" SP c-lock-list CRLF 168 c-lock-list = c-lock *(CFWS c-lock) [CFWS] 169 c-lock = scheme ":" c-lock-string 170 c-lock-string = *(4base64-char) [base64-terminal] 171 base64-char = ALPHA / DIGIT / "+" / "/" 172 base64-terminal = 2base64-char "==" / 3base64-char "=" 174 If is not supported by an implementation, the corresponding 175 element MUST be skipped and potential following 176 elements MUST NOT be ignored. 178 is the Base64 encoded output of a hash operation 179 (defined by ) of the Base64 encoded key "K" that is intended 180 to authenticate the person or agent that created or processed 181 respectively the article up to injection (inclusively): 183 base64(hash(base64(K))) 185 Because of the one-way nature of the hash operation the key "K" is 186 not revealed. 188 2.2. Cancel-Key 190 cancel-key = "Cancel-Key:" SP c-key-list CRLF 191 c-key-list = c-lock *(CFWS c-lock) [CFWS] 192 c-key = scheme ":" c-key-string 193 c-key-string = 1*base64-octet 194 base64-octet = ALPHA / DIGIT / "+" / "/" / "=" 196 If is not supported by an implementation, the corresponding 197 element MUST be skipped and potential following 198 elements MUST NOT be ignored. 200 is the Base64 encoded key "K" that was used to create 201 the Cancel-Lock header field (as defined in Section 2.1 of this 202 document) of the original article: 204 base64(K) 206 The relaxed syntax definition of above is required for 207 backward compatibility. New implementations always SHOULD generate 208 valid Base64. 210 3. Use 212 3.1. Adding an initial Cancel-Lock header field to a proto-article 214 A Cancel-Lock header field MAY be added to a proto-article by the 215 poster or posting agent which will include one or more 216 elements. 218 If the poster or posting agent doesn't add a Cancel-Lock header field 219 to an article, then an injecting agent (or moderator) MAY add one or 220 more provided that it positively authenticates the author. The 221 injecting agent (or moderator) MUST NOT add this header field to an 222 article unless it is able to authenticate all cancelling or 223 superseding attempts from the poster and automatically add working 224 Cancel-Key header fields for such articles. 226 Other agents MUST NOT add this header to articles or proto-articles 227 that they process. 229 3.2. Extending the Cancel-Lock header field of a proto-article 231 If a Cancel-Lock header field has already been added to a proto- 232 article then any agent further processing the proto-article up to the 233 injecting agent (inclusively) MAY append additional elements 234 to those already in the header. 236 Use cases for extending the Cancel-Lock header field: 238 o A moderator wants the ability to cancel articles after approving 239 them. 241 o A news administrator wants the ability to cancel articles that 242 were injected by its system (because they e.g. violate its abuse 243 policy). 245 o An injecting agent acts representitive for posting agents without 246 support for the autentication system described in this document. 248 Once an article is injected then this header MUST NOT be altered. In 249 particular, relaying agents beyond the injecting agent MUST NOT alter 250 it. 252 3.3. Adding a Cancel-Key header field to a proto-article 254 A Cancel-Key header field MAY be added to a proto-article containing 255 a Control or Supersedes header field by the poster or posting agent 256 which will include one or more elements. They will 257 correspond to some or all of the elements in the article 258 referenced by the Control (with a "cancel" command as defined in 259 [RFC5537]) or Supersedes header field. 261 If, as mentioned in Section 3.2 an injecting agent (or moderator) has 262 added a Cancel-Lock header field to an article listed in the Control 263 (with "cancel" command as defined in [RFC5537]) or Supersedes header 264 field then (given that it authenticates the poster as being the same 265 as the poster of the original article) it MUST add (or extend, if 266 already present) the Cancel-Key header field with at least one 267 element that correspond to that article. 269 Other agents MUST NOT alter this header. 271 3.4. Check a Cancel-Key header field 273 When a serving agent receives an article that attempts to cancel or 274 supersede a previous article via Control (with a "cancel" command as 275 defined in [RFC5537]) or Supersedes header field, the system defined 276 in this document can be used for authentication. The general 277 handling of articles containing such attempts as defined in [RFC5537] 278 is not changed by this document. 280 To process the authentication, the received article must contain a 281 Cancel-Key header field and the original article a Cancel-Lock header 282 field. If this is not the case, the authentication is not possible 283 (failed). 285 For the authentication check, every supported element from 286 the received article is processed as follows: 288 1. The part of the element is hashed using the 289 algorithm defined by its part. 291 2. For all elements with the same in the original 292 article their part is compared to the calculated 293 hash. 295 3. If one is equal, the authentication is passed and the processing 296 of further elements can be aborted. 298 4. If no match was found and there are no more elements to 299 process, the authentication failed. 301 4. Calculating the key data 303 This section is informative, not normative. 305 It is suggested to use the function K = HMAC(mid+sec) to create the 306 key "K" for an article with Message-ID , where HMAC is outlined 307 in [RFC2104]. is a secret held locally that can be used for 308 multiple articles. This method removes the need for a per-article 309 database containing the keys used for every article. 311 The local secret should have a length of at least the output 312 size of the hash function that is used by HMAC (32 octets for SHA- 313 256). If the secret is not a random value, but e.g. some sort of 314 human readable password, it should be much longer. In any case it is 315 important that this secret can not be guessed. 317 Note that the hash algorithm used as base for the HMAC operation is 318 not required to be the same as specified by . An agent that 319 verifies a Cancel-Key header field simply checks whether it matches 320 one of the elements with the same in the Cancel- 321 Lock header field of the original article. 323 Common libraries like OpenSSL can be used for the cryptographic 324 operations. 326 5. Examples 328 Example data for creation of a element with HMAC-SHA256 (as 329 suggested in Section 4): 331 Message-ID: <12345@mid.example> 333 mid: <12345@mid.example> 334 sec: ExampleSecret 335 K : HMAC-SHA256(mid+sec) ;"mid" used as HMAC message, "sec" used as HMAC key 337 Calculation of Base64(K) using the OpenSSL command line tools in a 338 POSIX shell: 340 $ printf "%s" "<12345@mid.example>" \ 341 | openssl dgst -sha256 -hmac "ExampleSecret" -binary \ 342 | openssl enc -base64 343 qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA= 345 This can be used as for canceling or superseding the 346 article <12345@mid.example>. 348 Calculation of Base64(SHA256(Base64(K))) required for 349 using the OpenSSL command line tools in a POSIX shell: 351 $ printf "%s" "qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA=" \ 352 | openssl dgst -sha256 -binary \ 353 | openssl enc -base64 354 s/pmK/3grrz++29ce2/mQydzJuc7iqHn1nqcJiQTPMc= 356 Inserted into the header of article <12345@mid.example> it looks like 357 this: 359 Cancel-Lock: sha-256:s/pmK/3grrz++29ce2/mQydzJuc7iqHn1nqcJiQTPMc= 361 Inserted into the header of an article that should cancel or 362 supersede article <12345@mid.example> it looks like this: 364 Cancel-Key: sha-256:qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA= 366 Other matching pair of Cancel-Lock and Cancel-Key header fields: 368 Cancel-Lock: sha-256:RrKLp7YCQc9T8HmgSbxwIDlnCDWsgy1awqtiDuhedRo= 369 Cancel-Key: sha-256:sSkDke97Dh78/d+Diu1i3dQ2Fp/EMK3xE2GfEqZlvK8= 371 With obsolete syntax (requires case-insensitive parsing of 372 and uses a with invalid/missing Base64 padding): 374 Cancel-Lock: sha1:bNXHc6ohSmeHaRHHW56BIWZJt+4= 375 Cancel-Key: ShA1:aaaBBBcccDDDeeeFFF 377 Let's assume that all the examples above are associated to the same 378 article (e.g. created by different agents): 380 Cancel-Lock: sha-256:s/pmK/3grrz++29ce2/mQydzJuc7iqHn1nqcJiQTPMc= 381 sha-256:RrKLp7YCQc9T8HmgSbxwIDlnCDWsgy1awqtiDuhedRo= 382 sha1:bNXHc6ohSmeHaRHHW56BIWZJt+4= 383 Cancel-Key: sha-256:qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA= 384 sha-256:sSkDke97Dh78/d+Diu1i3dQ2Fp/EMK3xE2GfEqZlvK8= 385 ShA1:aaaBBBcccDDDeeeFFF 387 Manual checks using the OpenSSL command line tools in a POSIX shell: 389 $ printf "%s" "qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA=" \ 390 | openssl dgst -sha256 -binary \ 391 | openssl enc -base64 392 s/pmK/3grrz++29ce2/mQydzJuc7iqHn1nqcJiQTPMc= 394 $ printf "%s" "sSkDke97Dh78/d+Diu1i3dQ2Fp/EMK3xE2GfEqZlvK8=" \ 395 | openssl dgst -sha256 -binary \ 396 | openssl enc -base64 397 RrKLp7YCQc9T8HmgSbxwIDlnCDWsgy1awqtiDuhedRo= 399 $ printf "%s" "aaaBBBcccDDDeeeFFF" \ 400 | openssl dgst -sha1 -binary \ 401 | openssl enc -base64 402 bNXHc6ohSmeHaRHHW56BIWZJt+4= 404 6. Obsolete Syntax 406 Implementations of earlier drafts of this specification allowed more 407 liberal (case insensitive) syntax and defined a different value for 408 than this version. The following value for is now 409 deprecated and SHOULD NOT be generated anymore. Serving agents 410 SHOULD still accept it for a transition period as long as the 411 corresponding hash function is not considered unsafe. See Section 7 412 for details. 414 obs-scheme = "sha1" 416 MUST be parsed case-insensitive. 418 It is important for backward compatibility that the deprecated value 419 for is not phased out too early. Security and compatibility 420 concerns should be carefully weighed before choosing to remove from existing implementations (or not implementing it in new 422 ones). 424 7. Security Considerations 426 The important properties of the hash function used for are 427 the preimage and second preimage resistance. A successful preimage 428 attack would reveal the real Cancel-Key that was used to create the 429 Cancel-Lock of the original article. A successful second preimage 430 attack would allow to create a new, different Cancel-Key that matches 431 a Cancel-Lock too. Both cases would break the authentication system 432 defined in this document. 434 Collision resistance of the hash function used for is less 435 important. Finding two Cancel-Keys that match an arbitary Cancel- 436 Lock is not helpful to break the authentication system defined in 437 this document (if a specific article is defined as target). Only 438 collateral damage like arbitrary deletion or spam is possible. 440 Currently there is no known practicable preimage and second preimage 441 attack against the hash function SHA1. Therefore there is no hurry 442 to replace it. The reasons why this document specifies SHA-256 (aka 443 SHA2-256) are: 445 o The last draft for the authentication system defined in this 446 document is nearly two decades old. The client side 447 implementations are moving forward extremely slowly too 448 (newsreaders from the last millenium are still in heavy use). 449 What is defined today should be strong enough for at least the 450 next decades. 452 o The collision resistance of SHA1 is already broken, therefore it 453 is now obsolete for digital signatures as used in TLS. It is 454 intended that an implementation of the authentication system 455 defined in this document can share the same cryptographic library 456 functions that are used for TLS. 458 o It is intended that the same hash function can be used for 459 and (as base) for the HMAC that is suggested in 460 Section 4. See notes below for HMAC-MD5 and HMAC-SHA1. 462 o The SHA2 family of hash algorithms is widely supported by 463 cryptographic libraries. In contrast, SHA3 is currently not 464 supported by e.g. OpenSSL. 466 The operation HMAC(mid+sec) as suggested in Section 4 must be able to 467 protect the local secret . The Message-ID is public (in 468 the article header). An attacker who wants to steal/use a local 469 secret only need to break this algorithm (regardless of ), 470 because Cancel-Keys are explicitly published for every request to 471 modify or delete existing articles. 473 Even if HMAC-MD5 and HMAC-SHA1 are not considered broken today, it is 474 desired to have some more security margin here. Breaking 475 only allows to authenticate a single forged modify or delete request. 476 With in hand it is possible to forge such requests for all 477 articles that contain Cancel-Locks based on Cancel-Keys generated 478 with this in the past. 480 8. IANA Considerations 482 IANA has registered the following header fields in the Permanent 483 Message Header Field Repository, in accordance with the procedures 484 set out in [RFC3864]: 486 Header field name: Cancel-Lock 488 Applicable protocol: netnews 490 Status: standard 492 Author/change controller: IETF 494 Specification document(s): This document (Section 2.1) 496 Header field name: Cancel-Key 498 Applicable protocol: netnews 500 Status: standard 502 Author/change controller: IETF 504 Specification document(s): This document (Section 2.2) 506 The Netnews Cancel-Lock hash algorithm registry will be maintained by 507 IANA. 509 The registry will be available at . 512 8.1. Algorithm Name Registration Procedure 514 IANA will register new Cancel-Lock hash algorithm names on a First 515 Come First Served basis, as defined in BCP 26 [RFC5226]. IANA has 516 the right to reject obviously bogus registration requests, but will 517 perform no review of claims made in the registration form. 519 Registration of a Netnews Cancel-Lock hash algorithm is requested by 520 filling in the following template and sending it via electronic mail 521 to IANA at : 523 Subject: Registration of Netnews Cancel-Lock hash algorithm X 525 Netnews Cancel-Lock hash algorithm name: 527 Security considerations: 529 Published specification (recommended): 531 Contact for further information: 533 Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE) 535 Owner/Change controller: 537 Note: (Any other information that the author deems relevant may be 538 added here.) 540 Authors may seek community review by posting a specification of their 541 proposed algorithm as an Internet-Draft. Netnews Cancel-Lock hash 542 algorithms intended for widespread use should be standardized through 543 the normal IETF process, when appropriate. 545 8.2. Registration of the Netnews Cancel-Lock hash algorithms 547 This section gives a formal definition of the Netnews Cancel-Lock 548 hash algorithms as required by Section 8.1 for the IANA registry. 550 Netnews hash algorithm name: sha1 552 Security considerations: See Section 7 of this document 554 Published specification: This document 556 Contact for further information: Authors of this document 558 Intended usage: LIMITED USE 560 Owner/Change controller: IESG 562 Note: This algorithm is intended for backward compatibility 564 Netnews hash algorithm name: sha256 566 Security considerations: See Section 7 of this document 567 Published specification: This document 569 Contact for further information: Authors of this document 571 Intended usage: COMMON 573 Owner/Change controller: IESG 575 Note: This algorithm is mandatory to implement 577 9. References 579 9.1. Normative References 581 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 582 Extensions (MIME) Part One: Format of Internet Message 583 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 584 . 586 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 587 Requirement Levels", BCP 14, RFC 2119, 588 DOI 10.17487/RFC2119, March 1997, 589 . 591 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 592 Procedures for Message Header Fields", BCP 90, RFC 3864, 593 DOI 10.17487/RFC3864, September 2004, 594 . 596 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 597 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 598 DOI 10.17487/RFC5226, May 2008, 599 . 601 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 602 Specifications: ABNF", STD 68, RFC 5234, 603 DOI 10.17487/RFC5234, January 2008, 604 . 606 [RFC5536] Murchison, K., Ed., Lindsey, C., and D. Kohn, "Netnews 607 Article Format", RFC 5536, DOI 10.17487/RFC5536, November 608 2009, . 610 [RFC5537] Allbery, R., Ed. and C. Lindsey, "Netnews Architecture and 611 Protocols", RFC 5537, DOI 10.17487/RFC5537, November 2009, 612 . 614 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 615 RFC 7405, DOI 10.17487/RFC7405, December 2014, 616 . 618 [SHA] National Institute of Standards and Technology, "Secure 619 Hash Standard (SHS)", FIPS 180-4, DOI 10.6028/FIPS.180-4, 620 August 2015, . 623 9.2. Informative References 625 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 626 DOI 10.17487/RFC1321, April 1992, 627 . 629 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 630 Hashing for Message Authentication", RFC 2104, 631 DOI 10.17487/RFC2104, February 1997, 632 . 634 [RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 635 (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001, 636 . 638 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 639 Thayer, "OpenPGP Message Format", RFC 4880, 640 DOI 10.17487/RFC4880, November 2007, 641 . 643 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 644 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 645 RFC 6151, DOI 10.17487/RFC6151, March 2011, 646 . 648 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 649 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 650 DOI 10.17487/RFC6234, May 2011, 651 . 653 Appendix A. Acknowledgements 655 The author acknowledges the original author of the Cancel-Lock 656 authentication system as documented in draft-ietf-usefor-cancel-lock: 657 Simon Lyall. He has written the original draft and former version 658 and 659 approved the usage of his work for this document. This document is 660 mostly based on his work and was originally intended as revision 02. 661 It must be renamed because the USEFOR IETF WG is now closed. 663 The author would like to thank the following individuals for 664 contributing their ideas and reviewing this specification: Julien 665 Elie, Richard Kettlewell, Holger Marzen. And Peter Faust, Urs 666 Janssen and Alfred Peters for providing statistic data about the 667 algorithms currently in use. 669 Appendix B. Document History (to be removed by RFC Editor before 670 publication) 672 B.1. Changes since -01 674 o Changed wording in Section 7. 676 o Added example for HMAC calculation in Section 5. 678 o Changed wording in Section 4. 680 o Added use cases to Section 3.2. 682 o Replaced wording "injecting-agent" by "injecting agent". 684 o Added Definition for "LOWER" in Section 2. 686 o Added Section 8.2. 688 o Added Section 8.1. 690 o Added new entries for header field registry in Section 8. 692 o Removed recommendation that moderators and injecting agents should 693 add only one Cancel-Lock or Cancel-Key resprectively to the list 694 in Section 3.1, Section 3.2 and Section 3.3. 696 o Added missing headerfield termination to Section 2.1 and 697 Section 2.2. 699 o Removed definition for "code-string" from Section 2. Added 700 stricter definition "c-lock-string" to Section 2.1. Added 701 backward compatible definition "c-key-string" to Section 2.2. 703 o Use different wording in Section 2.2. 705 o Changed wording to reflect that an injecting agent is allowed to 706 create Cancel-Lock headerfields in Section 2.1. 708 o Fixed wording and typo in Section 2. 710 o Added normative reference to RFC7405 because case-sensitivity is 711 used in ABNF. 713 o Added reference to RFC5536 (Section 2.2) in Section 2. 715 o Added references to RFC4880 and RFC5537 in Section 1. 717 o Replaced the wordings "remove" by "cancel" and "replace" by 718 "supersede". 720 o Modified header and abstract section to no longer list RFC5536 and 721 RFC5537 as updated by this document. 723 B.2. Changes since -00 725 o Added additional note that deprecated "scheme" values should be 726 preserved for backward compatibility as long as reasonable. 728 o Removed deprectated scheme "md5" (not in use anymore). 730 o Added descriptions how to generate "code-string" to Section 2.1 731 and Section 2.2. 733 o Removed length limitiation in ABNF of "scheme". 735 o Changed copyright notice to use text from TLP section 6.c.iii. 737 o Removed references from "abstract" section. 739 o Changed "SHOULD not" into "SHOULD NOT" in Section 6. 741 o Added line wraps to CLI commands in Section 5. 743 B.3. Changes since draft-ietf-usefor-cancel-lock-01 745 o Renamed document because the USEFOR IETF WG is now closed. 747 o Added more details how to check Cancel-Key header fields in 748 Section 3.4. 750 o Added more details to Section 7. 752 o Added updated ABNF for Cancel-Lock and Cancel-Key header fields. 754 o Deprecated "md5" and "sha1" schemes. 756 o Added "sha-256" scheme. 758 o Reworded the abstract section and added references. 760 o Added note to other authentication systems to Section 1. 762 o Added command line check examples to Section 5. 764 B.4. Changes since draft-ietf-usefor-cancel-lock-00 766 o References to SHA-160 changed to SHA1 768 o "scheme" is now a case insensitive token and the number "1" has 769 been changed to "sha1". 771 o Added some examples and fixed the section numbering. 773 o Updated 2nd paragraph on section 2.2 to make clear what exactly is 774 being hashed and how. 776 o Changed paragraph 2 of 3.1 to discourage injection agents from 777 adding the header. 779 o Removed the Clue-string as this complicated the scheme without 780 adding realistic functionality 782 o Moderators can now add these headers under the same conditions as 783 injection agents. 785 Author's Address 786 Michael Baeuerle 787 STZ Elektronik 788 Hofener Weg 33C 789 Remseck, Baden-Wuerttemberg 71686 790 Germany 792 Fax: +49 7146 999061 793 EMail: michael.baeuerle@stz-e.de