Skip to main content

Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols
draft-ietf-msec-tesla-for-alc-norm-10

Revision differences

Document history

Date Rev. By Action
2012-08-22
10 (System) post-migration administrative database adjustment to the No Objection position for Alexey Melnikov
2012-08-22
10 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2009-11-23
10 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2009-11-23
10 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2009-11-23
10 (System) IANA Action state changed to In Progress from Waiting on Authors
2009-11-11
10 (System) IANA Action state changed to Waiting on Authors from In Progress
2009-11-09
10 Cindy Morgan State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan
2009-11-09
10 (System) IANA Action state changed to In Progress
2009-11-07
10 Cindy Morgan IESG state changed to Approved-announcement sent
2009-11-07
10 Cindy Morgan IESG has approved the document
2009-11-07
10 Cindy Morgan Closed "Approve" ballot
2009-10-27
10 Alexey Melnikov [Ballot Position Update] Position for Alexey Melnikov has been changed to No Objection from Discuss by Alexey Melnikov
2009-10-26
10 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2009-10-26
10 (System) New version available: draft-ietf-msec-tesla-for-alc-norm-10.txt
2009-10-26
10 (System) Sub state has been changed to AD Follow up from New Id Needed
2009-10-26
09 (System) New version available: draft-ietf-msec-tesla-for-alc-norm-09.txt
2009-10-09
10 (System) Removed from agenda for telechat - 2009-10-08
2009-10-08
10 Cindy Morgan State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan
2009-10-08
10 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2009-10-08
10 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2009-10-07
10 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2009-10-07
10 Alexey Melnikov
[Ballot discuss]
I believe the following reference must be normative:

  [RFC1305]  Mills, D., "Network Time Protocol (Version 3)
        …
[Ballot discuss]
I believe the following reference must be normative:

  [RFC1305]  Mills, D., "Network Time Protocol (Version 3)
              Specification, Implementation", RFC 1305, March 1992.

as this document describes NTP timestamp format used in various places in the document.
2009-10-07
10 Alexey Melnikov [Ballot Position Update] New position, Discuss, has been recorded by Alexey Melnikov
2009-10-06
10 Russ Housley
[Ballot discuss]
The Gen-ART Review by Pete McCann raised some points for discussion.
  However the discussion has not taken place.  Suggestions are made,
  …
[Ballot discuss]
The Gen-ART Review by Pete McCann raised some points for discussion.
  However the discussion has not taken place.  Suggestions are made,
  and without the discussion it is impossible to tell if these are
  good suggestions or not.

  > I'd suggest a more prominent reference to RFC 4082, especially to
  > section 3.1 that describes the basic idea behind TESLA.  You do have
  > a reference just before Section 1.1, but perhaps you could add some
  > explanatory text here to make it clear that the an overview of the
  > use of hash chains to efficiently authenticate a long stream of
  > packets is described in RFC 4082.

  > Section 2.4.2.2 says:
  >
  >    The sender and receivers use the direct
  >    time synchronization scheme to synchronize with the various time
  >    references.
  >
  > Should this say "indirect time synchronization scheme"?
2009-10-06
10 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley
2009-10-03
10 Samuel Weiler Request for Telechat review by SECDIR is assigned to Yaron Sheffer
2009-10-03
10 Samuel Weiler Request for Telechat review by SECDIR is assigned to Yaron Sheffer
2009-09-30
10 Tim Polk [Ballot Position Update] New position, Yes, has been recorded for Tim Polk
2009-09-30
10 Tim Polk Ballot has been issued by Tim Polk
2009-09-30
10 Tim Polk Created "Approve" ballot
2009-09-30
10 Tim Polk State Changes to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup by Tim Polk
2009-09-30
10 Tim Polk Placed on agenda for telechat - 2009-10-08 by Tim Polk
2009-09-09
10 (System) Sub state has been changed to AD Follow up from New Id Needed
2009-09-09
08 (System) New version available: draft-ietf-msec-tesla-for-alc-norm-08.txt
2009-08-03
10 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Yaron Sheffer.
2009-07-28
10 Tim Polk State Changes to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead by Tim Polk
2009-07-28
10 Tim Polk Need to respond to issues in gen-art and secdir reviews
2009-07-23
10 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2009-07-21
10 Amanda Baber
IANA questions/comments:

