wdiff rfc8315.alt-original rfc8315.txt


Independent Submission
Internet Engineering Task Force (IETF)                       M. Baeuerle
Internet-Draft
Request for Comments: 8315                                STZ Elektronik
Updates: 5537 (if approved)                             December 4, 2017
Intended status:                                              February 2018
Category: Standards Track
Expires: June 7, 2018
ISSN: 2070-1721

                    Cancel-Locks in Netnews articles
                 draft-baeuerle-netnews-cancel-lock-09 Articles

Abstract

   This document defines an extension to the Netnews Article Format that
   may be used to authenticate the withdrawal of existing articles.  If
   approved, this
   This document updates RFC5537. RFC 5537.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of six months RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on June 7, 2018.
   https://www.rfc-editor.org/info/rfc8315.

Copyright Notice

   Copyright (c) 2017 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3 ....................................................2
      1.1. Conventions Used in This Document . . . . . . . . . . . .   3
     1.2.  Author's Note . . . . . . . . . . . . . . . . . . . . . .   3 ..........................3
   2. Header Fields . . . . . . . . . . . . . . . . . . . . . . . .   3 ...................................................3
      2.1. Cancel-Lock . . . . . . . . . . . . . . . . . . . . . . .   4 ................................................4
      2.2. Cancel-Key  . . . . . . . . . . . . . . . . . . . . . . .   5 .................................................4
   3. Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   5 .............................................................5
      3.1. Adding an initial Initial Cancel-Lock header field Header Field to a proto-
           article . . . . . . . . . . . . . . . . . . . . . . . . .   6
           Proto-Article ..............................................5
      3.2. Extending the Cancel-Lock header field Header Field of a proto-article   6 Proto-Article ..6
      3.3. Adding a Cancel-Key header field Header Field to a proto-article . . .   7 Proto-Article ........6
      3.4. Extending the Cancel-Key header field Header Field of a proto-article    7 Proto-Article ...7
      3.5. Check a Cancel-Key header field . . . . . . . . . . . . .   7 Header Field ............................7
   4. Calculating the key data  . . . . . . . . . . . . . . . . . .   8 Key Data ........................................8
   5. Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   9 ........................................................9
      5.1. Without UID . . . . . . . . . . . . . . . . . . . . . . .   9 ................................................9
      5.2. With UID  . . . . . . . . . . . . . . . . . . . . . . . .  10 ..................................................10
      5.3. Other examples  . . . . . . . . . . . . . . . . . . . . .  11 Examples ............................................11
      5.4. Manual checks . . . . . . . . . . . . . . . . . . . . . .  11 Checks .............................................12
   6. Obsolete Syntax . . . . . . . . . . . . . . . . . . . . . . .  12 ................................................12
   7. Security Considerations . . . . . . . . . . . . . . . . . . .  13 ........................................13
   8. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15 ............................................15
      8.1. Algorithm Name Registration Procedure . . . . . . . . . .  15 .....................16
      8.2. Change control  . . . . . . . . . . . . . . . . . . . . .  16 Control ............................................16
      8.3. Registration of the Netnews Cancel-Lock hash algorithms .  16 Hash Algorithms ...17
   9. References  . . . . . . . . . . . . . . . . . . . . . . . . .  17 .....................................................18
      9.1. Normative References  . . . . . . . . . . . . . . . . . .  17 ......................................18
      9.2. Informative References  . . . . . . . . . . . . . . . . .  18
   Appendix A. ....................................19
   Acknowledgements . . . . . . . . . . . . . . . . . .  20
   Appendix B.  Document History (to be removed by RFC Editor before
                publication) . . . . . . . . . . . . . . . . . . . .  20
     B.1.  Changes since -08 . . . . . . . . . . . . . . . . . . . .  20
     B.2.  Changes since -07 . . . . . . . . . . . . . . . . . . . .  20
     B.3.  Changes since -06 . . . . . . . . . . . . . . . . . . . .  21
     B.4.  Changes since -05 . . . . . . . . . . . . . . . . . . . .  22
     B.5.  Changes since -04 . . . . . . . . . . . . . . . . . . . .  22
     B.6.  Changes since -03 . . . . . . . . . . . . . . . . . . . .  23
     B.7.  Changes since -02 . . . . . . . . . . . . . . . . . . . .  24
     B.8.  Changes since -01 . . . . . . . . . . . . . . . . . . . .  25
     B.9.  Changes since -00 . . . . . . . . . . . . . . . . . . . .  26
     B.10. Changes since draft-ietf-usefor-cancel-lock-01  . . . . .  26
     B.11. Changes since draft-ietf-usefor-cancel-lock-00  . . . . .  27 ..................................................20
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  27 ..................................................20

