OSPFv2 HMAC-SHA Cryptographic Authentication
RFC 5709
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2015-10-14
|
07 | (System) | Notify list changed from ospf-chairs@ietf.org, draft-ietf-ospf-hmac-sha@ietf.org to (None) |
|
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the No Objection position for Cullen Jennings |
|
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the No Objection position for Alexey Melnikov |
|
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
|
2009-10-23
|
07 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
|
2009-10-23
|
07 | Amy Vezza | [Note]: 'RFC 5709' added by Amy Vezza |
|
2009-10-22
|
07 | (System) | RFC published |
|
2009-09-08
|
07 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
|
2009-09-04
|
07 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
|
2009-09-04
|
07 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
|
2009-09-04
|
07 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
|
2009-09-04
|
07 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
|
2009-09-04
|
07 | (System) | IANA Action state changed to In Progress |
|
2009-09-04
|
07 | Amy Vezza | IESG state changed to Approved-announcement sent |
|
2009-09-04
|
07 | Amy Vezza | IESG has approved the document |
|
2009-09-04
|
07 | Amy Vezza | Closed "Approve" ballot |
|
2009-09-04
|
07 | Ross Callon | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Ross Callon |
|
2009-09-04
|
07 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley |
|
2009-09-03
|
07 | Alexey Melnikov | [Ballot Position Update] Position for Alexey Melnikov has been changed to No Objection from Discuss by Alexey Melnikov |
|
2009-09-03
|
07 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2009-09-03
|
07 | (System) | New version available: draft-ietf-ospf-hmac-sha-07.txt |
|
2009-08-28
|
07 | (System) | Removed from agenda for telechat - 2009-08-27 |
|
2009-08-27
|
07 | Samuel Weiler | Request for Telechat review by SECDIR Completed. Reviewer: Hilarie Orman. |
|
2009-08-27
|
07 | Alexey Melnikov | [Ballot comment] 3. Cryptographic authentication with NIST SHS in HMAC mode The algorithms used to generate and verify the message digest are specified … [Ballot comment] 3. Cryptographic authentication with NIST SHS in HMAC mode The algorithms used to generate and verify the message digest are specified implicitly by the secret key. And the secret key is identified by the KeyID. Maybe you should say that here. 3.2 OSPFv2 Security Association Authentication Algorithm This indicates the authentication algorithm to be used. THis information should never be sent over the wire in cleartext form. While this is true, I think this is a bit misleading: this information is never sent over the wire (in OSPF itself). I suggest changing the last quoted sentence to make this clear, for example: This information is never sent over the wire. |
|
2009-08-27
|
07 | Alexey Melnikov | [Ballot discuss] >5. IANA CONSIDERATIONS > > There are no IANA considerations for this document. I don't think this is correct. The IANA considerations section … [Ballot discuss] >5. IANA CONSIDERATIONS > > There are no IANA considerations for this document. I don't think this is correct. The IANA considerations section should say that the definition of "Cryptographic authentication" authentication method in the "Open Shortest Path First (OSPF) Authentication Codes" registry (<http://www.iana.org/assignments/ospf-authentication-codes>) should be updated to also point to this document. Suggested RFC Editor note: Change section 5 to read: OLD: There are no IANA considerations for this document. NEW: This document requests IANA to add reference to this RFC as the second reference for the "Cryptographic authentication" (code 2) entry in the "Open Shortest Path First (OSPF) Authentication Codes" IANA registry. |
|
2009-08-27
|
07 | Cindy Morgan | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan |
|
2009-08-27
|
07 | Cullen Jennings | [Ballot Position Update] Position for Cullen Jennings has been changed to No Objection from Discuss by Cullen Jennings |
|
2009-08-27
|
07 | Cullen Jennings | [Ballot discuss] On the call, I would like to talk about the number of authors on this. At the end of the the iesg-secretary can … [Ballot discuss] On the call, I would like to talk about the number of authors on this. At the end of the the iesg-secretary can change my position to no-obj. |
|
2009-08-27
|
07 | Cullen Jennings | [Ballot Position Update] Position for Cullen Jennings has been changed to Discuss from No Objection by Cullen Jennings |
|
2009-08-27
|
07 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
|
2009-08-27
|
07 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
|
2009-08-27
|
07 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault |
|
2009-08-27
|
07 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded by Jari Arkko |
|
2009-08-27
|
07 | Pasi Eronen | [Ballot comment] I agree with Tim that SHA-224 is of questionable value here (and so is SHA-384, IMHO -- it's just a truncated version of … [Ballot comment] I agree with Tim that SHA-224 is of questionable value here (and so is SHA-384, IMHO -- it's just a truncated version of SHA-512). |
|
2009-08-27
|
07 | Pasi Eronen | [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen |
|
2009-08-26
|
07 | Alexey Melnikov | [Ballot comment] 3. Cryptographic authentication with NIST SHS in HMAC mode The algorithms used to generate and verify the message digest are specified … [Ballot comment] 3. Cryptographic authentication with NIST SHS in HMAC mode The algorithms used to generate and verify the message digest are specified implicitly by the secret key. And the secret key is identified by the KeyID. Maybe you should say that here. 3.2 OSPFv2 Security Association Authentication Algorithm This indicates the authentication algorithm to be used. THis information should never be sent over the wire in cleartext form. While this is true, I think this is a bit misleading: this information is never sent over the wire (in OSPF itself). Or am I wrong about that? Currently valid values are: MD5, SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512. I was expecting to see an IANA registry for this, but found that each mechanism is identified by the hash length field ("Auth Data Len"). Did the WG discussed alternatives, for example by defining a new "Authentication Method" code(s)? |
|
2009-08-26
|
07 | Alexey Melnikov | [Ballot discuss] >5. IANA CONSIDERATIONS > > There are no IANA considerations for this document. I don't think this is correct. The IANA considerations section … [Ballot discuss] >5. IANA CONSIDERATIONS > > There are no IANA considerations for this document. I don't think this is correct. The IANA considerations section should say that the definition of "Cryptographic authentication" authentication method in the "Open Shortest Path First (OSPF) Authentication Codes" registry (<http://www.iana.org/assignments/ospf-authentication-codes>) should be updated to also point to this document. |
|
2009-08-26
|
07 | Alexey Melnikov | [Ballot Position Update] New position, Discuss, has been recorded by Alexey Melnikov |
|
2009-08-26
|
07 | Russ Housley | [Ballot discuss] Section 3.2 defines Authentication Algorithm and Authentication Mode. I do not think these are separable in the manner described. I would … [Ballot discuss] Section 3.2 defines Authentication Algorithm and Authentication Mode. I do not think these are separable in the manner described. I would be much more comfortable with the use of Authentication Algorithm with the choices of HMAC-SHA-256, HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-384, HMAC-SHA-512, and Keyed-MD5. Please see draft-ietf-saag-crypto-key-table-00.txt. Please consider the other ideas presented in this draft. The document have the following requirements for the various HMAC algorithims: - MUST include support for HMAC-SHA-256 - SHOULD include support for HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-384, and HMAC-SHA-512 - SHOULD also include support for Keyed-MD5 This seems like a lot of SHOULD support algorithms. Perhaps some of them out to be MAY support algorithms. Some guidance to product planners about the mandatory to implement requirements in the future is highly desirable. I assume that support for Keyed-MD5 will be dropped in the future. Is HMAC-SHA-1 also in this same situation? If so, please say so. |
|
2009-08-26
|
07 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks |
|
2009-08-26
|
07 | Tim Polk | [Ballot comment] I believe the SHOULD list in section 3 is too long to have real value. I would suggest retaining HMAC-SHA-256 as MUST, with … [Ballot comment] I believe the SHOULD list in section 3 is too long to have real value. I would suggest retaining HMAC-SHA-256 as MUST, with Keyed-MD5 and HMAC-SHA-1 as SHOULD, and relegate the others to MAY. I also wonder if SHA-224 is worth including at all, given that we would only save 32 bits on the wire. Would operators find this a compelling feature? |
|
2009-08-26
|
07 | Tim Polk | [Ballot Position Update] New position, Yes, has been recorded by Tim Polk |
|
2009-08-26
|
07 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded by Ralph Droms |
|
2009-08-26
|
07 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
|
2009-08-25
|
07 | Adrian Farrel | [Ballot comment] Some nits you should address to improve the polish if you have the document open for edit. --- RFC Editor will ask you … [Ballot comment] Some nits you should address to improve the polish if you have the document open for edit. --- RFC Editor will ask you to reduce the number of names on the front cover in line with the guidelines. --- Section 2 All OSPF protocol exchanges are authenticated. Notwithstanding the exact same statement being present in RFC 2328 it is hard to claim that the Authentication Type "Null Authentication" represents authentication in action. Perhaps s/are/can be/ --- Section 3.2 RFC 2328 defined an OSPFv2 Security Association (OSPFv2 SA) in Section D.3, pages 228 and 229. However, the term is new to this document. Not clear what the second sentence means. --- Section 3.2 There is a fair amount of "should". Does this need to be 2119 language? --- Section 3.2 Authentication Algorithm THis information should never be sent over the wire in cleartext form. s/THis/This/ |
|
2009-08-25
|
07 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded by Adrian Farrel |
|
2009-08-24
|
07 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
|
2009-08-24
|
07 | Russ Housley | [Ballot discuss] Section 3.2 defines Authentication Algorithm and Authentication Mode. I do not think these are separable in the manner described. I would … [Ballot discuss] Section 3.2 defines Authentication Algorithm and Authentication Mode. I do not think these are separable in the manner described. I would be much more comfortable with the use of Authentication Algorithm with the choices of HMAC-SHA-256, HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-384, HMAC-SHA-512, and Keyed-MD5. Please see draft-ietf-saag-crypto-key-table-00.txt. Please consider the other ideas presented in this draft. The document have the following requirements for the various HMAC algorithims: - MUST include support for HMAC-SHA-256 - SHOULD include support for HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-384, and HMAC-SHA-512 - SHOULD also include support for Keyed-MD5 This seems like a lot of SHOULD support algorithms. Perhaps some of them out to be MAY support algorithms. Some guidance to product planners about the mandatory to implement requirements in the future is highly desirable. I assume that support for Keyed-MD5 will be dropped in the future. Is HMAC-SHA-1 also in this same situation? If so, please say so. As pointed out in the Gen-ART Review by David Black, the mention of IP Security in the next to last paragraph of the Security Considerations (section 4) should cite an informative reference, RFC 4301 would be appropriate. |
|
2009-08-24
|
07 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley |
|
2009-08-18
|
07 | Samuel Weiler | Request for Telechat review by SECDIR is assigned to Hilarie Orman |
|
2009-08-18
|
07 | Samuel Weiler | Request for Telechat review by SECDIR is assigned to Hilarie Orman |
|
2009-08-14
|
07 | Ross Callon | Placed on agenda for telechat - 2009-08-27 by Ross Callon |
|
2009-08-14
|
07 | Ross Callon | State Changes to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup by Ross Callon |
|
2009-08-14
|
07 | Ross Callon | [Ballot Position Update] New position, Yes, has been recorded for Ross Callon |
|
2009-08-14
|
07 | Ross Callon | Ballot has been issued by Ross Callon |
|
2009-08-14
|
07 | Ross Callon | Created "Approve" ballot |
|
2009-08-13
|
07 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2009-08-13
|
06 | (System) | New version available: draft-ietf-ospf-hmac-sha-06.txt |
|
2009-07-30
|
07 | Ross Callon | State Changes to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead by Ross Callon |
|
2009-07-22
|
07 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Hilarie Orman. |
|
2009-07-20
|
07 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
|
2009-07-20
|
07 | Amanda Baber | IANA comments: As described in the IANA Considerations section, we understand this document to have NO IANA Actions. |
|
2009-07-09
|
07 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Hilarie Orman |
|
2009-07-09
|
07 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Hilarie Orman |
|
2009-07-06
|
07 | Amy Vezza | Last call sent |
|
2009-07-06
|
07 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
|
2009-07-05
|
07 | Ross Callon | State Changes to Last Call Requested from AD Evaluation::External Party by Ross Callon |
|
2009-07-05
|
07 | Ross Callon | Last Call was requested by Ross Callon |
|
2009-07-05
|
07 | (System) | Ballot writeup text was added |
|
2009-07-05
|
07 | (System) | Last call text was added |
|
2009-07-05
|
07 | (System) | Ballot approval text was added |
|
2009-06-10
|
07 | Ross Callon | State Changes to AD Evaluation::External Party from Publication Requested by Ross Callon |
|
2009-05-29
|
07 | Ross Callon | PROTO writeup by Acee Lindem: OSPFv2 HMAC-SHA Cryptographic Authentication <draft-ietf-ospf-hmac-sha-05.txt … PROTO writeup by Acee Lindem: OSPFv2 HMAC-SHA Cryptographic Authentication <draft-ietf-ospf-hmac-sha-05.txt> 1. Have the chairs personally reviewed this version of the Internet Draft (ID), and in particular, do they believe this ID is ready to forward to the IESG for publication? Yes 2. Has the document had adequate review from both key WG members and key non-WG members? Yes - Both WG members and members of the security community have read it (although that doesn't mean that the SECDIR won't have comments). Do you have any concerns about the depth or breadth of the reviews that have been performed? No 3. Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)? No 4. Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or have concerns whether there really is a need for it. In any event, if your issues have been discussed in the WG and the WG has indicated it that it still wishes to advance the document, detail those concerns in the write-up. No 5. How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There was controversy as to how the HMAC-SHA digest would be computed and the subject draft is the agreed upon solution. 6. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email to the Responsible Area Director. No 7. Have the chairs verified that the document adheres to all of the ID Checklist items? idnits 2.11.11 tmp/draft-ietf-ospf-hmac-sha-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to http://www.ietf.org/ID-Checklist.html: ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- No issues found here. Checking references for intended status: ---------------------------------------------------------------------------- No issues found here. No nits found. -------------------------------------------------------------------------------- 8. Is the document split into normative and informative references? Yes Are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? (note here that the RFC editor will not publish an RFC with normative references to IDs, it will delay publication until all such IDs are also ready for publication as RFCs.) No 9. What is the intended status of the document? (e.g., Proposed Standard, Informational?) Proposed Standard 10. For Standards Track and BCP documents, the IESG approval announcement includes a write-up section with the following sections: * Technical Summary This draft extends OSPFv2 cryptographic authentication to include the HMAC-SHA-x family of algorithms. * Working Group Summary There is no opposition to the draft and at some members of the security community are awaiting its publication. * Protocol Quality The existing cryptographic authentication is simply extended to include the new algorithms. ISIS and RIPv2 already support HMAC-SHA-X so there a precedent for applying these algorithms to IGP authentication. There is one prototype implementation. |
|
2009-05-29
|
07 | Ross Callon | PROTO writeup by Acee Lindem: OSPFv2 HMAC-SHA Cryptographic Authentication <draft-ietf-ospf-hmac-sha-05.txt … PROTO writeup by Acee Lindem: OSPFv2 HMAC-SHA Cryptographic Authentication <draft-ietf-ospf-hmac-sha-05.txt> 1. Have the chairs personally reviewed this version of the Internet Draft (ID), and in particular, do they believe this ID is ready to forward to the IESG for publication? Yes 2. Has the document had adequate review from both key WG members and key non-WG members? Yes - Both WG members and members of the security community have read it (although that doesn't mean that the SECDIR won't have comments). Do you have any concerns about the depth or breadth of the reviews that have been performed? No 3. Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)? No 4. Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or have concerns whether there really is a need for it. In any event, if your issues have been discussed in the WG and the WG has indicated it that it still wishes to advance the document, detail those concerns in the write-up. No 5. How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There was controversy as to how the HMAC-SHA digest would be computed and the subject draft is the agreed upon solution. 6. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email to the Responsible Area Director. No 7. Have the chairs verified that the document adheres to all of the ID Checklist items? idnits 2.11.11 tmp/draft-ietf-ospf-hmac-sha-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to http://www.ietf.org/ID-Checklist.html: ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- No issues found here. Checking references for intended status: ---------------------------------------------------------------------------- No issues found here. No nits found. -------------------------------------------------------------------------------- 8. Is the document split into normative and informative references? Yes Are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? (note here that the RFC editor will not publish an RFC with normative references to IDs, it will delay publication until all such IDs are also ready for publication as RFCs.) No 9. What is the intended status of the document? (e.g., Proposed Standard, Informational?) Proposed Standard 10. For Standards Track and BCP documents, the IESG approval announcement includes a write-up section with the following sections: * Technical Summary This draft extends OSPFv2 cryptographic authentication to include the HMAC-SHA-x family of algorithms. * Working Group Summary There is no opposition to the draft and at some members of the security community are awaiting its publication. * Protocol Quality The existing cryptographic authentication is simply extended to include the new algorithms. ISIS and RIPv2 already support HMAC-SHA-X so there a precedent for applying these algorithms to IGP authentication. There is one prototype implementation. |
|
2009-05-29
|
07 | Ross Callon | Draft Added by Ross Callon in state Publication Requested |
|
2009-05-27
|
05 | (System) | New version available: draft-ietf-ospf-hmac-sha-05.txt |
|
2009-05-07
|
04 | (System) | New version available: draft-ietf-ospf-hmac-sha-04.txt |
|
2008-10-21
|
03 | (System) | New version available: draft-ietf-ospf-hmac-sha-03.txt |
|
2008-01-25
|
02 | (System) | New version available: draft-ietf-ospf-hmac-sha-02.txt |
|
2007-12-04
|
01 | (System) | New version available: draft-ietf-ospf-hmac-sha-01.txt |
|
2007-04-09
|
00 | (System) | New version available: draft-ietf-ospf-hmac-sha-00.txt |