USEFOR Working Group                                             S. Lyall
INTERNET-DRAFT                                              November 1998
                                                         Expires May 1999


                     Cancel-Locks in Usenet articles.
                   draft-ietf-usefor-cancel-lock-01.txt


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
     progress."

     To view the entire list of current Internet-Drafts, please check
     the "1id-abstracts.txt" listing contained in the Internet-Drafts
     Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
     (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
     (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
     (US West Coast).


Abstract

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

As a proto-article 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
assumed.


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 that may subsequently be
issued for those originals. They MUST NOT be altered or created by any
other agents.

The scheme works by including a "Cancel-Lock: " header and contents in an
article. Further articles that wish to cancel, supersede or replace this
article can 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 an 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 = cancel-lock *( CFWS cancel-lock ) [CFWS]
    Cancel-Key-content = cancel-key *( CFWS cancel-key ) [CFWS]
           cancel-lock = scheme ":" code-string
            cancel-key = scheme ":" code-string
                scheme = token
           code-string = 1*base64-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 "SHA1" which corresponds to the
SHA1 algorithm [SHA1]. Other schemes MAY be defined by further IETF
standards. This element is case insensitive.


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 "sha1" the code-string element of a cancel-lock is the
output of a hash operation (using the SHA1 algorithm) performed on the
code-string of the cancel-key.


3. Use

In order for an article removal to be allowed under the Cancel-Lock method
the following takes place:

When a 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 at least one 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
Cancel-Lock-content.

If the poster or posting agent does not add a Cancel-Lock header to an
article then an injecting-agent (or moderator) MAY add one provided that
it positively authenticates the author. The injecting-agent (or
moderator) MUST NOT add this header to an article unless it is able to
authenticate all cancels, replaces and supersedes from the poster and
automatically add the correct Cancel-Key header (and content) for such
articles.

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 (ie moderators and injection-agents) MAY append a single
cancel-lock to those already in the header.

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

Once an article is 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 (or moderator) 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 of the original article(s) ) it MUST add a
"Cancel-Key: " header with the cancel-key(s) that correspond to those
article(s).

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.


6. Examples

The following are Cancel-Lock headers along with a Cancel-Key header
that matches them:

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

Cancel-Lock: SHA1:H7/zsCUemvbvSDyARDaMs6AQu5s=
Cancel-Key: sha1:chW8hNeDx3iNUsGBU6/ezDk88P4=  sha1:4srkWaRIzvK51ArAP

Cancel-Lock: sha1:JyEBL4w9/abCBuzCxMIE/E73GM4=
       sha1:2Bmg+zWaY1noRiCdy8k3IapwSDU=
Cancel-Key: sha1:K4rkWRjRcXmIzvK51ArAP



7. 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.

[SHA1]  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.


8. Changes from previous draft.


- References to SHA-160 changed to SHA1

- "scheme" is now a case insensitive token and the number "1" has been
  changed to "sha1".

- Added some examples and fixed the section numbering.

- Updated 2nd paragraph on section 2.2 to make clear what exactly is
  being hashed and how.

- Changed paragraph 2 of 3.1 to discourage injection-agents from adding
  the header.

- Removed the Clue-string as this complicated the scheme without adding
  realistic functionality

- moderators can now add these headers under the same conditions as
  injection-agents.


9. Author's Address

Simon Lyall
PO Box 6616,
Auckland,
New Zealand.

Phone: +64 9 358 5067 ext 701
Email:  simon@darkmere.gen.nz