1.  Introduction

   The authentication system defined in this document is intended to be
   used as a simple method to verify that the withdrawal of an article
   is valid, valid; that is to say either the poster, posting agent, moderator moderator, or
   injecting agent that processed the original article has requested to
   withdraw it via the use of a cancel control article
   ([RFC5537] Section 5.3) or a Supersedes header field
   ([RFC5537] Section 5.4).

   This document defines two new header fields: Cancel-Lock and Cancel-
   Key.
   Cancel-Key.  The Cancel-Lock header field contains hashes of secret
   data.  The preimages can later be used in the Cancel-Key header field
   to authenticate a cancel or supersede request.

   One property of this system is that it prevents tracking of
   individual users.

   There are other authentication systems available with different
   properties.  When everybody should be able to verify who the
   originator is, e.g. e.g., for control articles to add or remove newsgroups
   ([RFC5537] Section 5.2), an OpenPGP [RFC4880] signature is suited.
   appropriate.

1.1.  Conventions Used in This Document

   Any term not defined in this document has the same meaning as it does
   in [RFC5536] or [RFC5537].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].

1.2.  Author's Note

   Please write the letters "ae" in "Baeuerle" as an a-umlaut (U+00E4,
   "&#228;" in XML), the first letter in "Elie" with an acute accent
   (U+00C9, "&#201;" in XML), the letters "ss" in Janssen as an eszett
   (U+00DF, "&#223;" in XML)
   BCP 14 [RFC2119] [RFC8174] when, and the letters "ue" only when, they appear in Baden-Wuerttemberg all
   capitals, as an u-umlaut (U+00FC, "&#252;" in XML) wherever this is possible. shown here.

2.  Header Fields

   This section describes the formal syntax of the new header fields
   using ABNF [RFC5234].  Non-terminals not defined in this document are
   defined in Section 3 of [RFC5536].

   The new header fields Cancel-Lock and Cancel-Key are defined by this
   document, extended extending the list of article header fields defined in
   [RFC5536].

   Each of these header fields MUST NOT occur more than once in an
   article.

   Both new header field bodies contain lists of encoded values.  Every
   entry is based on a <scheme>:

      scheme       = "sha256" / "sha512" / 1*scheme-char / obs-scheme
      scheme-char  = ALPHA / DIGIT / "-" / "/"

   The hash algorithms for <scheme> are defined in [RFC6234], [RFC6234]; see also
   [RFC1321] and [RFC6151] for MD5, [RFC3174] for SHA1 SHA1, and [SHA] for
   the SHA2 family.  The Base64 encoding used is defined in Section 4 of
   [RFC4648].

   This document defines two values for <scheme>: "sha256" and "sha512".
   The hash algorithm "sha256" is mandatory to implement.

   Because the hash algorithm for <scheme> cannot be negotiated,
   unnecessary proliferation of hash algorithms should be avoided.  The
   hash algorithms "sha224" and "sha384" are only added to the Netnews "Netnews
   Cancel-Lock hash algorithm Hash Algorithms" registry (Section 8.3) because
   implementations exist that supports support them.  Implementations SHOULD NOT
   use the hash algorithms "sha224" and "sha384" to generate <scheme>.

2.1.  Cancel-Lock

      cancel-lock     = "Cancel-Lock:" SP c-lock-list CRLF
      c-lock-list     = [CFWS] c-lock *(CFWS c-lock) [CFWS]
      c-lock          = scheme ":" c-lock-string
      c-lock-string   = *(4base64-char) [base64-terminal]
      base64-char     = ALPHA / DIGIT / "+" / "/"
      base64-terminal = 2base64-char "==" / 3base64-char "="

   Comments in CFWS (comments and/or folding whitespace) can cause
   interoperability problems, so comments SHOULD NOT be generated but
   MUST be accepted.

   If <scheme> is not supported by an implementation, the corresponding
   <c-lock> element MUST be skipped and potential following <c-lock>
   elements MUST NOT be ignored.

   <c-lock-string> is the Base64 encoded Base64-encoded output of a hash operation
   (defined by <scheme>) of the Base64 encoded Base64-encoded key "K" that is intended
   to authenticate the person or agent that created or processed
   respectively
   (respectively) the proto-article up to injection (inclusively):

      Base64(hash(Base64(K)))

   Because of the one-way nature of the hash operation operation, the key "K" is
   not revealed.

2.2.  Cancel-Key

      cancel-key   = "Cancel-Key:" SP c-key-list CRLF
      c-key-list   = [CFWS] c-key *(CFWS c-key) [CFWS]
      c-key        = scheme ":" c-key-string
      c-key-string = c-lock-string / obs-c-key-string

   Comments in CFWS can cause interoperability problems, so comments
   SHOULD NOT be generated but MUST be accepted.

   If <scheme> is not supported by an implementation, the corresponding
   <c-key> element MUST be skipped and potential following <c-key>
   elements MUST NOT be ignored.

   <c-key-string> is the Base64 encoded Base64-encoded key "K" that was used to create
   the <c-lock> element in the Cancel-Lock header field body (as defined
   in Section 2.1 of this document) of the original article:

      Base64(K)

   The relaxed syntax definition of <c-key-string> above is required for
   backward compatibility with implementations that are not compliant
   with this specification.  Compliant implementations SHOULD generate
   valid Base64 (that is to say the syntax of <c-lock-string> as defined
   in Section 2.1 of this document) and MUST accept strings of
   <base64-octet> characters (that is to say the syntax of <obs-c-key-
   string>
   <obs-c-key-string> as defined in Section 6 of this document).

