USEFOR Working Group                                            S. Lyall
INTERNET-DRAFT                                            September 1998
                                                      Expires March 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 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*base64-octet
           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 "SHA1" which corresponds to the
SHA1 algorithm [SHA1]. Other schemes MAY be defined by further IETF
standards.


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.


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 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 MAY add one provided that it positively 
authenticates the author. The injecting-agent 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 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 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
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:Hc

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



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. Author's Address

Simon Lyall
PO Box 6616,
Auckland,
New Zealand.

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





-- 
Simon J. Lyall.  |   Very  Busy  |   Mail: simon@darkmere.gen.nz
"To stay awake all night adds a day to your life" - Stilgar | MT.

