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) … |
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 |