USEFOR Working Group                                            S. Lyall
INTERNET-DRAFT                                               August 1998
                                                   Expires February 1999

                     Cancel-Locks in Usenet articles.

Status of this memo

     This document is an Internet-Draft.  Internet-Drafts are working
     documents of the Internet Engineering Task Force (IETF), its areas,
     and its working groups.  Note that other groups may also distribute
     working documents as Internet-Drafts.

     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

     To view the entire list of current Internet-Drafts, please check
     the "1id-abstracts.txt" listing contained in the Internet-Drafts
     Shadow Directories on (Africa),
     (Northern Europe), (Southern Europe),
     (Pacific Rim), (US East Coast), or
     (US West Coast).


This document outlines a method that may be used by authors of successor
(or canceling) articles to authenticate their authorship of the original

As a pre-injected article passes through various agents they may include
the hash of a secret string in a Cancel-Key header. Later if they wish to
use a standard mechanism to remove the original article (eg Cancel or
Supersede) they can include this string in the Cancel-Lock header to
verify that they are entitled to perform this operation.

Familiarity with the current News Article Format draft [ARTICLE] is

1. Introduction: The Cancel-Key & Cancel-Lock headers

These two headers MAY be used by posters, posting agents, moderators and
injecting agents in order to mark articles they process and to verify
canceling , superseding and replacing articles they may subsequently be
issued for those originals. They MUST NOT be altered or created by any
other agents.

The scheme works by included a "Cancel-Lock: " header and contents in an
article. Further articles that wish to cancel, supersede or replace this
article are required to include a "Cancel-Key: " header which contains
a code-string that when hashed yields one of the code-strings in the
"Cancel-Lock: " header of the original article.

These headers are intended to be used as a simple method to verify that
the author of a article which removes another one is either the poster,
posting agent, moderator or injecting agent that processed the original
article when it was in its proto-article form.

2. Format

     Cancel-Lock-content = [CFWS] cancel-lock *( CFWS cancel-lock ) [CFWS]
      Cancel-Key-content = [CFWS] cancel-key *( CFWS cancel-key ) [CFWS]
             cancel-lock = scheme ":" code-string
              cancel-key = scheme ":" code-string [ ":" clue-string ]
                  scheme = 1*DIGIT
             code-string = 1*base64-octet
             clue-string = 2base64-octet
            base64-octet = ALPHA / DIGIT / "+" / "/" / "="

2.1 The "scheme" element

The scheme is the format that is used to encode the code-string. This
document only defines the scheme of "1" which corresponds to the
SHA algorithm [SHA-160]. Other schemes MAY be defined by further IETF

2.2 The "code-string" element

The code-string is a series of base-64-octets. The code-string in a
cancel-lock is the hash of the corresponding code-string in a cancel-key.
The encoding of the binary key or lock is performed in accordance with the
Base64 Transfer Encoding defined in [RFC-2045].

Under Scheme 1 the code-string element of a cancel-lock is the output hash
of the SHA algorithm.

2.3 The "clue-string" element

The clue-string is an optional element that MAY be included in a
cancel-key. It consists of the first two base64-octets of the code-string
of the cancel-lock to which the cancel-key corresponds.

The clue-string is intended the reduce searching time where multiple
cancel-lock's may be referred to by a single cancel-key.

3. Use

When an serving agent receives an article that attempts to remove a
previous article via Cancel, Supersedes or Replaces, then if the original
article contains a valid cancel-lock the replacing article MUST contain a
valid cancel-key (or keys) that corresponds to one (or more) of the
cancel-lock's in the original article.

3.1 Adding an initial "Cancel-Lock: " header to a proto-article

A Cancel-Lock header MAY be added to a proto-article by the poster
or posting agent which will include one or more cancel-locks in its

If the poster or posting agent does not add a Cancel-Lock header to an
article then an injecting-agent MAY add one provided that it
positively authenticates the author. However this practice is NOT
recommended since the poster will be unable to create a cancel-key to
remove the article later without the co-operation of the injecting agent.

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

3.2 Extending the "Cancel-Lock: " header of a proto-article

If a "Cancel-Lock: " header has already been added to a proto-article then
any agent (prior to the article being injected) further processing the
proto-article MAY append a single cancel-lock to those already in the

No more than one cancel-lock SHOULD be added by each agent that
processes the proto-article.

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

3.3 Adding a "Cancel-Key: " header to a proto-article.

The Cancel-Key header MAY be added to a proto-article containing a
"Cancel: ", "Replaces: " or "Supersedes: " header by the poster
or posting agent which will include one or more cancel-keys in its
Cancel-Key-content. These cancel-keys will correspond to some or all of
the   cancel-locks in articles listed in the "Cancel: " , "Replaces: "
and "Supersedes: " headers.

If, as mentioned in 3.1 an injecting agent has added a "Cancel-Lock: "
header to an article listed in the "Cancel: " , "Replaces: " or
"Supersedes: " headers then (assuming it authenticates the poster as being
the same as the poster or the original article(s) ) it MUST add a
"Cancel-Key: " header with the cancel-key(s) that correspond to those

Other Agents MUST NOT alter this header.

4. Creating the cancel-lock

It is suggested that when creating a cancel-lock the function
HMAC(message-id+secret) be used, where HMAC is outlined in [HMAC],
message-id is the message-id of the article and secret is a secret key
held locally.

This method removes the need for a per-article database containing the
cancel-lock used with every article..

5. Security Issues

General security issues with hash functions are discussed elsewhere, see the
references in [HMAC] for some pointers. The method outlined in Section 4
is also vulnerable to the secret key being compromised or guessed.

5. References

[ARTICLE] News Article Format. D Ritter. Internet Draft
     draft-ietf-usefor-article-01 . 1998.

[HMAC]  Keyed-Hashing for Message Authentication. H. Krawczyk, M.
     Bellare, R. Canetti. February 1997. RFC 2104.

[SHA-160]  NIST, FIPS PUB 180-1: Secure Hash Standard, Apr 1995.

[RFC-2045] MIME, part 1  Freed, Ned; Borenstein, Nathaniel S.:
     Multipurpose Internet mail extensions (MIME), part 1: format of
     Internet message bodies. RFC 2045, Nov 1996.

6. Author's Address

Simon Lyall,
PO Box 6616,
New Zealand.

Phone: +64 9 358 5067 ext 701