3.  Use

   Use cases:

   o  The poster of an article wants to cancel or supersede existing
      articles.

   o  A moderator wants the ability to cancel articles after approving
      them.

   o  An injecting agent wants to act as a representative for a posting
      agent that has no support for the authentication system described
      in this document.

   o  A news administrator wants the ability to cancel articles that
      were injected by its system (because e.g., (because, for example, they violate
      its abuse policy).

3.1.  Adding an initial Initial Cancel-Lock header field Header Field to a proto-article Proto-Article

   A Cancel-Lock header field MAY be added to a proto-article by the
   poster or posting agent which and will include one or more <c-lock>
   elements.

   If the poster or posting agent doesn't add a Cancel-Lock header field
   to a proto-article, then an injecting agent (or moderator) MAY add
   one, including one or more <c-lock> elements.

   If multiple <c-lock> elements are added to the Cancel-Lock header
   field by a single agent, each <c-lock> element MUST use a unique
   key
   K "K" to improve security.

   If an injecting agent (or moderator) wants to act as a representative
   for a posting agent without support for the authentication system
   described in this document, then it MUST be able to positively
   authenticate the poster and it MUST be able to automatically add a
   working Cancel-Key header field for all proto-articles with
   cancelling or superseding attempts from that poster.

   Other agents MUST NOT add this header field to articles or proto-
   articles
   proto-articles that they process.

3.2.  Extending the Cancel-Lock header field Header Field of a proto-article Proto-Article

   If a Cancel-Lock header field has already been added to a proto-
   article
   proto-article, then any agent further processing the proto-article up
   to the injecting agent (inclusively) MAY append additional <c-lock>
   elements to those already in the header field body.

   If multiple <c-lock> elements are appended to the Cancel-Lock header
   field by a single agent, each <c-lock> element MUST use a unique
   key
   K "K" to improve security.

   If an injecting agent (or moderator) wants to act as a representative
   for a posting agent without support for the authentication system
   described in this document, then the same requirements apply as those
   mentioned in Section 3.1.

   Once an article is injected injected, then this header field MUST NOT be
   altered.  In particular, relaying agents beyond the injecting agent
   MUST NOT alter it.

3.3.  Adding a Cancel-Key header field Header Field to a proto-article Proto-Article

   The Cancel-Key header field contains one or more of the secret
   strings that were used to create the Cancel-Lock header field of the
   original article.  Knowledge of at least one of the secret strings is
   required to create a match for successful authentication.

   A Cancel-Key header field MAY be added to a proto-article containing
   a Control or Supersedes header field by the poster or posting agent
   which
   and will include one or more <c-key> elements.  They will correspond
   to some or all of the <c-lock> elements in the article referenced by
   the Control (with a "cancel" command as defined in [RFC5537]) or
   Supersedes header field.

   If, as mentioned in Section 3.1, an injecting agent (or moderator) or moderator
   (acting as a representative for the posting agent) has added a
   Cancel-Lock header field to an article listed in the Control (with a
   "cancel" command as defined in [RFC5537]) or Supersedes header field - representative for the posting agent - field,
   then (given that it authenticates the poster as being the same as the
   poster of the original article) it MUST add the Cancel-Key header
   field with at least one <c-key> element that corresponds to that
   article.

   Other agents MUST NOT alter this header field.

3.4.  Extending the Cancel-Key header field Header Field of a proto-article Proto-Article

   If a Cancel-Key header field has already been added to a proto-
   article
   proto-article, then any agent further processing the proto-article
   up to the injecting agent (inclusively) MAY append additional <c-key>
   elements to those already in the header field body.

   If, as mentioned in Section 3.2 3.2, an injecting agent (or moderator) or moderator
   (acting as a representative for the posting agent) has extended the
   Cancel-Lock header field in an article listed in the Control (with a
   "cancel" command as defined in [RFC5537]) or Supersedes header field - representative for the posting agent - field,
   then (given that it authenticates the poster as being the same as the
   poster of the original article) it MUST extend the Cancel-Key header
   field body with at least one <c-key> element that corresponds to that
   article.

   Once an article is injected injected, then this header field MUST NOT be
   altered.  In particular, relaying agents beyond the injecting agent
   MUST NOT alter it.

3.5.  Check a Cancel-Key header field Header Field

   When a relaying or serving agent receives an article that attempts to
   cancel or supersede a previous article via a Control (with a "cancel"
   command as defined in [RFC5537]) or Supersedes header field, the
   system defined in this document can be used for authentication.  The
   general handling of articles containing such attempts as defined in
   [RFC5537] is not changed by this document.

   To process the authentication, the received article must contain a
   Cancel-Key header field and the original article must contain a
   Cancel-Lock header field.  If this is not the case, the
   authentication is not possible (failed).

   For the authentication check, every supported <c-key> element from
   the received article is processed as follows:

   1.  The <c-key-string> part of the <c-key> element is hashed using
       the algorithm defined by its <scheme> part.

   2.  For all each <c-lock> elements element with the same <scheme> in the original
       article their
       article, its <c-lock-string> part is compared to the calculated
       hash.

   3.  If one a <c-lock-string> part is equal, equal to the calculated hash, the
       authentication is passed and the processing of further elements
       can be aborted.

   4.  If no match was found and there are no more <c-key> elements to
       process, the authentication failed.

4.  Calculating the key data Key Data

   The following algorithm is RECOMMENDED to calculate the key "K" based
   on a local secret <sec>.

   The result of the function: function

      K = HMAC(sec, uid+mid)

   is the key "K" for an article with a Message-ID <mid> that belongs to
   the User-ID (or UID) <uid> (e.g. (e.g., the login name of the user).  HMAC  The
   Hashed Message Authentication Code (HMAC) is outlined in [RFC2104].
   The HMAC is computed over the data <uid+mid> (with '+' "+" representing
   the concatenation operation), using <sec> as a secret key held
   locally that can be used for multiple articles.  This method removes
   the need for a per-article database containing the keys used for
   every article.

   A posting agent must add the Message-ID header field to the proto-
   article
   proto-article itself and use the content of the header field body as
   <mid> (excluding whitespace, whitespace but including literal angle brackets).

   The User-ID <uid> must not contain angle brackets (to ensure that
   concatenation of different <uid> and <mid> elements cannot give the
   same results).

   A posting agent, agent that uses a dedicated local secret <sec> for every
   user,
   user should use an empty string for the <uid> part.

   In general general, different values for the secret <sec> must be used if
   multiple <c-lock> elements are added by a single agent.

   The local secret <sec> should have a length of at least the output
   size of the hash function that is used by the HMAC
   (256 bit bits / 32 octets for SHA256) and must be a cryptographically
   random value [RFC4086].

   Note that the hash algorithm used as the base for the HMAC operation
   is not required to be the same as that specified by <scheme>.  An
   agent that verifies a Cancel-Key header field body simply checks
   whether one of its <c-key> elements matches one of the <c-lock>
   elements with the same <scheme> in the Cancel-Lock header field body
   of the original article.

   Common libraries like OpenSSL can be used for the cryptographic
   operations.

5.  Examples

5.1.  Without UID

   Example data for creation of a <c-lock> element with HMAC-SHA256 and
   an empty string as <uid> (as suggested recommended in Section 4 for posting
   agents):

      Message-ID: <12345@mid.example>

      mid: <12345@mid.example>
      sec: ExampleSecret
      K  : HMAC-SHA256(sec, mid) ;mid used as data, sec as secret key

   Calculation of Base64(K) using the OpenSSL command line command-line tools in a
   POSIX shell:

      $ printf "%s" "<12345@mid.example>" \
        | openssl dgst -sha256 -hmac "ExampleSecret" -binary \
        | openssl enc -base64
      qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA=

   This can be used as <c-key-string> for cancelling or superseding the
   article <12345@mid.example>.

   Calculation of Base64(SHA256(Base64(K))) required for <c-lock-string>
   using the OpenSSL command line command-line tools in a POSIX shell:

      $ printf "%s" "qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA=" \
        | openssl dgst -sha256 -binary \
        | openssl enc -base64
      s/pmK/3grrz++29ce2/mQydzJuc7iqHn1nqcJiQTPMc=

   Inserted into the Cancel-Lock header field body of the article
   <12345@mid.example>
   <12345@mid.example>, it looks like this:

      Cancel-Lock: sha256:s/pmK/3grrz++29ce2/mQydzJuc7iqHn1nqcJiQTPMc=

   Inserted into the Cancel-Key header field body of an article that
   should cancel or supersede the article <12345@mid.example> <12345@mid.example>, it looks
   like this:

      Cancel-Key: sha256:qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA=

5.2.  With UID

   Example data for creation of a <c-lock> element with HMAC-SHA256 and
   "JaneDoe" as <uid> (as suggested recommended in Section 4):

      Message-ID: <12345@mid.example>

      uid: JaneDoe
      mid: <12345@mid.example>
      sec: AnotherSecret
      K  : HMAC-SHA256(sec, uid+mid) ;uid+mid as data, sec as secret key

   Calculation of Base64(K) using the OpenSSL command line command-line tools in a
   POSIX shell:

      $ printf "%s" "JaneDoe<12345@mid.example>" \
        | openssl dgst -sha256 -hmac "AnotherSecret" -binary \
        | openssl enc -base64
      yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys=

   This can be used as <c-key-string> for cancelling or superseding the
   article <12345@mid.example>.

   Calculation of Base64(SHA256(Base64(K))) required for <c-lock-string>
   using the OpenSSL command line command-line tools in a POSIX shell:

      $ printf "%s" "yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys=" \
        | openssl dgst -sha256 -binary \
        | openssl enc -base64
      NSBTz7BfcQFTCen+U4lQ0VS8VIlZao2b8mxD/xJaaeE=

   Inserted into the Cancel-Lock header field body of the article
   <12345@mid.example>
   <12345@mid.example>, it looks like this:

      Cancel-Lock: sha256:NSBTz7BfcQFTCen+U4lQ0VS8VIlZao2b8mxD/xJaaeE=

   Inserted into the Cancel-Key header field body of an article that
   should cancel or supersede the article <12345@mid.example> <12345@mid.example>, it looks
   like this:

      Cancel-Key: sha256:yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys=

5.3.  Other examples

   Other Examples

   Another matching pair of Cancel-Lock and Cancel-Key header fields:

      Cancel-Lock: sha256:RrKLp7YCQc9T8HmgSbxwIDlnCDWsgy1awqtiDuhedRo=
      Cancel-Key: sha256:sSkDke97Dh78/d+Diu1i3dQ2Fp/EMK3xE2GfEqZlvK8=

   With obsolete syntax (uses a <c-key-string> with invalid/missing
   Base64 padding):

      Cancel-Lock: sha1:bNXHc6ohSmeHaRHHW56BIWZJt+4=
      Cancel-Key: ShA1:aaaBBBcccDDDeeeFFF

   Let's assume that all the examples above are associated to the same
   article (e.g. (e.g., created by different agents):

      Cancel-Lock: sha256:s/pmK/3grrz++29ce2/mQydzJuc7iqHn1nqcJiQTPMc=
                   sha256:NSBTz7BfcQFTCen+U4lQ0VS8VIlZao2b8mxD/xJaaeE=
                   sha256:RrKLp7YCQc9T8HmgSbxwIDlnCDWsgy1awqtiDuhedRo=
                   sha1:bNXHc6ohSmeHaRHHW56BIWZJt+4=
      Cancel-Key: sha256:qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA=
                  sha256:yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys=
                  sha256:sSkDke97Dh78/d+Diu1i3dQ2Fp/EMK3xE2GfEqZlvK8=
                  ShA1:aaaBBBcccDDDeeeFFF

   Remember that parsing for <scheme> must be parsed case insensitive.

5.4.  Manual checks Checks

   Manual checks using the OpenSSL command line command-line tools in a POSIX shell:

      $ printf "%s" "qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA=" \
        | openssl dgst -sha256 -binary \
        | openssl enc -base64
      s/pmK/3grrz++29ce2/mQydzJuc7iqHn1nqcJiQTPMc=

      $ printf "%s" "yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys=" \
        | openssl dgst -sha256 -binary \
        | openssl enc -base64
      NSBTz7BfcQFTCen+U4lQ0VS8VIlZao2b8mxD/xJaaeE=

      $ printf "%s" "sSkDke97Dh78/d+Diu1i3dQ2Fp/EMK3xE2GfEqZlvK8=" \
        | openssl dgst -sha256 -binary \
        | openssl enc -base64
      RrKLp7YCQc9T8HmgSbxwIDlnCDWsgy1awqtiDuhedRo=

      $ printf "%s" "aaaBBBcccDDDeeeFFF" \
        | openssl dgst -sha1 -binary \
        | openssl enc -base64
      bNXHc6ohSmeHaRHHW56BIWZJt+4=

6.  Obsolete Syntax

   Implementations of earlier drafts draft versions of this specification
   defined a different value for <scheme> than this version.  The
   following value for <scheme> is now deprecated and SHOULD NOT be
   generated anymore.  Serving agents SHOULD still accept it for a
   transition period as long as the corresponding hash function is not
   considered unsafe (see Section 7 for details), details) or already marked as
   OBSOLETE in the Netnews "Netnews Cancel-Lock hash algorithm Hash Algorithms" registry
   (Section 8.3).

      obs-scheme = "sha1"

   It is important for backward compatibility that the deprecated value
   for <scheme> is not phased out too early.  Security and compatibility
   concerns should be carefully weighed before choosing to remove <obs-
   scheme>
   <obs-scheme> from existing implementations (or not implementing it in
   new ones).

   Earlier drafts draft versions of this specification allowed more liberal
   syntax for <c-key-string>:

      obs-c-key-string = 1*base64-octet
      base64-octet     = ALPHA / DIGIT / "+" / "/" / "="

   <obs-c-key-string> SHOULD NOT be generated but MUST be accepted.

7.  Security Considerations

   The authentication system defined in this document provides no
   integrity checking
   integrity-checking properties.  Arbitrary modifications can be
   applied to an article on its way through the network, regardless of
   the presence of a Cancel-Key header field.  A serving agent, who agent that
   receives an article that contains a Cancel-Key header field with a
   matching <c-key> element, element only get gets the information that the
   withdrawal of the target article was approved by a legitimate person
   or agent.

   Example: A valid <c-key> element is extracted from a cancel control
   article and inserted into a forged supersede article.  All servers on
   the network that receive the forged supersede article before the
   cancel control article should accept the forged supersede.  But
   because everybody can post articles with forged identity information
   in the header (same as with spam e-mail), email), the same result can be
   achieved by sending a forged new article using no authentication
   system at all.

   For originator and integrity checks checks, a signature based signature-based authentication
   system is required (normally (normally, OpenPGP [RFC4880] is used for this
   purpose).  Both systems can be combined.

   The important property of the hash function used for <scheme> is the
   preimage resistance.  A successful preimage attack either reveals the
   real Cancel-Key (that was used to create the Cancel-Lock of the
   original article) or gives a different Cancel-Key (that matches a
   Cancel-Lock too).  This would break the authentication system defined
   in this document.

   Collision resistance of the hash function used for <scheme> is less
   important.  Finding two <c-key> elements for the Cancel-Key header
   field that match to a <c-lock> element of an arbitrary Cancel-Lock
   header field is not helpful to break the authentication system
   defined in this document (if a specific article is defined as the
   target).  Only collateral damage by arbitrary cancel or supersede is
   possible.

   Currently

   Currently, there is no known practicable preimage and second preimage
   attack against the hash function SHA1.  Therefore  Therefore, there is no hurry
   to replace it.  The reasons why this document specifies hash
   functions from the SHA2 family are:

   o  The last draft for previous specification of the authentication system defined in
      this document -- [USEFOR-CANCEL-LOCK] -- is nearly two decades
      old.  The client side client-side implementations are moving forward extremely slowly
      slowly, too (newsreaders from the last millennium are still in
      heavy use).  What is defined today should be strong enough for at least the
      next decades. two decades or so.

   o  The collision resistance of SHA1 is already broken, therefore broken; therefore, it
      is now obsolete for digital signatures as used in TLS. Transport Layer
      Security (TLS).  It is intended that an implementation of the
      authentication system defined in this document can share the same
      cryptographic library functions that are used for TLS.

   o  It is intended that the same hash function can be used for
      <scheme> and (as the base) for the HMAC that is suggested recommended in
      Section 4.  See notes below for HMAC-MD5 and HMAC-SHA1.

   o  The SHA2 family of hash algorithms is widely supported by
      cryptographic libraries.  In contrast, SHA3 is currently too
      recent and has not been studied enough to be considered more
      secure than SHA2.

   The operation HMAC(sec, uid+mid) as suggested recommended in Section 4 must be
   able to protect the local secret <sec>.  The Message-ID <mid> is
   public (in the Message-ID header field body) body), and <uid> is optional.
   An attacker who wants to steal/use a local secret only need needs to break
   this algorithm (regardless of <scheme>), because Cancel-Key header
   fields are explicitly published for every request to cancel or
   supersede existing articles.

   Even if HMAC-MD5 and HMAC-SHA1 are not considered broken today, it is
   desired to have some more security a greater margin for security here.  Breaking
   <scheme> only allows to authenticate the authentication of a single forged cancel or
   supersede request.  With <sec> in hand hand, it is possible to forge such
   requests for all articles that contain Cancel-Lock header field
   bodies with elements that are were generated with this <sec> in the past.
   Changing <sec> in at regular intervals can be used to mitigate the potential
   damage.

   If an agent adds or appends multiple <c-lock> elements, it must not
   use the same K for them (by using different secrets <sec>). (<sec>)).  Adding
   multiple <c-lock> elements with the same <scheme> and the same K
   makes no sense (would (because it would result in identical <c-lock> elements),
   therefore
   elements); therefore, the case with of different <scheme> values is
   relevant: A a preimage attack on the different hash algorithms may be
   easier if the attacker knows that the output of them those hash algorithms
   was created with the same input.

   If an implementation chooses to not implement the key calculation
   algorithm recommended in Section 4, 4 or to implement it with the HMAC
   based on a different hash function than <scheme>, the key size used
   should match the output size of the hash function used for <scheme>.

