RFC 5709

OSPFv2 HMAC-SHA Cryptographic Authentication

📅 published October 2009, from ietf

RFC 5709: OSPFv2 HMAC-SHA Cryptographic Authentication 🦋

Okay bestie, so RFC 5709 is a Standards Track doc from October 2009 that gives OSPFv2's built-in crypto auth a total glow-up 💅✨ It came out of the Network Working Group, and the author squad is M. Bhatia (Alcatel-Lucent), V. Manral (IP Infusion), M. Fanto (Aegis Data Security), R. White, M. Barnes (Cisco Systems), T. Li (Ericsson), and R. Atkinson (Extreme Networks). Its header says it Updates: 2328, which means it's building on RFC 2328 🎀 There's no Obsoletes entry in the title block, so nothing gets retired here.

Abstract ✨

So the vibe is this: the doc explains how the NIST Secure Hash Standard family of algorithms can be used with the built-in cryptographic authentication mechanism in OSPF version 2 🔥 It updates, but does not supercede, the cryptographic authentication mechanism in RFC 2328. Not a replacement, just an upgrade 🦋

Status of This Memo 📜

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. 💜

Heads up, this part is serious: the document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Read them carefully, because they spell out your rights and restrictions for this document. Any Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the BSD License.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people controlling the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. Unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The one exception is formatting it for publication as an RFC or translating it into languages other than English 🌈

1. Introduction 🌸

Okay so, deploying any routing protocol comes with a variety of risks [Bell89] 😬 This document is an update to OSPFv2 Cryptographic Authentication, which is specified in Appendix D of RFC 2328. It does not deprecate or supercede RFC 2328. OSPFv2 itself is defined in RFC 2328 [RFC2328] 🧚

This doc adds support for the Secure Hash Algorithms (SHA) defined in the US NIST Secure Hash Standard (SHS), which is defined by NIST FIPS 180-2. [FIPS-180-2] includes SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 ✨ It also uses the Hashed Message Authentication Code (HMAC) authentication mode defined in NIST FIPS 198 [FIPS-198] 🍓

It is believed that [RFC2104] is mathematically identical to [FIPS-198]. It is also believed that the algorithms in [RFC4634] are mathematically identical to [FIPS-180-2] 🤍

Why was this even made? Operators asked to be able to use the NIST SHS family of algorithms in the NIST HMAC mode. They were being forced to use Keyed-MD5 algorithm and mode with OSPFv2 Cryptographic Authentication, and they were not here for it 💀 Cryptographic matters get a deeper dive in the Security Considerations section of this document 🔐

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 📖

2. Background 🦋

All OSPF protocol exchanges can be authenticated 🔥 The OSPF packet header (see Appendix A.3.1 of RFC 2328) includes an Authentication Type field and 64 bits of data for use by the appropriate authentication scheme, which gets chosen by the Type field 💅

The authentication type is configurable on a per-interface basis (or, equivalently, on a per-network/subnet basis). Additional authentication data is also configurable on a per-interface basis 🎀

OSPF authentication types 0, 1, and 2 are defined by RFC 2328. This document is an update to RFC 2328 that only applies to Authentication Type 2, "Cryptographic Authentication" 👑

3. Cryptographic Authentication with NIST SHS in HMAC Mode 🔐

Using this authentication type, a shared secret key is configured in all routers attached to a common network/subnet. For each OSPF protocol packet, the key is used to generate or verify a "message digest" that is appended to the end of the OSPF packet. The message digest is a one-way function of the OSPF protocol packet and the secret key. Since the secret key is never sent over the network in the clear, protection is provided against passive attacks [RFC1704] 🫶

The algorithms used to generate and verify the message digest are specified implicitly by the secret key. This spec covers computing OSPFv2 Cryptographic Authentication data when any of the NIST SHS family of algorithms is used in the Hashed Message Authentication Code (HMAC) mode. Also see RFC 2328, Appendix D 🌈

With the additions in this document, the currently valid algorithms (including mode) for OSPFv2 Cryptographic Authentication are:

        Keyed-MD5               (defined in RFC 2328, Appendix D)
        HMAC-SHA-1              (defined here)
        HMAC-SHA-256            (defined here)
        HMAC-SHA-384            (defined here)
        HMAC-SHA-512            (defined here)

Of the above, implementations of this specification MUST include support for at least:

        HMAC-SHA-256

and SHOULD include support for:

        HMAC-SHA-1

and SHOULD also (for backwards compatibility with existing implementations and deployments) include support for:

        Keyed-MD5

and MAY also include support for:

        HMAC-SHA-384
        HMAC-SHA-512
