Skip to main content

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