Upon approval of this document, IANA will make the following
changes in the "Timed Efficient Stream Loss-tolerant Authentication
(TESLA) Parameters" registry located at …
IANA questions/comments:

Upon approval of this document, IANA will make the following
changes in the "Timed Efficient Stream Loss-tolerant Authentication
(TESLA) Parameters" registry located at
http://www.iana.org/assignments/tesla-parameters/

========================================
========================================
In the sub-registry "TESLA-PRF Values"

OLD:

Value PRF Function Reference
-------- ----------------------- ---------
0 HMAC-SHA1 [RFC4442]
1-240 Unassigned
241-255 Private Use


NEW:

Value PRF Function Reference
-------- ----------------------- ---------
0 HMAC-SHA1 [RFC4442]
1 HMAC-SHA-224 [RFC-msec-tesla-for-alc-norm-07]
2 HMAC-SHA-256 (default) [RFC-msec-tesla-for-alc-norm-07]
3 HMAC-SHA-384 [RFC-msec-tesla-for-alc-norm-07]
4 HMAC-SHA-512 [RFC-msec-tesla-for-alc-norm-07]
5-240 Unassigned
241-255 Private Use

========================================
========================================
In the sub-registry "TESLA-MAC Values"

OLD:

Value PRF Function Reference
-------- ----------------------- ---------
0 HMAC-SHA1 [RFC4442]
1-240 Unassigned
241-255 Private Use


NEW:

Value PRF Function Reference
-------- ----------------------- ---------
0 HMAC-SHA1 [RFC4442]
1 HMAC-SHA-224 [RFC-msec-tesla-for-alc-norm-07]
2 HMAC-SHA-256 (default) [RFC-msec-tesla-for-alc-norm-07]
3 HMAC-SHA-384 [RFC-msec-tesla-for-alc-norm-07]
4 HMAC-SHA-512 [RFC-msec-tesla-for-alc-norm-07]
5-240 Unassigned
241-255 Private Use

========================================
========================================
IANA will create the following sub-registry:

Registry Name: TESLA-SIG-ALGO Values
Reference: [RFC-msec-tesla-for-alc-norm-07]
Registration Procedures: XXXX

Value range = 8bits unsigned

Registry:
Value Signature Algorithm Name Reference
-------- --------------------------- ---------
0 INVALID [RFC-msec-tesla-for-alc-norm-07]
1 RSASSA-PKCS1-v1_5 (default) [RFC-msec-tesla-for-alc-norm-07]
2 RSASSA-PSS [RFC-msec-tesla-for-alc-norm-07]
3-255 Unassigned

QUESTION: No registration procedure was defined. Please provide.
QUESTION: No upper limit of the value was defined. From field length, it
appears to be 8 bits. Please confirm.


========================================
========================================
IANA will create the following sub-registry:

Registry Name: TESLA-SIG-CRYPTO-FUNC Values
Reference: [RFC-msec-tesla-for-alc-norm-07]
Registration Procedures: XXXX

Value range = 8bits unsigned

Registry:
Value Cryptographic Function Name Reference
-------- --------------------------- ---------
0 INVALID [RFC-msec-tesla-for-alc-norm-07]
1 SHA-1 [RFC-msec-tesla-for-alc-norm-07]
2 SHA-224 [RFC-msec-tesla-for-alc-norm-07]
3 SHA-256 (default) [RFC-msec-tesla-for-alc-norm-07]
4 SHA-384 [RFC-msec-tesla-for-alc-norm-07]
5 SHA-512 [RFC-msec-tesla-for-alc-norm-07]
6-255 Unassigned