An implementation of this specification MUST allow network operators to configure ANY authentication algorithm supported by that implementation for use with ANY given KeyID value that is configured into that OSPFv2 router. 🚨

3.1. Generating Cryptographic Authentication 💖

The overall cryptographic authentication process defined in Appendix D of RFC 2328 stays the same 🧚 What changes is the specific crypto details (SHA rather than MD5, and HMAC rather than Keyed-Hash), and those are defined here. To reduce confusion, this section keeps the repetition of text from RFC 2328, Appendix D to a minimum, and that appendix is incorporated here by reference [RFC2328] 📜

First, following the procedure defined in RFC 2328, Appendix D, select the appropriate OSPFv2 Security Association for use with this packet, and set the KeyID field to the KeyID value of that OSPFv2 Security Association 🔑

Second, set the Authentication Type to Cryptographic Authentication, and set the Authentication Data Length field to the length (measured in bytes, not bits) of the cryptographic hash that will be used. When any NIST SHS algorithm is used in HMAC mode with OSPFv2 Cryptographic Authentication, the Authentication Data Length equals the normal hash output length (measured in bytes) for the specific NIST SHS algorithm in use. For example, with NIST SHA-256, the Authentication Data Length is 32 bytes 🍓

Third, the 32-bit cryptographic sequence number is set according to the procedures in RFC 2328, Appendix D that apply to the Cryptographic Authentication type ⏱️

Fourth, the message digest is calculated and appended to the OSPF packet, as described below in Section 3.3. The KeyID, Authentication Algorithm, and Authentication Key used to calculate the digest are all components of the selected OSPFv2 Security Association. The input to the authentication algorithm is the OSPF packet and the secret key 🎀

3.2. OSPFv2 Security Association 🎀

Okay so, this doc uses the term OSPFv2 Security Association (OSPFv2 SA for short) to mean the authentication key info defined in Section D.3 of RFC 2328. Plot twist: OSPFv2 doesn't have any in-band way to create or manage these SAs 🙈. The parameters of an OSPFv2 SA are updated to be:

  • Key Identifier (KeyID) 🔑 This is an 8-bit unsigned value that uniquely identifies an OSPFv2 SA. The router administrator configures it (or, in the future, maybe some key management protocol the IETF specifies). The receiver uses it to find the right OSPFv2 SA to use, and the sender puts this KeyID in the OSPF packet based on the active OSPF configuration.
  • Authentication Algorithm 🧁 This says which authentication algorithm (and cryptographic mode, like HMAC) gets used. This info SHOULD never be sent over the wire in cleartext form. Right now the valid values are Keyed-MD5, HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512.
  • Authentication Key 🗝️ This is the cryptographic key used for cryptographic authentication with this OSPFv2 SA. This value SHOULD never be sent over the wire in cleartext form. It's noted as "K" in Section 3.3 below.
  • Key Start Accept ⏰ The time that this OSPF router will accept packets that were created with this OSPF Security Association.
  • Key Start Generate 🚀 The time that this OSPF router will begin using this OSPF Security Association to generate OSPF packets.
  • Key Stop Generate 🛑 The time that this OSPF router will stop using this OSPF Security Association to generate OSPF packets.
  • Key Stop Accept 🚪 The time that this OSPF router will stop accepting packets generated with this OSPF Security Association.

For a smooth key transition, KeyStartAccept SHOULD be less than KeyStartGenerate, and KeyStopGenerate SHOULD be less than KeyStopAccept. If KeyStopGenerate and KeyStopAccept are left unspecified, the key's lifetime is infinite ♾️. When a new key replaces an old one, the KeyStartGenerate time for the new key MUST be less than or equal to the KeyStopGenerate time of the old key. Main character timing, no cap 💅.

Key storage SHOULD persist across a system restart, warm or cold, so nothing goes sideways operationally 🫶. Now the scary part 😭: if the last key tied to an interface expires, it's unacceptable to fall back to an unauthenticated state, and it's not advisable to disrupt routing either. So the router should send a "last Authentication Key expiration" notification to the network manager and treat the key as having an infinite lifetime until the lifetime gets extended, the key is deleted by network management, or a new key is configured. Iconic protection energy 👑.

3.3. Cryptographic Aspects 🧮

This section describes how the Authentication Data value gets computed when any NIST SHS algorithm is used in HMAC mode with OSPFv2 Cryptographic Authentication. It's giving math class, but I promise it's cute 🦋.

