Internet DRAFT - draft-baeuerle-netnews-cancel-lock
draft-baeuerle-netnews-cancel-lock
Independent Submission M. Baeuerle
Internet-Draft STZ Elektronik
Updates: 5537 (if approved) December 4, 2017
Intended status: Standards Track
Expires: June 7, 2018
Cancel-Locks in Netnews articles
draft-baeuerle-netnews-cancel-lock-09
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 document updates RFC5537.
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 of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents 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.
Copyright Notice
Copyright (c) 2017 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.
Baeuerle Expires June 7, 2018 [Page 1]
Internet-Draft Cancel-Locks December 2017
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 3
1.2. Author's Note . . . . . . . . . . . . . . . . . . . . . . 3
2. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Cancel-Lock . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Cancel-Key . . . . . . . . . . . . . . . . . . . . . . . 5
3. Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Adding an initial Cancel-Lock header field to a proto-
article . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Extending the Cancel-Lock header field of a proto-article 6
3.3. Adding a Cancel-Key header field to a proto-article . . . 7
3.4. Extending the Cancel-Key header field of a proto-article 7
3.5. Check a Cancel-Key header field . . . . . . . . . . . . . 7
4. Calculating the key data . . . . . . . . . . . . . . . . . . 8
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Without UID . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. With UID . . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Other examples . . . . . . . . . . . . . . . . . . . . . 11
5.4. Manual checks . . . . . . . . . . . . . . . . . . . . . . 11
6. Obsolete Syntax . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8.1. Algorithm Name Registration Procedure . . . . . . . . . . 15
8.2. Change control . . . . . . . . . . . . . . . . . . . . . 16
8.3. Registration of the Netnews Cancel-Lock hash algorithms . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. 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
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27
Baeuerle Expires June 7, 2018 [Page 2]
Internet-Draft Cancel-Locks December 2017
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, that is to say either the poster, posting agent, 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. 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. for control articles to add or remove newsgroups
([RFC5537] Section 5.2), an OpenPGP [RFC4880] signature is suited.
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,
"ä" in XML), the first letter in "Elie" with an acute accent
(U+00C9, "É" in XML), the letters "ss" in Janssen as an eszett
(U+00DF, "ß" in XML) and the letters "ue" in Baden-Wuerttemberg
as an u-umlaut (U+00FC, "ü" in XML) wherever this is possible.
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].
Baeuerle Expires June 7, 2018 [Page 3]
Internet-Draft Cancel-Locks December 2017
The new header fields Cancel-Lock and Cancel-Key are defined by this
document, extended 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], see also
[RFC1321] and [RFC6151] for MD5, [RFC3174] for 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
Cancel-Lock hash algorithm registry (Section 8.3) because
implementations exist that supports 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 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 output of a hash operation
(defined by <scheme>) of the Base64 encoded key "K" that is intended
to authenticate the person or agent that created or processed
respectively the proto-article up to injection (inclusively):
Baeuerle Expires June 7, 2018 [Page 4]
Internet-Draft Cancel-Locks December 2017
Base64(hash(Base64(K)))
Because of the one-way nature of the hash 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 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> 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 representative for a posting agent
that has no support for the authentication system described in
this document.
Baeuerle Expires June 7, 2018 [Page 5]
Internet-Draft Cancel-Locks December 2017
o A news administrator wants the ability to cancel articles that
were injected by its system (because e.g., they violate its abuse
policy).
3.1. Adding an initial Cancel-Lock header field to a proto-article
A Cancel-Lock header field MAY be added to a proto-article by the
poster or posting agent which 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 to improve security.
If an injecting agent (or moderator) wants to act 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 that they process.
3.2. Extending the Cancel-Lock header field of a proto-article
If a Cancel-Lock header field has already been added to a 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 to improve security.
If an injecting agent (or moderator) wants to act representative for
a posting agent without support for the authentication system
described in this document, then the same requirements apply as
mentioned in Section 3.1.
Once an article is injected then this header field MUST NOT be
altered. In particular, relaying agents beyond the injecting agent
MUST NOT alter it.
Baeuerle Expires June 7, 2018 [Page 6]
Internet-Draft Cancel-Locks December 2017
3.3. Adding a Cancel-Key header field to a 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 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)
has added a Cancel-Lock header field to an article listed in the
Control (with "cancel" command as defined in [RFC5537]) or Supersedes
header field - representative for the posting agent - 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 of a proto-article
If a Cancel-Key header field has already been added to a 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 an injecting agent (or moderator) has
extended the Cancel-Lock header field in an article listed in the
Control (with "cancel" command as defined in [RFC5537]) or Supersedes
header field - representative for the posting agent - 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 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
When a relaying or serving agent receives an article that attempts to
cancel or supersede a previous article via Control (with a "cancel"
command as defined in [RFC5537]) or Supersedes header field, the
Baeuerle Expires June 7, 2018 [Page 7]
Internet-Draft Cancel-Locks December 2017
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 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 <c-lock> elements with the same <scheme> in the original
article their <c-lock-string> part is compared to the calculated
hash.
3. If one is equal, 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
The following algorithm is RECOMMENDED to calculate the key "K" based
on a local secret <sec>.
The result of the function:
K = HMAC(sec, uid+mid)
is the key "K" for an article with Message-ID <mid> that belongs to
the User-ID <uid> (e.g. the login name of the user). HMAC is
outlined in [RFC2104]. 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 itself and use the content of the header field body as <mid>
(excluding whitespace, but including literal angle brackets).
Baeuerle Expires June 7, 2018 [Page 8]
Internet-Draft Cancel-Locks December 2017
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, that uses a dedicated local secret <sec> for every
user, should use an empty string for the <uid> part.
In 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 HMAC (256 bit / 32 octets
for SHA256) and must be a cryptographically random value [RFC4086].
Note that the hash algorithm used as base for the HMAC operation is
not required to be the same as 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
empty string as <uid> (as suggested 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 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>.
Baeuerle Expires June 7, 2018 [Page 9]
Internet-Draft Cancel-Locks December 2017
Calculation of Base64(SHA256(Base64(K))) required for <c-lock-string>
using the OpenSSL 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 article
<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 article <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 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 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 tools in a POSIX shell:
Baeuerle Expires June 7, 2018 [Page 10]
Internet-Draft Cancel-Locks December 2017
$ printf "%s" "yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys=" \
| openssl dgst -sha256 -binary \
| openssl enc -base64
NSBTz7BfcQFTCen+U4lQ0VS8VIlZao2b8mxD/xJaaeE=
Inserted into the Cancel-Lock header field body of article
<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 article <12345@mid.example> it looks like
this:
Cancel-Key: sha256:yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys=
5.3. Other examples
Other 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. 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 <scheme> must be parsed case insensitive.
5.4. Manual checks
Manual checks using the OpenSSL command line tools in a POSIX shell:
Baeuerle Expires June 7, 2018 [Page 11]
Internet-Draft Cancel-Locks December 2017
$ 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 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), or already marked as OBSOLETE in the Netnews
Cancel-Lock hash algorithm 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> from existing implementations (or not implementing it in new
ones).
Earlier drafts 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.
Baeuerle Expires June 7, 2018 [Page 12]
Internet-Draft Cancel-Locks December 2017
7. Security Considerations
The authentication system defined in this document provides no
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
receives an article that contains a Cancel-Key header field with a
matching <c-key> element, only get 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), the same result can be
achieved by sending a forged new article using no authentication
system at all.
For originator and integrity checks a signature based authentication
system is required (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
target). Only collateral damage by arbitrary cancel or supersede is
possible.
Currently there is no known practicable preimage and second preimage
attack against the hash function SHA1. 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 the authentication system defined in this
document is nearly two decades old. The client side
implementations are moving forward extremely slowly too
(newsreaders from the last millennium are still in heavy use).
Baeuerle Expires June 7, 2018 [Page 13]
Internet-Draft Cancel-Locks December 2017
What is defined today should be strong enough for at least the
next decades.
o The collision resistance of SHA1 is already broken, therefore it
is now obsolete for digital signatures as used in 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 base) for the HMAC that is suggested 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 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) and <uid> is optional.
An attacker who wants to steal/use a local secret only need 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 margin here. Breaking <scheme>
only allows to authenticate a single forged cancel or supersede
request. With <sec> in hand it is possible to forge such requests
for all articles that contain Cancel-Lock header field bodies with
elements that are generated with this <sec> in the past. Changing
<sec> in 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>). Adding
multiple <c-lock> elements with the same <scheme> and the same K
makes no sense (would result in identical <c-lock> elements),
therefore the case with different <scheme> is relevant: A preimage
attack on the different hash algorithms may be easier if the attacker
knows that the output of them was created with the same input.
If an implementation chooses to not implement the key calculation
algorithm recommended in Section 4, or to implement it with 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>.
Baeuerle Expires June 7, 2018 [Page 14]
Internet-Draft Cancel-Locks December 2017
8. IANA Considerations
IANA has registered the following header fields in the Permanent
Message Header Field Repository, 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
Header field name: Cancel-Key
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document
The Netnews Cancel-Lock hash algorithm registry will be maintained by
IANA.
The registry will be available at <https://www.iana.org/assignments/
netnews-parameters/netnews-parameters.xhtml#cancel-lock-hash-
algorithms>.
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, 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 definition of <scheme> in Section 2) can be used.
Baeuerle Expires June 7, 2018 [Page 15]
Internet-Draft Cancel-Locks December 2017
Especially, Netnews Cancel-Lock algorithms are named by strings
consisting of letters, digits, 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
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 this will 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 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
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 of this document
Published specification: This document
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
Baeuerle Expires June 7, 2018 [Page 16]
Internet-Draft Cancel-Locks December 2017
Netnews Cancel-Lock hash algorithm name: sha1
Security considerations: See corresponding section of this document
Published specification: This document
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 of this document
Published specification: This document
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, this is a truncated variant
Netnews Cancel-Lock hash algorithm name: sha256
Security considerations: See corresponding section of this document
Published specification: This document
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 of this document
Published specification: This document
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, this is a truncated variant
Netnews Cancel-Lock hash algorithm name: sha512
Security considerations: See corresponding section of this document
Published specification: This document
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>.
Baeuerle Expires June 7, 2018 [Page 17]
Internet-Draft Cancel-Locks December 2017
[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. 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. 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>.
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 for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>.
Baeuerle Expires June 7, 2018 [Page 18]
Internet-Draft Cancel-Locks December 2017
[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,
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, November 1998.
Baeuerle Expires June 7, 2018 [Page 19]
Internet-Draft Cancel-Locks December 2017
Appendix A. Acknowledgements
The author acknowledges the original author of the Cancel-Lock
authentication system as documented in draft-ietf-usefor-cancel-lock:
Simon Lyall. He has written the original draft and former version
[USEFOR-CANCEL-LOCK] and approved the usage of his work for this
document. This document is mostly based on his work and was
originally intended as revision 02. It must be renamed because the
USEFOR IETF WG is now 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, Emil Schuster. And Peter Faust and Alfred
Peters for providing statistic data about the algorithms currently in
use.
Special thanks to the Document Shepherd, Julien Elie and to the
Responsible Area Director, Alexey Melnikov.
Appendix B. Document History (to be removed by RFC Editor before
publication)
B.1. Changes since -08
o Removed space from link in Section 8 (reported by Julien Elie).
o Added note in Section 4 that whitespace from the header field body
should not be used for <mid> (suggested by Julien Elie).
o Added relaying agent to Section 3.5 because of RFC5537 Section 3.6
Point 5 (reported by Julien Elie).
o Corrected definition of <c-key-list> in Section 2.2 (reported by
Julien Elie).
o Changed wording in Section 2 and Section 7 (suggested by Julien
Elie).
o Replaced words in abstract section with the ones from Section 1
(suggested by Julien Elie).
B.2. Changes since -07
o Fixed line length problems in Section 8.3.
Baeuerle Expires June 7, 2018 [Page 20]
Internet-Draft Cancel-Locks December 2017
o Use NBSP for "e.g. OpenSSL" in Section 7 to prevent insertion of
additional space by file format converters (suggested by Julien
Elie).
o Replaced reference to obsolete RFC5226 with reference to successor
RFC8216 (reported by Julien Elie).
o Swapped parameters of HMAC() function in Section 5 and Section 7
too (reported by Julien Elie).
B.3. Changes since -06
o Changed paragraph about key size in Section 7.
o Added RFC4086 as normative reference. Changed wording from
"random" to "cryptographically random" with reference to RFC4086"
in Section 4 (suggested by Eric Rescorla).
o Swapped parameters of HMAC() function in Section 4 for consistency
with other RFCs (suggested by Eric Rescorla).
o Moved general description from Section 3 to Section 1 (suggested
by Eric Rescorla).
o Changed wording in Section 3 (suggested by Eric Rescorla).
o Replaced the word "required" with "requested" in Section 1
(reported by Warren Kumari).
o Syntax definition modified in Section 2 because of erratum 5116 in
RFC5536 (reported by Paul Kyzivat, using words suggested by Alexey
Melnikov).
o Fixed spelling in different sections (reported by Julien Elie).
o Added text why agents must use different K values if they add
multiple <c-lock> elements to Section 7.
o Modified text for unique K in Section 4 to make it clear that the
requirement targets single agents that add multiple <c-lock>
elements (suggested by Julien Elie).
o Moved text for unique K from Section 2.1 to Section 3.1 and
Section 3.2 to make it clear that the requirement targets single
agents that add multiple <c-lock> elements (suggested by Julien
Elie).
Baeuerle Expires June 7, 2018 [Page 21]
Internet-Draft Cancel-Locks December 2017
B.4. Changes since -05
o Modified text in Section 3.1 and Section 3.2 to make it clear that
an injecting agent only must be able to authenticate the poster if
it wants to act representative for him.
o Added/moved general description text to Section 3 to make things
easier to understand (suggested by GEN-Art Last Call review).
o Removed text for importance of second preimage resistance in
Section 7 (suggested by Secdir review).
o Added note that local secret must be random in Section 4
(suggested by Secdir review).
o Added note that <uid> is not allowed to contain angle brackets in
Section 4 (suggested by Secdir review).
o Changed copyright notice (because Simon Lyall has licensed his
work to the IETF Trust in the meantime).
o Fixed spelling in Section 3.3, Section 3.4, Section 7 and
Section 8.1 (reported by Julien Elie).
o Changed proposed location of IANA registry in Section 8. Should
be more consistent with existing registries now (suggested by
Julien Elie).
o Added note to not use the same secret if multiple <c-lock>
elements are added in Section 2.1 and Section 4 (suggested by
Secdir review).
o Unified the term "cancel control article".
o Added notes for impersonation and content forging attacks in
Section 7.
o Description text modified in Section 1.
B.5. Changes since -04
o Added note that the IESG is the owner of all Netnews Cancel-Lock
hash algorithms that are on the IETF Standards Track in
Section 8.1.
o Changed the algorithm from informative to RECOMMENDED in
Section 4.
Baeuerle Expires June 7, 2018 [Page 22]
Internet-Draft Cancel-Locks December 2017
o Replaced "code-string" with "c-lock-string" for Step 2 in
Section 3.5.
o Replaced "code-string" with "c-key-string" for Step 1 in
Section 3.5.
o Added a short explanation in Section 3.3.
o Added a short explanation in Section 3.1.
o Replaced link to RFC2045 with link to RFC4648 in Section 2.
o Replaced normative reference RFC2045 (for Base64 algorithm) with
RFC4648.
o Added case insensitivity note in Section 5.3.
o RFC6234 (listed in the downref registry) is now a normative
reference (formerly informative) as recommended by Shepherd Write-
Up.
o NIST SHS standard is now an informative reference (formerly
normative) as recommended by Shepherd Write-Up.
o Added "sha224" and "sha384" schemes in Section 8.3 (because
implementations exists that supports them).
o Refer to Section 8.3 instead of Section 8.1 for hash algorithm
registry.
o Fixed some typos.
o Fixed line length in Section 5.1.
B.6. Changes since -03
o Added note for change interval of <sec> in Section 7.
o Changed wording in Section 7.
o Splitted Section 5 into multiple subsections.
o Added example with UID in Section 5.
o Changed "SHOULD NOT" to uppercase in Section 6.
o Reformatted Section 8, Section 8.1 and Section 8.3.
Baeuerle Expires June 7, 2018 [Page 23]
Internet-Draft Cancel-Locks December 2017
o Fixed spelling in Section 4.
B.7. Changes since -02
o Added Section 8.2.
o Added note about algorithm names in Section 8.1.
o Added "/" to scheme-char in Section 2.
o Removed case sensitivity of scheme and normative reference to
RFC7405 in Section 2 again.
o Added "sha512" scheme in Section 2.
o Changed wording in Section 8.3.
o Fixed typo "canceling" in Section 5.
o Changed calculation formulas to use "Base64" in Section 2.1 and
Section 2.2.
o Added obsolete algorithm "md5" in Section 8.3.
o Added note that posting agents should add the Message-ID header
field to proto-articles and use its content for <mid> in
Section 4.
o Added <uid> part to key calculation in Section 4.
o Added note to generate CFWS without comments in Section 2.1 and
Section 2.2.
o Changed ABNF to allow CFWS at the beginning of header fields in
Section 2.1 and Section 2.2.
o Changed wording for "header"/"header field"/"header field body".
o Added Section 3.4.
o Changed wording in Section 3.1.
o Allowed additional whitespace at the beginning of header fields in
Section 2.1 and Section 2.2.
o Changed definition of "c-key-string" in Section 2.2.
o Added "obs-c-key-string" to Section 6.
Baeuerle Expires June 7, 2018 [Page 24]
Internet-Draft Cancel-Locks December 2017
o Fixed typo in Section 2.2 ("c-lock" replaced by "c-key").
o Added key length recommendation in Section 7.
o Renamed "sha-256" scheme to "sha256".
o Modified header and abstract section to list RFC5537 as updated by
this document again.
o Added "USEFOR-CANCEL-LOCK" as informative reference.
o Changed wording in Section 4.
B.8. Changes since -01
o Changed wording in Section 7.
o Added example for HMAC calculation in Section 5.
o Changed wording in Section 4.
o Added use cases to Section 3.2.
o Replaced wording "injecting-agent" by "injecting agent".
o Added Definition for "LOWER" in Section 2.
o Added Section 8.3.
o Added Section 8.1.
o Added new entries for header field registry in Section 8.
o Removed recommendation that moderators and injecting agents should
add only one Cancel-Lock or Cancel-Key resprectively to the list
in Section 3.1, Section 3.2 and Section 3.3.
o Added missing headerfield termination to Section 2.1 and
Section 2.2.
o Removed definition for "code-string" from Section 2. Added
stricter definition "c-lock-string" to Section 2.1. Added
backward compatible definition "c-key-string" to Section 2.2.
o Use different wording in Section 2.2.
o Changed wording to reflect that an injecting agent is allowed to
create Cancel-Lock headerfields in Section 2.1.
Baeuerle Expires June 7, 2018 [Page 25]
Internet-Draft Cancel-Locks December 2017
o Fixed wording and typo in Section 2.
o Added normative reference to RFC7405 because case-sensitivity is
used in ABNF.
o Added reference to RFC5536 (Section 2.2) in Section 2.
o Added references to RFC4880 and RFC5537 in Section 1.
o Replaced the wordings "remove" by "cancel" and "replace" by
"supersede".
o Modified header and abstract section to no longer list RFC5536 and
RFC5537 as updated by this document.
B.9. Changes since -00
o Added additional note that deprecated "scheme" values should be
preserved for backward compatibility as long as reasonable.
o Removed deprectated scheme "md5" (not in use anymore).
o Added descriptions how to generate "code-string" to Section 2.1
and Section 2.2.
o Removed length limitiation in ABNF of "scheme".
o Changed copyright notice to use text from TLP section 6.c.iii.
o Removed references from "abstract" section.
o Changed "SHOULD NOT" to uppercase in Section 6.
o Added line wraps to CLI commands in Section 5.
B.10. Changes since draft-ietf-usefor-cancel-lock-01
o Renamed document because the USEFOR IETF WG is now closed.
o Added more details how to check Cancel-Key header fields in
Section 3.5.
o Added more details to Section 7.
o Added updated ABNF for Cancel-Lock and Cancel-Key header fields.
o Deprecated "md5" and "sha1" schemes.
Baeuerle Expires June 7, 2018 [Page 26]
Internet-Draft Cancel-Locks December 2017
o Added "sha-256" scheme.
o Reworded the abstract section and added references.
o Added note to other authentication systems to Section 1.
o Added command line check examples to Section 5.
B.11. Changes since draft-ietf-usefor-cancel-lock-00
o References to SHA-160 changed to SHA1
o "scheme" is now a case insensitive token and the number "1" has
been changed to "sha1".
o Added some examples and fixed the section numbering.
o Updated 2nd paragraph on section 2.2 to make clear what exactly is
being hashed and how.
o Changed paragraph 2 of 3.1 to discourage injection agents from
adding the header.
o Removed the Clue-string as this complicated the scheme without
adding realistic functionality
o Moderators can now add these headers under the same conditions as
injection agents.
Author's Address
Michael Baeuerle
STZ Elektronik
Hofener Weg 33C
Remseck, Baden-Wuerttemberg 71686
Germany
Fax: +49 7146 999061
EMail: michael.baeuerle@stz-e.de
Baeuerle Expires June 7, 2018 [Page 27]
