Document Action: 'Use of TESLA in the ALC and NORM Protocols' to Experimental RFC

The IESG <> Sun, 08 November 2009 04:40 UTC

Return-Path: <>
Received: by (Postfix, from userid 30) id 96FB53A68FA; Sat, 7 Nov 2009 20:40:53 -0800 (PST)
X-idtracker: yes
From: The IESG <>
To: IETF-Announce <>
Subject: Document Action: 'Use of TESLA in the ALC and NORM Protocols' to Experimental RFC
Message-Id: <>
Date: Sat, 07 Nov 2009 20:40:53 -0800
Cc: msec mailing list <>, msec chair <>, Internet Architecture Board <>, RFC Editor <>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IETF announcement list. No discussions." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 08 Nov 2009 04:40:53 -0000

The IESG has approved the following document:

- 'Use of TESLA in the ALC and NORM Protocols '
   <draft-ietf-msec-tesla-for-alc-norm-10.txt> as an Experimental RFC

This document is the product of the Multicast Security Working Group. 

The IESG contact persons are Tim Polk and Pasi Eronen.

A URL of this Internet-Draft is:

Technical Summary

This document describes how to use the TESLA Multicast Source
Authentication Transform (RFC 4082) in a packet source authentication and
packet integrity verification protocol within the ALC and NORM content
delivery protocols. In other words, the TESLA method allows ALC and NORM
receivers to verify that the sender identified as sending the ALC or NORM
packet actually originated the packet. TELSA is a well-known algorithm for
integrity protecting single-source multicast packet streams.

Working Group Summary

This I-D was discussed on the MSEC WG mailing list, in particular during
the WG last call period. Comments were received, and two additional
versions of the I-D were generated by the authors. The WG had no further
comments on the document.

Document Quality

The TESLA portions of the document was reviewed in detail by an
implementor of TESLA, and his comments are adequately addressed. It was
also reviewed in detail by a security protocol implementer, who felt it
was implementable.


Brian Weis is the Document Shepherd; Tim Polk is the Responsible Area