In the algorithm below, we use the following nomenclature, which is consistent with [FIPS-198]:

  • H is the specific hashing algorithm (e.g., SHA-256).
  • K is the Authentication Key for the OSPFv2 security association.
  • Ko is the cryptographic key used with the hash algorithm.
  • B is the block size of H, measured in octets rather than bits. Note well that B is the internal block size, not the hash size 👀.
For SHA-1 and SHA-256: B == 64
For SHA-384 and SHA-512: B == 128
  • L is the length of the hash, measured in octets rather than bits.
  • XOR is the exclusive-or operation.
  • Opad is the hexadecimal value 0x5c repeated B times.
  • Ipad is the hexadecimal value 0x36 repeated B times.
  • Apad is the hexadecimal value 0x878FE1F3 repeated (L/4) times.

Implementation note: this Apad definition means Apad is always the same length as the hash output. Lowkey genius 🧠.

(1) PREPARATION OF KEY 🥣 In this application, Ko is always L octets long. If the Authentication Key (K) is L octets long, then Ko is equal to K. If the Authentication Key (K) is more than L octets long, then Ko is set to H(K). If the Authentication Key (K) is less than L octets long, then Ko is set to the Authentication Key (K) with zeros appended to the end of it, so Ko ends up L octets long.

(2) FIRST-HASH 🥞 First, the OSPFv2 packet's Authentication Trailer (the appendage described in RFC 2328, Section D.4.3, Page 233, items (6)(a) and (6)(d)) gets filled with the value Apad, and the Authentication Type field is set to 2.

Then we compute a First-Hash, also known as the inner hash:

First-Hash = H(Ko XOR Ipad || (OSPFv2 Packet))

Implementation Notes: the First-Hash above includes the Authentication Trailer containing the Apad value, as well as the OSPF packet, as per RFC 2328, Section D.4.3. The Apad definition (above) makes sure it's always the same length as the hash output, which is consistent with RFC 2328. The "(OSPFv2 Packet)" mentioned in the First-Hash (above) does include the OSPF Authentication Trailer. Digest lengths are 20 bytes for SHA-1, 32 bytes for SHA-256, 48 bytes for SHA-384, and 64 bytes for SHA-512 🧁.

(3) SECOND-HASH 🍰 Then we compute a Second-Hash, also known as the outer hash:

Second-Hash = H(Ko XOR Opad || First-Hash)

(4) RESULT 🏆 The resulting Second-Hash becomes the Authentication Data that gets sent in the Authentication Trailer of the OSPFv2 packet. The length of the Authentication Trailer is always identical to the message digest size of the specific hash function H being used.

This also means that hash functions with larger output sizes will make the OSPFv2 packet bigger as it goes out on the wire 📦.

Implementation Note: RFC 2328, Appendix D says the Authentication Trailer is not counted in the OSPF packet's own Length field, but it is included in the packet's IP Length field. Read that twice, bestie 🙈.

3.4. Message Verification 🔍

Message verification follows the procedure defined in RFC 2328, except that the cryptographic calculation of the message digest follows the procedure in Section 3.3 above whenever any NIST SHS algorithm in HMAC mode is in use. Kindly recall that the cryptographic algorithm/mode in use is indicated implicitly by the KeyID of the received OSPFv2 packet 🫧.

Implementation Notes:

  • You MUST save the received digest value before calculating the expected digest value, so that after that calculation you can compare the received value with the expected value to decide whether to accept that OSPF packet. Don't skip this step, periodt 💀.
  • RFC 2328, Section D.4.3 (6) (c) should be read very closely before you implement the above. With SHA algorithms in HMAC mode, Apad is placed where the MD5 key would go if Keyed-MD5 were in use. 🎀

3.5. Changing OSPFv2 Security Associations 🔄

Using KeyIDs makes switching the active OSPFv2 SA super convenient 💖. An implementation can choose to attach a lifetime to each OSPFv2 SA, and then it can automatically switch to a different OSPFv2 SA based on the lifetimes of the configured OSPFv2 SA(s). Automation, iconic ✨.

After the active OSPFv2 SA changes, the OSPF sender uses the (different) KeyID value associated with the newly active OSPFv2 SA. The receiver uses this new KeyID to pick the appropriate (new) OSPFv2 SA for the received OSPF packet that carries the new KeyID value 🦋.

Because the KeyID field is present, the receiver doesn't need to try every configured OSPFv2 Security Association against each received OSPFv2 packet 🙌. This can mitigate some of the risks of a Denial-of-Service (DoS) attack on the OSPF instance, but it does not entirely prevent all conceivable DoS attacks 😭. For example, an on-link adversary could still generate OSPFv2 packets that are syntactically valid but contain invalid Authentication Data, which forces the receiver(s) to do expensive cryptographic computations just to discover the packets are invalid. Not the vibe 💀.