8.  IANA Considerations

   IANA has registered the following header fields in the Permanent "Permanent
   Message Header Field Repository, Names" registry, in accordance with the
   procedures set out in [RFC3864]:

      Header field name: Cancel-Lock
      Applicable protocol: netnews
      Status: standard
      Author/change controller: IETF
      Specification document(s): This document RFC 8315

      Header field name: Cancel-Key
      Applicable protocol: netnews
      Status: standard
      Author/change controller: IETF
      Specification document(s): This document RFC 8315

   The Netnews "Netnews Cancel-Lock hash algorithm Hash Algorithms" registry will be is maintained by
   IANA.

   The registry will be is available at <https://www.iana.org/assignments/
   netnews-parameters/netnews-parameters.xhtml#cancel-lock-hash-
   algorithms>.
   <https://www.iana.org/assignments/netnews-parameters/>.

8.1.  Algorithm Name Registration Procedure

   IANA will register new Cancel-Lock hash algorithm names on a First
   Come First Served basis, as defined in BCP 26 [RFC8126].  IANA has
   the right to reject obviously bogus registration requests, requests but will
   perform no review of claims made in the registration form.

   Registration of a Netnews Cancel-Lock hash algorithm is requested by
   filling in the following template and sending it via electronic mail
   to IANA at <iana@iana.org>:

      Subject: Registration of Netnews Cancel-Lock hash algorithm X
      Netnews Cancel-Lock hash algorithm name:
      Security considerations:
      Published specification (recommended):
      Contact for further information:
      Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE)
      Owner/Change controller:
      Note: (Any other information that the author deems relevant may be
         added here.)

   Any name that conforms to the syntax of a Netnews Cancel-Lock hash
   algorithm (see the definition of <scheme> in Section 2) can be used.

   Especially, used;
   in particular, Netnews Cancel-Lock algorithms are named by strings
   consisting of letters, digits, hyphens hyphens, and/or slashes.

   Authors may seek community review by posting a specification of their
   proposed algorithm as an Internet-Draft.  Netnews Cancel-Lock hash
   algorithms intended for widespread use should be standardized through
   the normal IETF process, when appropriate.

   The IESG is considered to be the owner of all Netnews Cancel-Lock
   hash algorithms that are on the IETF Standards Track.