QUESTION: No registration procedure was defined. Please provide.
QUESTION: No upper limit of the value was defined. From field length, it
appears to be 8 bits. Please confirm.

========================================
========================================
QUESTION: in section 5.1, this document defines the values for the Type
field. Should those values be registered in a registry? However, the
Type field is used as part of the EXT_AUTH which is yet to be registered
by IANA as part of the draft-ietf-rmt-bb-lct-revised- normative
reference, which has not yet completed IESG evaluation.
2009-07-18
10 Samuel Weiler Request for Last Call review by SECDIR is assigned to Yaron Sheffer
2009-07-18
10 Samuel Weiler Request for Last Call review by SECDIR is assigned to Yaron Sheffer
2009-07-09
10 Cindy Morgan Last call sent
2009-07-09
10 Cindy Morgan State Changes to In Last Call from Last Call Requested by Cindy Morgan
2009-07-09
10 Tim Polk Last Call was requested by Tim Polk
2009-07-09
10 Tim Polk State Changes to Last Call Requested from AD Evaluation by Tim Polk
2009-07-09
10 (System) Ballot writeup text was added
2009-07-09
10 (System) Last call text was added
2009-07-09
10 (System) Ballot approval text was added
2009-06-11
10 Tim Polk State Changes to AD Evaluation from Publication Requested by Tim Polk
2009-05-13
10 Cindy Morgan
Intended Status: Experimental

Answers to Document Shepherd Write-Up questions (Questions listed in
the end):
1.a - Brian Weis is the document Shepherd. He has personally …
Intended Status: Experimental

Answers to Document Shepherd Write-Up questions (Questions listed in
the end):
1.a - Brian Weis is the document Shepherd. He has personally reviewed
the document and asserts that it is ready for IESG publication.
1.b - The document has been reviewed by key WG members and has passed
WG LC. There are no concerns about depth or breadth of the reviews.
1.c - There is no need for wider review.
1.d - There are no specific concerns of which the AD and/or IESG
should be aware.
1.e - The WG consensus is solid.
1.f - There has been no threat of appeal.
1.g - The document satisfies all ID nits with a few minor warnings.
The document Shepherd believes that the license boilerplate was
current at the time it was submitted (although idnits complains about
it now).
1.h - The document splits its references and all normative references
are complete and approved documents. Three normative references are
IETF I-Ds; however two of them have completed IETF LC: draft-ietf-rmt-
bb-lct-revised and draft-ietf-rmt-pi-norm-revised. As far as I can
tell, neither has significant issues. One I-D (draft-ietf-rmt-pi-alc-
revised ) appears to be heading into IETF LC. The WG chair (Brian
Adamson) indicated to me in email that he believes it will go forward
soon.
1.i - The IANA Considerations section is consistent with the body of
the document. The document adds values to two existing registries.
Two new registries are introduced. The new registry definitions should
describe the rules for adding to the registry, but this minor issue
can be corrected during the IETF last call process.
1.j - No sections of the document are written in a formal language.

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.
2009-05-13
10 Cindy Morgan Draft Added by Cindy Morgan in state Publication Requested
2008-12-17
07 (System) New version available: draft-ietf-msec-tesla-for-alc-norm-07.txt
2008-10-22
06 (System) New version available: draft-ietf-msec-tesla-for-alc-norm-06.txt
2008-07-30
05 (System) New version available: draft-ietf-msec-tesla-for-alc-norm-05.txt
2008-02-18
04 (System) New version available: draft-ietf-msec-tesla-for-alc-norm-04.txt
2007-11-19
03 (System) New version available: draft-ietf-msec-tesla-for-alc-norm-03.txt
2007-07-05
02 (System) New version available: draft-ietf-msec-tesla-for-alc-norm-02.txt
2007-03-02
01 (System) New version available: draft-ietf-msec-tesla-for-alc-norm-01.txt
2006-06-19
00 (System) New version available: draft-ietf-msec-tesla-for-alc-norm-00.txt