4. Security Considerations 🛡️

okay bestie, this section is the serious one, so let's go 🫶 This doc levels up OSPFv2 security in two ways. It adds support for the algorithms in the NIST Secure Hash Standard (SHS) using HMAC mode to the existing OSPFv2 Cryptographic Authentication method, and it also adds support for HMAC mode itself. ✨

So there are now a few alternatives to the old Keyed-MD5 mechanism 💅 Real talk: there are published concerns about how strong MD5 is ([Dobb96a], [Dobb96b], [Wang04]). Those concerns are mostly about MD5 in other modes, like MD5 in X.509v3/PKIX digital certificates. They are not an attack on Keyed-MD5, which is what OSPFv2 specified in RFC 2328. There are also published concerns about SHA [Wang05], and about MD5 and SHA when used in HMAC mode ([RR07], [RR08]). Separately, some organisations (for example, the US government) prefer NIST algorithms, such as the SHA family, over other algorithms for local policy reasons 🇺🇸

The value Apad is used here mainly to stay consistent with the IETF specs for HMAC-SHA authentication in RIPv2 SHA [RFC4822] and IS-IS SHA [RFC5310]. It also keeps OSPF protocol processing changes to a minimum, as described in Section D.4.3 of RFC 2328 [RFC2328]. Very practical, very iconic 🧚

The security you get from the Cryptographic Authentication option depends completely on three things: the strength of the cryptographic algorithm and mode in use, the strength of the key, and whether the security mechanism is implemented correctly in every communicating OSPF implementation. 🔥 So the use of high assurance development methods is recommended. It also requires that all parties keep the shared secret key secret, no exceptions 🤫 [RFC4086] gives guidance on how to generate cryptographically random bits.

⚠️ This mechanism is vulnerable to a replay attack by any on-link node. An on-link node could record a legitimate OSPF packet sent on the link, then replay that packet the next time the recorded OSPF packet's sequence number is valid. This replay attack could cause significant routing disruptions within the OSPF domain.

Ideally, to prevent the attack above, each OSPF Security Association would be replaced by a new and different OSPF Security Association before any sequence number were reused. As of the date this document was published, no form of automated key management had been standardised for OSPF. So common operational practice was to use the same OSPF Authentication Key for very long periods of time 😬 That practice is undesirable for many reasons, which is why it is clearly desirable to develop and standardise some automated key-management mechanism for OSPF. Someone please make this happen 🙏