8.2.  Change control Control

   Once a Netnews Cancel-Lock hash algorithm registration has been
   published by IANA, the owner may request a change to its definition.
   The change request follows the same procedure as the initial
   registration request.

   The owner of a Netnews Cancel-Lock hash algorithm may pass
   responsibility for the algorithm to another person or agency by
   informing IANA; this can be done without discussion or review.

   The IESG may reassign responsibility for a Netnews Cancel-Lock hash
   algorithm.  The most common case of reason for this will would be to enable
   changes to be made to algorithms where the owner of the registration
   has died, has moved out of contact, or is otherwise unable to make
   changes that are important to the community.

   Netnews Cancel-Lock hash algorithm registrations MUST NOT be deleted;
   algorithms deleted.
   Algorithms that are no longer believed appropriate for use can be
   declared OBSOLETE by a change to their "intended usage" field; such
   algorithms will be clearly marked in the registry published by IANA.

   The IESG is considered to be the owner of all Netnews Cancel-Lock
   hash algorithms that are on the IETF Standards Track.

8.3.  Registration of the Netnews Cancel-Lock hash algorithms Hash Algorithms

   This section gives a formal definition of the Netnews Cancel-Lock
   hash algorithms as required by Section 8.1 for the IANA registry.

      Netnews Cancel-Lock hash algorithm name: md5
      Security considerations: See corresponding section Section 7 of this document
      Published specification: This document RFC 8315
      Contact for further information: Author of this document
      Intended usage: OBSOLETE
      Owner/Change controller: IESG <iesg@ietf.org>
      Note: Do not use this algorithm anymore

      Netnews Cancel-Lock hash algorithm name: sha1
      Security considerations: See corresponding section Section 7 of this document
      Published specification: This document RFC 8315
      Contact for further information: Author of this document
      Intended usage: LIMITED USE
      Owner/Change controller: IESG <iesg@ietf.org>
      Note: This algorithm is intended for backward compatibility

      Netnews Cancel-Lock hash algorithm name: sha224
      Security considerations: See corresponding section Section 7 of this document
      Published specification: This document RFC 8315
      Contact for further information: Author of this document
      Intended usage: LIMITED USE
      Owner/Change controller: IESG <iesg@ietf.org>
      Note: sha256 should be used instead, instead; this is a truncated variant
      Netnews Cancel-Lock hash algorithm name: sha256
      Security considerations: See corresponding section of Section 7 this document
      Published specification: This document RFC 8315
      Contact for further information: Author of this document
      Intended usage: COMMON
      Owner/Change controller: IESG <iesg@ietf.org>
      Note: This algorithm is mandatory to implement

      Netnews Cancel-Lock hash algorithm name: sha384
      Security considerations: See corresponding section Section 7 of this document
      Published specification: This document RFC 8315
      Contact for further information: Author of this document
      Intended usage: LIMITED USE
      Owner/Change controller: IESG <iesg@ietf.org>
      Note: sha512 should be used instead, instead; this is a truncated variant

      Netnews Cancel-Lock hash algorithm name: sha512
      Security considerations: See corresponding section Section 7 of this document
      Published specification: This document RFC 8315
      Contact for further information: Author of this document
      Intended usage: COMMON
      Owner/Change controller: IESG <iesg@ietf.org>
      Note: This algorithm is optional

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
              Procedures for Message Header Fields", BCP 90, RFC 3864,
              DOI 10.17487/RFC3864, September 2004,
              <https://www.rfc-editor.org/info/rfc3864>.

   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC 4086,
              DOI 10.17487/RFC4086, June 2005,
              <https://www.rfc-editor.org/info/rfc4086>.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
              <https://www.rfc-editor.org/info/rfc4648>.

   [RFC5234]  Crocker, D., Ed. Ed., and P. Overell, "Augmented BNF for
              Syntax Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <https://www.rfc-editor.org/info/rfc5234>.

   [RFC5536]  Murchison, K., Ed., Lindsey, C., and D. Kohn, "Netnews
              Article Format", RFC 5536, DOI 10.17487/RFC5536,
              November 2009, <https://www.rfc-editor.org/info/rfc5536>.

   [RFC5537]  Allbery, R., Ed. Ed., and C. Lindsey, "Netnews Architecture
              and Protocols", RFC 5537, DOI 10.17487/RFC5537,
              November 2009, <https://www.rfc-editor.org/info/rfc5537>.

   [RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and SHA-based HMAC and HKDF)", RFC 6234,
              DOI 10.17487/RFC6234, May 2011,
              <https://www.rfc-editor.org/info/rfc6234>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in
              RFC 2119 Key Words", BCP 14, RFC 8174,
              DOI 10.17487/RFC8174, May 2017,
              <https://www.rfc-editor.org/info/rfc8174>.