Because all of the currently specified algorithms use symmetric cryptography, you cannot authenticate precisely which OSPF router sent a given packet. What you can authenticate is that the sender knew the OSPF Security Association (including the OSPFv2 SA's parameters) that's currently in use. Close enough, honestly 🦋

Privacy is not a requirement here, because a routing protocol contains information that doesn't need to be kept secret. Authentication of the messages inside the protocol is still very much of interest, though, because it reduces the risk of an adversary compromising the routing system by deliberately injecting false information into it. Protect the routes, bestie 💜

This technology enhances an authentication mechanism for OSPFv2. The mechanism described here is not perfect and does not need to be perfect. Instead, it represents a significant increase in the work function of an adversary attacking OSPFv2, compared with plain-text authentication or null authentication, while not causing undue implementation, deployment, or operational complexity. Denial-of-Service attacks are not generally preventable in a useful networking protocol [VK83] 💀

Because of implementation considerations, including the need for backwards compatibility, this specification uses the same mechanism as RFC 2328 and only adds support for additional cryptographic hash functions. Also, some large network operators have said they prefer to keep the basic mechanism from RFC 2328 instead of migrating to IP Security, because of deployment and operational considerations. If every OSPFv2 router supported IPsec, IPsec tunnels could be used in place of this mechanism [RFC4301]. This would, however, relegate the topology to point-to-point adjacencies over a mesh of IPsec tunnels 🕸️

If a stronger authentication were believed to be required, the use of a full digital signature [RFC2154] would be an approach that should be seriously considered 👑 Full digital signatures would enable precise authentication of the OSPF router originating each OSPF link-state advertisement, which would provide much stronger integrity protection for the OSPF routing domain. Main character energy for the whole routing domain ✨

5. IANA Considerations 📋

The OSPF Authentication Codes registry entry for Cryptographic Authentication (Registry Code 2) has been updated to refer to this document as well as to RFC 2328. Registry glow-up unlocked 🌸

6. Acknowledgements 🫶

The authors want to thank Bill Burr, Tim Polk, John Kelsey, and Morris Dworkin of (US) NIST. They reviewed the parts of this document that are directly derived from the closely related work on RIPv2 Cryptographic Authentication [RFC4822], and we're so grateful 🥹

David Black, Nevil Brownlee, Acee Lindem, and Hilarie Orman (listed in alphabetical order by last name) gave feedback on earlier versions of this document. That feedback greatly improved both the technical content and the readability of the current document 💖

Henrik Levkowetz's Internet Draft tools were super helpful in preparing this document, and they are very much appreciated 🧚

7. References 📚

7.1. Normative References

[FIPS-180-2] US National Institute of Standards & Technology, "Secure
             Hash Standard (SHS)", FIPS PUB 180-2, August 2002.

[FIPS-198]   US National Institute of Standards & Technology, "The
             Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB
             198, March 2002.

[RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2328]    Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

7.2. Informative References

[Bell89]     Bellovin, S., "Security Problems in the TCP/IP Protocol
             Suite", ACM Computer Communications Review, Volume 19,
             Number 2, pp. 32-48, April 1989.

[Dobb96a]    Dobbertin, H, "Cryptanalysis of MD5 Compress", Technical
             Report, 2 May 1996. (Presented at the Rump Session of
             EuroCrypt 1996.)

[Dobb96b]    Dobbertin, H, "The Status of MD5 After a Recent Attack",
             CryptoBytes, Vol. 2, No. 2, Summer 1996.

[RFC1704]    Haller, N. and R. Atkinson, "On Internet
             Authentication", RFC 1704, October 1994.

[RFC2104]    Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
             Keyed-Hashing for Message Authentication", RFC 2104,
             February 1997.

[RFC2154]    Murphy, S., Badger, M., and B. Wellington, "OSPF with
             Digital Signatures", RFC 2154, June 1997.

[RFC4086]    Eastlake, D., 3rd, Schiller, J., and S. Crocker,
             "Randomness Requirements for Security", BCP 106, RFC
             4086, June 2005.

[RFC4301]    Kent, S. and K. Seo, "Security Architecture for the
             Internet Protocol", RFC 4301, December 2005.

[RFC4634]    Eastlake 3rd, D. and T. Hansen, "US Secure Hash
             Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006.

[RFC4822]    Atkinson, R. and M. Fanto, "RIPv2 Cryptographic
             Authentication", RFC 4822, February 2007.

[RFC5310]    Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
             and M. Fanto, "IS-IS Generic Cryptographic
             Authentication", RFC 5310, February 2009.

[RR07]       Rechberger, C. and V. Rijmen, "On Authentication with
             HMAC and Non-random Properties", Financial Cryptography
             and Data Security, Lecture Notes in Computer Science,
             Volume 4886/2008, Springer-Verlag, Berlin, December
             2007.

[RR08]       Rechberger, C. and V. Rijmen, "New Results on NMAC/HMAC
             when Instantiated with Popular Hash Functions", Journal
             of Universal Computer Science, Volume 14, Number 3, pp.
             347-376, 1 February 2008.

[VK83]       Voydock, V. and S. Kent, "Security Mechanisms in High-
             level Networks", ACM Computing Surveys, Vol. 15, No. 2,
             June 1983.

[Wang04]     Wang, X., et alia, "Collisions for Hash Functions MD4,
             MD5, HAVAL-128, and RIPEMD", August 2004, IACR,
             http://eprint.iacr.org/2004/199

[Wang05]     Wang, X., et alia, "Finding Collisions in the Full SHA-
             1" Proceedings of Crypto 2005, Lecture Notes in Computer
             Science, Volume 3621, pp. 17-36, Springer-Verlag,
             Berlin, August 31, 2005.

Authors' Addresses 📮

Manav Bhatia
Alcatel-Lucent
Bangalore,
India

EMail: manav.bhatia@alcatel-lucent.com


Vishwas Manral
IP Infusion
Almora, Uttarakhand
India

EMail: vishwas@ipinfusion.com


Matthew J. Fanto
Aegis Data Security
Dearborn, MI
USA

EMail: mfanto@aegisdatasecurity.com
Russ I. White
Cisco Systems
7025 Kit Creek Road
P.O. Box 14987
RTP, NC
27709 USA

EMail: riw@cisco.com


M. Barnes
Cisco Systems
225 West Tasman Drive
San Jose, CA
95134  USA

EMail: mjbarnes@cisco.com


Tony Li
Ericsson
300 Holger Way
San Jose, CA
95134  USA

EMail: tony.li@tony.li


Randall J. Atkinson
Extreme Networks
3585 Monroe Street
Santa Clara, CA
95051  USA

Phone: +1 (408) 579-2800
EMail: rja@extremenetworks.com
📦 where this page comes from