9.2.  Informative References

   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
              DOI 10.17487/RFC1321, April 1992,
              <https://www.rfc-editor.org/info/rfc1321>.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing
              Keyed-Hashing for Message Authentication", RFC 2104,
              DOI 10.17487/RFC2104, February 1997,
              <https://www.rfc-editor.org/info/rfc2104>.

   [RFC3174]  Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
              (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001,
              <https://www.rfc-editor.org/info/rfc3174>.

   [RFC4880]  Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
              Thayer, "OpenPGP Message Format", RFC 4880,
              DOI 10.17487/RFC4880, November 2007,
              <https://www.rfc-editor.org/info/rfc4880>.

   [RFC6151]  Turner, S. and L. Chen, "Updated Security Considerations
              for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
              RFC 6151, DOI 10.17487/RFC6151, March 2011,
              <https://www.rfc-editor.org/info/rfc6151>.

   [SHA]      National Institute of Standards and Technology, "Secure
              Hash Standard (SHS)", FIPS 180-4,
              DOI 10.6028/FIPS.180-4, 10.6028/NIST.FIPS.180-4, August 2015,
              <http://nvlpubs.nist.gov/nistpubs/FIPS/
              NIST.FIPS.180-4.pdf>.

   [USEFOR-CANCEL-LOCK]
              Lyall, S., "Cancel-Locks in Usenet articles.", Work in
              Progress, draft-ietf-usefor-cancel-lock-01, November 1998.

Appendix A.

Acknowledgements

   The author acknowledges the original author of the Cancel-Lock
   authentication system system, as documented in draft-ietf-usefor-cancel-lock: [USEFOR-CANCEL-LOCK]: Simon
   Lyall.  He has written  Simon wrote the original draft and former version
   [USEFOR-CANCEL-LOCK] document and approved the usage of
   his work for this document.  This document is mostly based on his work and
   work.  (It was originally intended as revision 02.  It must be 02 but was renamed
   because the USEFOR IETF WG is now closed. closed.)

   The author would like to thank the following individuals for
   contributing their ideas and reviewing this specification: Russ
   Allbery, Urs Janssen, Richard Kettlewell, Marcel Logen, Holger
   Marzen, Dennis Preiser, and Emil Schuster.  And  Thanks also to Peter
   Faust and Alfred Peters for providing statistic statistical data about the
   algorithms currently in use.

   Special thanks to the Document Shepherd, Julien Elie Elie; and to the
   Responsible
   responsible Area Director, Alexey Melnikov.

Author's Address

   Michael Baeuerle
   STZ Elektronik
   Hofener Weg 33C
   Remseck, Baden-Wuerttemberg  71686
   Germany

   Fax:   +49 7146 999061
   EMail:
   Email: michael.baeuerle@stz-e.de