diff options
Diffstat (limited to 'doc/rfc/rfc7166.txt')
| -rw-r--r-- | doc/rfc/rfc7166.txt | 1291 |
1 files changed, 1291 insertions, 0 deletions
diff --git a/doc/rfc/rfc7166.txt b/doc/rfc/rfc7166.txt new file mode 100644 index 0000000..c899306 --- /dev/null +++ b/doc/rfc/rfc7166.txt @@ -0,0 +1,1291 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Bhatia +Request for Comments: 7166 Alcatel-Lucent +Obsoletes: 6506 V. Manral +Category: Standards Track Ionos Corp. +ISSN: 2070-1721 A. Lindem + Ericsson + March 2014 + + + Supporting Authentication Trailer for OSPFv3 + +Abstract + + Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism + for authenticating protocol packets. This behavior is different from + authentication mechanisms present in other routing protocols (OSPFv2, + Intermediate System to Intermediate System (IS-IS), RIP, and Routing + Information Protocol Next Generation (RIPng)). In some environments, + it has been found that IPsec is difficult to configure and maintain + and thus cannot be used. This document defines an alternative + mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does + not depend only upon IPsec for authentication. + + The OSPFv3 Authentication Trailer was originally defined in RFC 6506. + This document obsoletes RFC 6506 by providing a revised definition, + including clarifications and refinements of the procedures. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7166. + + + + + + + + + + + +Bhatia, et al. Standards Track [Page 1] + +RFC 7166 Authentication Trailer for OSPFv3 March 2014 + + +Copyright Notice + + Copyright (c) 2014 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Requirements ...............................................4 + 1.2. Summary of Changes from RFC 6506 ...........................4 + 2. Proposed Solution ...............................................5 + 2.1. AT-Bit in Options Field ....................................5 + 2.2. Basic Operation ............................................6 + 2.3. IPv6 Source Address Protection .............................6 + 3. OSPFv3 Security Association .....................................7 + 4. Authentication Procedure ........................................9 + 4.1. Authentication Trailer .....................................9 + 4.1.1. Sequence Number Wrap ...............................11 + 4.2. OSPFv3 Header Checksum and LLS Data Block Checksum ........11 + 4.3. Cryptographic Authentication Procedure ....................12 + 4.4. Cross-Protocol Attack Mitigation ..........................12 + 4.5. Cryptographic Aspects .....................................12 + 4.6. Message Verification ......................................15 + 5. Migration and Backward Compatibility ...........................16 + 6. Security Considerations ........................................17 + 7. IANA Considerations ............................................18 + 8. References .....................................................19 + 8.1. Normative References ......................................19 + 8.2. Informative References ....................................19 + Appendix A. Acknowledgments .......................................22 + + + + + + + + + + + +Bhatia, et al. Standards Track [Page 2] + +RFC 7166 Authentication Trailer for OSPFv3 March 2014 + + +1. Introduction + + Unlike Open Shortest Path First version 2 (OSPFv2) [RFC2328], OSPF + for IPv6 (OSPFv3) [RFC5340] does not include the AuType and + Authentication fields in its headers for authenticating protocol + packets. Instead, OSPFv3 relies on the IPsec protocols + Authentication Header (AH) [RFC4302] and Encapsulating Security + Payload (ESP) [RFC4303] to provide integrity, authentication, and/or + confidentiality. + + [RFC4552] describes how IPv6 AH and ESP extension headers can be used + to provide authentication and/or confidentiality to OSPFv3. + + However, there are some environments, e.g., Mobile Ad Hoc Networks + (MANETs), where IPsec is difficult to configure and maintain; this + mechanism cannot be used in such environments. + + [RFC4552] discusses, at length, the reasoning behind using manually + configured keys, rather than some automated key management protocol + such as Internet Key Exchange version 2 (IKEv2) [RFC5996]. The + primary problem is the lack of a suitable key management mechanism, + as OSPFv3 adjacencies are formed on a one-to-many basis and most key + management mechanisms are designed for a one-to-one communication + model. This forces the system administrator to use manually + configured Security Associations (SAs) and cryptographic keys to + provide the authentication and, if desired, confidentiality services. + + Regarding replay protection, [RFC4552] states that: + + Since it is not possible using the current standards to provide + complete replay protection while using manual keying, the proposed + solution will not provide protection against replay attacks. + + Since there is no replay protection provided, there are a number of + vulnerabilities in OSPFv3 that have been discussed in [RFC6039]. + + While techniques exist to identify ESP-NULL packets [RFC5879], these + techniques are generally not implemented in the data planes of OSPFv3 + routers. This makes it very difficult for implementations to examine + OSPFv3 packets and prioritize certain OSPFv3 packet types, e.g., + Hello packets, over the other types. + + This document defines a mechanism that works similarly to OSPFv2 + [RFC5709] to provide authentication to OSPFv3 packets and solves the + problems related to replay protection and deterministically + disambiguating different OSPFv3 packets as described above. + + + + + +Bhatia, et al. Standards Track [Page 3] + +RFC 7166 Authentication Trailer for OSPFv3 March 2014 + + + This document adds support for the Secure Hash Algorithms (SHAs) + defined in the US NIST Secure Hash Standard (SHS), which is specified + by NIST FIPS 180-4. [FIPS-180-4] includes SHA-1, SHA-224, SHA-256, + SHA-384, and SHA-512. The Hashed Message Authentication Code (HMAC) + authentication mode defined in NIST FIPS 198-1 [FIPS-198-1] is used. + +1.1. Requirements + + 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]. + +1.2. Summary of Changes from RFC 6506 + + This document includes the following changes from RFC 6506 [RFC6506]: + + 1. Sections 2.2 and 4.2 explicitly state that the Link-Local + Signaling (LLS) block checksum calculation is omitted when an + OSPFv3 Authentication Trailer is used for OSPFv3 authentication. + The LLS data block is included in the authentication digest + calculation, and computation of a checksum is unnecessary. + Clarification of this issue was documented in an erratum. + + 2. Section 3 previously recommended usage of an expired key for + transmitted OSPFv3 packets when no valid keys existed. This + statement has been removed. + + 3. Section 4.5 includes a correction to the key preparation to use + the Protocol-Specific Authentication Key (Ks) rather than the + Authentication Key (K) as the initial key (Ko). This problem was + also documented in an erratum. + + 4. Section 4.5 also includes a discussion of the choice of key length + to be the hash length (L) rather than the block size (B). The + discussion of this choice was included to clarify an issue raised + in a rejected erratum. + + 5. Sections 4.1 and 4.6 indicate that sequence number checking is + dependent on OSPFv3 packet type in order to account for packet + prioritization as specified in [RFC4222]. This was an omission + from RFC 6506 [RFC6506]. + + 6. Section 4.6 explicitly states that OSPFv3 packets with a + nonexistent or expired Security Association (SA) will be dropped. + + 7. Section 5 includes guidance on the precise actions required for an + OSPFv3 router providing a backward-compatible transition mode. + + + + +Bhatia, et al. Standards Track [Page 4] + +RFC 7166 Authentication Trailer for OSPFv3 March 2014 + + +2. Proposed Solution + + To perform non-IPsec Cryptographic Authentication, OSPFv3 routers + append a special data block, henceforth referred to as the + Authentication Trailer, to the end of the OSPFv3 packets. The length + of the Authentication Trailer is not included in the length of the + OSPFv3 packet but is included in the IPv6 payload length, as shown in + Figure 1. + + +---------------------+ -- -- +----------------------+ + | IPv6 Payload Length | ^ ^ | IPv6 Payload Length | + | PL = OL + LL | | | | PL = OL + LL + AL | + | | v v | | + +---------------------+ -- -- +----------------------+ + | OSPFv3 Header | ^ ^ | OSPFv3 Header | + | Length = OL | | | | Length = OL | + | | | OSPFv3 | | | + |.....................| | Packet | |......................| + | | | Length | | | + | OSPFv3 Packet | | | | OSPFv3 Packet | + | | v v | | + +---------------------+ -- -- +----------------------+ + | | ^ ^ | | + | Optional LLS | | LLS Data | | Optional LLS | + | LL = LLS Data | | Block | | LL = LLS Data | + | Block Length | v Length v | Block Length | + +---------------------+ -- -- +----------------------+ + ^ | | + AL = PL - (OL + LL) | | Authentication | + | | AL = Fixed Trailer + | + v | Digest Length | + -- +----------------------+ + + Figure 1: Authentication Trailer in OSPFv3 + + The presence of the Link-Local Signaling (LLS) [RFC5613] block is + determined by the L-bit setting in the OSPFv3 Options field in OSPFv3 + Hello and Database Description packets. If present, the LLS data + block is included along with the OSPFv3 packet in the Cryptographic + Authentication computation. + +2.1. AT-Bit in Options Field + + RFC 6506 introduced the AT-bit ("AT" stands for "Authentication + Trailer") into the OSPFv3 Options field. OSPFv3 routers MUST set the + AT-bit in OSPFv3 Hello and Database Description packets to indicate + that all the packets on this link will include an Authentication + Trailer. For OSPFv3 Hello and Database Description packets, the + + + +Bhatia, et al. Standards Track [Page 5] + +RFC 7166 Authentication Trailer for OSPFv3 March 2014 + + + AT-bit indicates that the AT is present. For other OSPFv3 packet + types, the OSPFv3 AT-bit setting from the OSPFv3 Hello/Database + Description setting is preserved in the OSPFv3 neighbor data + structure. OSPFv3 packet types that don't include an OSPFv3 Options + field will use the setting from the neighbor data structure to + determine whether or not the AT is expected. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+--+-+--+ + | | | | | | | | | | | | | |AT|L|AF|*|*|DC|R|N|MC|E|V6| + +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+--+-+--+ + + Figure 2: OSPFv3 Options Field + + The AT-bit, as shown in the figure above, MUST be set in all OSPFv3 + Hello and Database Description packets that contain an Authentication + Trailer. + +2.2. Basic Operation + + The procedure followed for computing the Authentication Trailer is + much the same as those described in [RFC5709] and [RFC2328]. One + difference is that the LLS data block, if present, is included in the + Cryptographic Authentication computation. + + The way the authentication data is carried in the Authentication + Trailer is very similar to how it is done in the case of [RFC2328]. + The only difference between the OSPFv2 Authentication Trailer and the + OSPFv3 Authentication Trailer is that information in addition to the + message digest is included. The additional information in the OSPFv3 + Authentication Trailer is included in the message digest computation + and is therefore protected by OSPFv3 Cryptographic Authentication as + described herein. + + Consistent with OSPFv2 Cryptographic Authentication [RFC2328] and + Link-Local Signaling Cryptographic Authentication [RFC5613], checksum + calculation and verification are omitted for both the OSPFv3 header + checksum and the LLS data block when the OSPFv3 authentication + mechanism described in this specification is used. + +2.3. IPv6 Source Address Protection + + While OSPFv3 always uses the Router ID to identify OSPFv3 neighbors, + the IPv6 source address is learned from OSPFv3 Hello packets and + copied into the neighbor data structure [RFC5340]. Hence, OSPFv3 is + susceptible to Man-in-the-Middle attacks where the IPv6 source + address is modified. To thwart such attacks, the IPv6 source address + + + +Bhatia, et al. Standards Track [Page 6] + +RFC 7166 Authentication Trailer for OSPFv3 March 2014 + + + will be included in the message digest calculation and protected by + OSPFv3 authentication. Refer to Section 4.5 for details. This is + different than the procedure specified in [RFC5709] but consistent + with [MANUAL-KEY]. + +3. OSPFv3 Security Association + + An OSPFv3 Security Association (SA) contains a set of parameters + shared between any two legitimate OSPFv3 speakers. + + Parameters associated with an OSPFv3 SA are as follows: + + o Security Association Identifier (SA ID) + + This is a 16-bit unsigned integer used to uniquely identify an + OSPFv3 SA, as manually configured by the network operator. + + The receiver determines the active SA by looking at the SA ID + field in the incoming protocol packet. + + The sender, based on the active configuration, selects an SA to + use and puts the correct Key ID value associated with the SA in + the OSPFv3 protocol packet. If multiple valid and active OSPFv3 + SAs exist for a given interface, the sender may use any of those + SAs to protect the packet. + + Using SA IDs makes changing keys while maintaining protocol + operation convenient. Each SA ID specifies two independent parts: + the authentication algorithm and the Authentication Key, as + explained below. + + Normally, an implementation would allow the network operator to + configure a set of keys in a key chain, with each key in the chain + having a fixed lifetime. The actual operation of these mechanisms + is outside the scope of this document. + + Note that each SA ID can indicate a key with a different + authentication algorithm. This allows the introduction of new + authentication mechanisms without disrupting existing OSPFv3 + adjacencies. + + o Authentication Algorithm + + This signifies the authentication algorithm to be used with this + OSPFv3 SA. This information is never sent in clear text over the + wire. Because this information is not sent on the wire, the + implementer chooses an implementation-specific representation for + this information. + + + +Bhatia, et al. Standards Track [Page 7] + +RFC 7166 Authentication Trailer for OSPFv3 March 2014 + + + Currently, the following algorithms are supported: + + * HMAC-SHA-1, + + * HMAC-SHA-256, + + * HMAC-SHA-384, and + + * HMAC-SHA-512. + + o Authentication Key + + This value denotes the Cryptographic Authentication Key associated + with this OSPFv3 SA. The length of this key is variable and + depends upon the authentication algorithm specified by the + OSPFv3 SA. + + o KeyStartAccept + + This value indicates the time that this OSPFv3 router will accept + packets that have been created with this OSPFv3 SA. + + o KeyStartGenerate + + This value indicates the time that this OSPFv3 router will begin + using this OSPFv3 SA for OSPFv3 packet generation. + + o KeyStopGenerate + + This value indicates the time that this OSPFv3 router will stop + using this OSPFv3 SA for OSPFv3 packet generation. + + o KeyStopAccept + + This value indicates the time that this OSPFv3 router will stop + accepting packets generated with this OSPFv3 SA. + + In order to achieve smooth key transition, KeyStartAccept SHOULD + be less than KeyStartGenerate, and KeyStopGenerate SHOULD be less + than KeyStopAccept. If KeyStartGenerate or KeyStartAccept is left + unspecified, the time will default to 0, and the key will be used + immediately. If KeyStopGenerate or KeyStopAccept is left + unspecified, the time will default to infinity, and the key's + lifetime will be infinite. When a new key replaces an old key, + the KeyStartGenerate time for the new key MUST be less than or + equal to the KeyStopGenerate time of the old key. + + + + + +Bhatia, et al. Standards Track [Page 8] + +RFC 7166 Authentication Trailer for OSPFv3 March 2014 + + + Key storage SHOULD persist across a system restart, warm or cold, + to avoid operational issues. In the event that the last key + associated with an interface expires, the network operator SHOULD + be notified, and the OSPFv3 packet MUST NOT be transmitted + unauthenticated. + +4. Authentication Procedure + +4.1. Authentication Trailer + + The Authentication Trailer that is appended to the OSPFv3 protocol + packet is described below: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Authentication Type | Auth Data Len | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | Security Association ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Cryptographic Sequence Number (High-Order 32 Bits) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Cryptographic Sequence Number (Low-Order 32 Bits) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Authentication Data (Variable) | + ~ ~ + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 3: Authentication Trailer Format + + The various fields in the Authentication Trailer are as follows: + + o Authentication Type + + This 16-bit field identifies the type of authentication. The + following values are defined in this specification: + + 0 - Reserved. + 1 - HMAC Cryptographic Authentication as described herein. + + o Auth Data Len + + This is the length in octets of the Authentication Trailer (AT), + including both the 16-octet fixed header and the variable-length + message digest. + + + +Bhatia, et al. Standards Track [Page 9] + +RFC 7166 Authentication Trailer for OSPFv3 March 2014 + + + o Reserved + + This field is reserved. It SHOULD be set to 0 when sending + protocol packets and MUST be ignored when receiving protocol + packets. + + o Security Association Identifier (SA ID) + + This 16-bit field maps to the authentication algorithm and the + secret key used to create the message digest appended to the + OSPFv3 protocol packet. + + Though the SA ID implies the algorithm, the HMAC output size + should not be used by implementers as an implicit hint, because + additional algorithms may be defined in the future that have the + same output size. + + o Cryptographic Sequence Number + + This is a 64-bit strictly increasing sequence number that is used + to guard against replay attacks. The 64-bit sequence number MUST + be incremented for every OSPFv3 packet sent by the OSPFv3 router. + Upon reception, the sequence number MUST be greater than the + sequence number in the last accepted OSPFv3 packet of the same + OSPFv3 packet type from the sending OSPFv3 neighbor. Otherwise, + the OSPFv3 packet is considered a replayed packet and dropped. + OSPFv3 packets of different types may arrive out of order if they + are prioritized as recommended in [RFC4222]. + + OSPFv3 routers implementing this specification MUST use available + mechanisms to preserve the sequence number's strictly increasing + property for the deployed life of the OSPFv3 router (including + cold restarts). One mechanism for accomplishing this would be to + use the high-order 32 bits of the sequence number as a wrap/boot + count that is incremented anytime the OSPFv3 router loses its + sequence number state. Sequence number wrap is described in + Section 4.1.1. + + o Authentication Data + + This field contains variable data that is carrying the digest for + the protocol packet and optional LLS data block. + + + + + + + + + +Bhatia, et al. Standards Track [Page 10] + +RFC 7166 Authentication Trailer for OSPFv3 March 2014 + + +4.1.1. Sequence Number Wrap + + When incrementing the sequence number for each transmitted OSPFv3 + packet, the sequence number should be treated as an unsigned 64-bit + value. If the lower-order 32-bit value wraps, the higher-order + 32-bit value should be incremented and saved in non-volatile storage. + If by some chance the OSPFv3 router is deployed long enough that + there is a possibility that the 64-bit sequence number may wrap, all + keys, independent of their key distribution mechanism, MUST be reset + to avoid the possibility of replay attacks. Once the keys have been + changed, the higher-order sequence number can be reset to 0 and saved + to non-volatile storage. + +4.2. OSPFv3 Header Checksum and LLS Data Block Checksum + + Both the checksum calculation and verification are omitted for the + OSPFv3 header checksum and the LLS data block checksum [RFC5613] when + the OSPFv3 authentication mechanism described in this specification + is used. This implies the following: + + o For OSPFv3 packets to be transmitted, the OSPFv3 header checksum + computation is omitted, and the OSPFv3 header checksum SHOULD be + set to 0 prior to computation of the OSPFv3 Authentication Trailer + message digest. + + o For OSPFv3 packets including an LLS data block to be transmitted, + the OSPFv3 LLS data block checksum computation is omitted, and the + OSPFv3 LLS data block checksum SHOULD be set to 0 prior to + computation of the OSPFv3 Authentication Trailer message digest. + + o For received OSPFv3 packets including an OSPFv3 Authentication + Trailer, OSPFv3 header checksum verification MUST be omitted. + However, if the OSPFv3 packet does include a non-zero OSPFv3 + header checksum, it will not be modified by the receiver and will + simply be included in the OSPFv3 Authentication Trailer message + digest verification. + + o For received OSPFv3 packets including an LLS data block and OSPFv3 + Authentication Trailer, LLS data block checksum verification MUST + be omitted. However, if the OSPFv3 packet does include an LLS + data block with a non-zero checksum, it will not be modified by + the receiver and will simply be included in the OSPFv3 + Authentication Trailer message digest verification. + + + + + + + + +Bhatia, et al. Standards Track [Page 11] + +RFC 7166 Authentication Trailer for OSPFv3 March 2014 + + +4.3. Cryptographic Authentication Procedure + + As noted earlier, the SA ID maps to the authentication algorithm and + the secret key used to generate and verify the message digest. This + specification discusses the computation of OSPFv3 Cryptographic + Authentication data when any of the NIST SHS family of algorithms is + used in the Hashed Message Authentication Code (HMAC) mode. + + The currently valid algorithms (including mode) for OSPFv3 + Cryptographic Authentication include: + + o HMAC-SHA-1, + + o HMAC-SHA-256, + + o HMAC-SHA-384, and + + o HMAC-SHA-512. + + 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 MAY also include support for HMAC-SHA-384 and + HMAC-SHA-512. + + Implementations of this specification MUST use HMAC-SHA-256 as the + default authentication algorithm. + +4.4. Cross-Protocol Attack Mitigation + + In order to prevent cross-protocol replay attacks for protocols + sharing common keys, the two-octet OSPFv3 Cryptographic Protocol ID + is appended to the Authentication Key prior to use. Other protocols + using Cryptographic Authentication as specified herein MUST similarly + append their respective Cryptographic Protocol IDs to their keys in + this step. Refer to the IANA Considerations (Section 7). + +4.5. Cryptographic Aspects + + In the algorithm description below, the following nomenclature, which + is consistent with [FIPS-198-1], is used: + + H is the specific hashing algorithm (e.g., SHA-256). + + K is the Authentication Key from the OSPFv3 Security Association. + + Ks is a Protocol-Specific Authentication Key obtained by appending + Authentication Key (K) with the two-octet OSPFv3 Cryptographic + Protocol ID. + + + +Bhatia, et al. Standards Track [Page 12] + +RFC 7166 Authentication Trailer for OSPFv3 March 2014 + + + Ko is the cryptographic key used with the hash algorithm. + + B is the block size of H, measured in octets rather than bits. Note + 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 a value that is the same length as the hash output or message + digest. The first 16 octets contain the IPv6 source address followed + by the hexadecimal value 0x878FE1F3 repeated (L-16)/4 times. This + implies that hash output is always a length of at least 16 octets. + + 1. Preparation of the Key + + The OSPFv3 Cryptographic Protocol ID is appended to the + Authentication Key (K), yielding a Protocol-Specific + Authentication Key (Ks). In this application, Ko is always + L octets long. While [RFC2104] supports a key that is up to + B octets long, this application uses L as the Ks length consistent + with [RFC4822], [RFC5310], and [RFC5709]. According to + [FIPS-198-1], Section 3, keys greater than L octets do not + significantly increase the function strength. Ks is computed as + follows: + + If Ks is L octets long, then Ko is equal to Ks. If Ks is more + than L octets long, then Ko is set to H(Ks). If Ks is less + than L octets long, then Ko is set to the value of Ks, with + zeros appended to the end of Ks such that Ko is L octets long. + + 2. First-Hash + + First, the OSPFv3 packet's Authentication Data field in the + Authentication Trailer is filled with the value Apad. This is + very similar to the appendage described in [RFC2328], + Appendix D.4.3, Items (6)(a) and (6)(d)). + + + + + + +Bhatia, et al. Standards Track [Page 13] + +RFC 7166 Authentication Trailer for OSPFv3 March 2014 + + + Then, a First-Hash, also known as the inner hash, is computed as + follows: + + First-Hash = H(Ko XOR Ipad || (OSPFv3 Packet)) + + When XORing Ko and Ipad, Ko will be padded with zeros to the + length of Ipad. + + Implementation Note: The First-Hash above includes the + Authentication Trailer as well as the OSPFv3 packet as per + [RFC2328], Appendix D.4.3, and the LLS data block, if present + [RFC5613]. + + The definition of Apad (above) ensures that it is always the same + length as the hash output. This is consistent with RFC 2328. + Note that the "(OSPFv3 Packet)" referenced in the First-Hash + function above includes both the optional LLS data block and the + OSPFv3 Authentication Trailer. + + The digest length for SHA-1 is 20 octets; for SHA-256, 32 octets; + for SHA-384, 48 octets; and for SHA-512, 64 octets. + + 3. Second-Hash + + Then a Second-Hash, also known as the outer hash, is computed as + follows: + + Second-Hash = H(Ko XOR Opad || First-Hash) + + When XORing Ko and Opad, Ko will be padded with zeros to the + length of Opad. + + 4. Result + + The resulting Second-Hash becomes the authentication data that is + sent in the Authentication Trailer of the OSPFv3 packet. The + length of the authentication data is always identical to the + message digest size of the specific hash function H that is + being used. + + This also means that the use of hash functions with larger output + sizes will also increase the size of the OSPFv3 packet as + transmitted on the wire. + + + + + + + + +Bhatia, et al. Standards Track [Page 14] + +RFC 7166 Authentication Trailer for OSPFv3 March 2014 + + + Implementation Note: [RFC2328], Appendix D specifies that the + Authentication Trailer is not counted in the OSPF packet's own + Length field but is included in the packet's IP Length field. + Similar to this, the Authentication Trailer is not included in + the OSPFv3 header length but is included in the IPv6 header + payload length. + +4.6. Message Verification + + A router would determine that OSPFv3 is using an Authentication + Trailer (AT) by examining the AT-bit in the Options field in the + OSPFv3 header for Hello and Database Description packets. The + specification in the Hello and Database Description options indicates + that other OSPFv3 packets will include the Authentication Trailer. + + The AT is accessed using the OSPFv3 packet header length to access + the data after the OSPFv3 packet and, if an LLS data block [RFC5613] + is present, using the LLS data block length to access the data after + the LLS data block. The L-bit in the OSPFv3 options in Hello and + Database Description packets is examined to determine if an LLS data + block is present. If an LLS data block is present (as specified by + the L-bit), it is included along with the OSPFv3 Hello or Database + Description packet in the Cryptographic Authentication computation. + + Due to the placement of the AT following the LLS data block and the + fact that the LLS data block is included in the Cryptographic + Authentication computation, OSPFv3 routers supporting this + specification MUST minimally support examining the L-bit in the + OSPFv3 options and using the length in the LLS data block to access + the AT. It is RECOMMENDED that OSPFv3 routers supporting this + specification fully support OSPFv3 Link-Local Signaling [RFC5613]. + + If usage of the AT, as specified herein, is configured for an OSPFv3 + link, OSPFv3 Hello and Database Description packets with the AT-bit + clear in the options will be dropped. All OSPFv3 packet types will + be dropped if the AT is configured for the link and the IPv6 header + length is less than the amount necessary to include an Authentication + Trailer. + + The receiving interface's OSPFv3 SA is located using the SA ID in the + received AT. If the SA is not found, or if the SA is not valid for + reception (i.e., current time < KeyStartAccept or + current time >= KeyStopAccept), the OSPFv3 packet is dropped. + + If the cryptographic sequence number in the AT is less than or equal + to the last sequence number in the last OSPFv3 packet of the same + OSPFv3 type successfully received from the neighbor, the OSPFv3 + + + + +Bhatia, et al. Standards Track [Page 15] + +RFC 7166 Authentication Trailer for OSPFv3 March 2014 + + + packet MUST be dropped, and an error event SHOULD be logged. OSPFv3 + packets of different types may arrive out of order if they are + prioritized as recommended in [RFC4222]. + + Authentication-algorithm-dependent processing needs to be performed, + using the algorithm specified by the appropriate OSPFv3 SA for the + received packet. + + Before an implementation performs any processing, it needs to save + the values of the Authentication Data field from the Authentication + Trailer appended to the OSPFv3 packet. + + It should then set the Authentication Data field with Apad before the + authentication data is computed (as described in Section 4.5). The + calculated data is compared with the received authentication data in + the Authentication Trailer. If the two do not match, the packet MUST + be discarded, and an error event SHOULD be logged. + + After the OSPFv3 packet has been successfully authenticated, + implementations MUST store the 64-bit cryptographic sequence number + for each OSPFv3 packet type received from the neighbor. The saved + cryptographic sequence numbers will be used for replay checking for + subsequent packets received from the neighbor. + +5. Migration and Backward Compatibility + + All OSPFv3 routers participating on a link SHOULD be migrated to + OSPFv3 authentication at the same time. As with OSPFv2 + authentication, a mismatch in the SA ID, Authentication Type, or + message digest will result in failure to form an adjacency. For + multi-access links, communities of OSPFv3 routers could be migrated + using different Interface Instance IDs. However, at least one router + would need to form adjacencies between both the OSPFv3 routers + including and not including the Authentication Trailer. This would + result in sub-optimal routing as well as added complexity and is only + recommended in cases where authentication is desired on the link and + migrating all the routers on the link at the same time isn't + feasible. + + In support of uninterrupted deployment, an OSPFv3 router implementing + this specification MAY implement a transition mode where it includes + the Authentication Trailer in transmitted packets but does not verify + this information in received packets. This is provided as a + + + + + + + + +Bhatia, et al. Standards Track [Page 16] + +RFC 7166 Authentication Trailer for OSPFv3 March 2014 + + + transition aid for networks in the process of migrating to the + authentication mechanism described in this specification. More + specifically: + + 1. OSPFv3 routers in transition mode will include the OSPFv3 + Authentication Trailer in transmitted packets and set the AT-bit + in the Options field of transmitted Hello and Database Description + packets. OSPFv3 routers receiving these packets and not having + authentication configured will ignore the Authentication Trailer + and AT-bit. + + 2. OSPFv3 routers in transition mode will also calculate and set the + OSPFv3 header checksum and the LLS data block checksum in + transmitted packets so that they will not be dropped by OSPFv3 + routers without authentication configured. + + 3. OSPFv3 routers in transition mode will authenticate received + packets that either have the AT-bit set in the Options field for + Hello or Database Description packets or are from a neighbor that + previously set the AT-bit in the Options field of successfully + authenticated Hello and Database Description packets. + + 4. OSPFv3 routers in transition mode will also accept packets without + the Options field AT-bit set in Hello and Database Description + packets. These packets will be assumed to be from OSPFv3 routers + without authentication configured, and they will not be + authenticated. Additionally, the OSPFv3 header checksum and LLS + data block checksum will be validated. + +6. Security Considerations + + This document proposes extensions to OSPFv3 that would make it more + secure than OSPFv3 as defined in [RFC5340]. It does not provide + confidentiality, as a routing protocol contains information that does + not need to be kept secret. It does, however, provide means to + authenticate the sender of packets that are of interest. It + addresses all the security issues that have been identified in + [RFC6039] and [RFC6506]. + + It should be noted that the authentication method described in this + document is not being used to authenticate the specific originator of + a packet but rather is being used to confirm that the packet has + indeed been issued by a router that has access to the + Authentication Key. + + Deployments SHOULD use sufficiently long and random values for the + Authentication Key so that guessing and other cryptographic attacks + on the key are not feasible in their environments. Furthermore, it + + + +Bhatia, et al. Standards Track [Page 17] + +RFC 7166 Authentication Trailer for OSPFv3 March 2014 + + + is RECOMMENDED that Authentication Keys incorporate at least 128 + pseudorandom bits to minimize the risk of such attacks. In support + of these recommendations, management systems SHOULD support + hexadecimal input of Authentication Keys. + + Deployments that support a transitionary state but interoperate with + routers that do not support this authentication method may be exposed + to unauthenticated data during the transition period. + + The mechanism described herein is not perfect and does not need to be + perfect. Instead, this mechanism represents a significant increase + in the effort required for an adversary to successfully attack the + OSPFv3 protocol, while not causing undue implementation, deployment, + or operational complexity. + + Refer to [RFC4552] for additional considerations on manual keying. + +7. IANA Considerations + + This document obsoletes RFC 6506; thus, IANA has updated the + references in existing registries that pointed to RFC 6506 to point + to this document. This is the only IANA action requested by this + document. + + IANA previously allocated the AT-bit (0x000400) in the "OSPFv3 + Options (24 bits)" registry as described in Section 2.1. + + IANA previously created the "Open Shortest Path First v3 (OSPFv3) + Authentication Trailer Options" registry. This registry includes the + "OSPFv3 Authentication Types" registry, which defines valid values + for the Authentication Type field in the OSPFv3 Authentication + Trailer. The registration procedure is Standards Action [RFC5226]. + + +-------------+-----------------------------------+ + |Value | Designation | + +-------------+-----------------------------------+ + | 0 | Reserved | + | | | + | 1 | HMAC Cryptographic Authentication | + | | | + | 2-65535 | Unassigned | + +-------------+-----------------------------------+ + + OSPFv3 Authentication Types + + Finally, IANA previously created the "Keying and Authentication for + Routing Protocols (KARP) Parameters" registry. This registry + includes the "Cryptographic Protocol ID" registry, which provides + + + +Bhatia, et al. Standards Track [Page 18] + +RFC 7166 Authentication Trailer for OSPFv3 March 2014 + + + unique protocol-specific values for cryptographic applications, + including but not limited to prevention of cross-protocol replay + attacks. Values can be assigned for both native IPv4/IPv6 protocols + and UDP/TCP protocols. The registration procedure is Standards + Action. + + +-------------+----------------------+ + | Value/Range | Designation | + +-------------+----------------------+ + | 0 | Reserved | + | | | + | 1 | OSPFv3 | + | | | + | 2-65535 | Unassigned | + +-------------+----------------------+ + + Cryptographic Protocol ID + +8. References + +8.1. Normative References + + [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. + + [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF + for IPv6", RFC 5340, July 2008. + + [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., + Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic + Authentication", RFC 5709, October 2009. + +8.2. Informative References + + [FIPS-180-4] + US National Institute of Standards and Technology, "Secure + Hash Standard (SHS)", FIPS PUB 180-4, March 2012. + + [FIPS-198-1] + US National Institute of Standards and Technology, "The + Keyed-Hash Message Authentication Code (HMAC)", FIPS + PUB 198-1, July 2008. + + + + + + + +Bhatia, et al. Standards Track [Page 19] + +RFC 7166 Authentication Trailer for OSPFv3 March 2014 + + + [MANUAL-KEY] + Bhatia, M., Hartman, S., and D. Zhang, "Security Extension + for OSPFv2 when using Manual Key Management", Work in + Progress, February 2011. + + [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- + Hashing for Message Authentication", RFC 2104, + February 1997. + + [RFC4222] Choudhury, G., Ed., "Prioritized Treatment of Specific + OSPF Version 2 Packets and Congestion Avoidance", BCP 112, + RFC 4222, October 2005. + + [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, + December 2005. + + [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", + RFC 4303, December 2005. + + [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality + for OSPFv3", RFC 4552, June 2006. + + [RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic + Authentication", RFC 4822, February 2007. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + + [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., + and M. Fanto, "IS-IS Generic Cryptographic + Authentication", RFC 5310, February 2009. + + [RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. + Yeung, "OSPF Link-Local Signaling", RFC 5613, August 2009. + + [RFC5879] Kivinen, T. and D. McDonald, "Heuristics for Detecting + ESP-NULL Packets", RFC 5879, May 2010. + + [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, + "Internet Key Exchange Protocol Version 2 (IKEv2)", + RFC 5996, September 2010. + + + + + + + + + +Bhatia, et al. Standards Track [Page 20] + +RFC 7166 Authentication Trailer for OSPFv3 March 2014 + + + [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues + with Existing Cryptographic Protection Methods for Routing + Protocols", RFC 6039, October 2010. + + [RFC6506] Bhatia, M., Manral, V., and A. Lindem, "Supporting + Authentication Trailer for OSPFv3", RFC 6506, + February 2012. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bhatia, et al. Standards Track [Page 21] + +RFC 7166 Authentication Trailer for OSPFv3 March 2014 + + +Appendix A. Acknowledgments + + First and foremost, thanks to the US National Institute of Standards + and Technology for their work on the SHA [FIPS-180-4] and HMAC + [FIPS-198-1]. + + Thanks also need to go to the authors of the HMAC-SHA authentication + RFCs, including [RFC4822], [RFC5310], and [RFC5709]. The basic + HMAC-SHA procedures were originally described by Ran Atkinson in + [RFC4822]. + + Also, thanks to Ran Atkinson for help in the analysis of RFC 6506 + errata. + + Thanks to Srinivasan K L and Marek Karasek for their identification + and submission of RFC 6506 errata. + + Thanks to Sam Hartman for discussions on replay mitigation and the + use of a 64-bit strictly increasing sequence number. Also, thanks to + Sam for comments during IETF last call with respect to the OSPFv3 SA + and the sharing of keys between protocols. + + Thanks to Michael Barnes for numerous comments and strong input on + the coverage of LLS by the Authentication Trailer (AT). + + Thanks to Marek Karasek for providing the specifics with respect to + backward-compatible transition mode. + + Thanks to Michael Dubrovskiy and Anton Smirnov for comments on + document revisions. + + Thanks to Rajesh Shetty for numerous comments, including the + suggestion to include an Authentication Type field in the + Authentication Trailer for extendibility. + + Thanks to Uma Chunduri for suggesting that we may want to protect the + IPv6 source address even though OSPFv3 uses the Router ID for + neighbor identification. + + Thanks to Srinivasan K L, Shraddha H, Alan Davey, Russ White, Stan + Ratliff, and Glen Kent for their support and review comments. + + Thanks to Alia Atlas for comments made under the purview of the + Routing Directorate review. + + Thanks to Stephen Farrell for comments during the IESG review. + Stephen was also involved in the discussion of cross-protocol + attacks. + + + +Bhatia, et al. Standards Track [Page 22] + +RFC 7166 Authentication Trailer for OSPFv3 March 2014 + + + Thanks to Brian Carpenter for comments made during the Gen-ART + review. + + Thanks to Victor Kuarsingh for the OPS-DIR review. + + Thanks to Brian Weis for the SEC-DIR review. + +Authors' Addresses + + Manav Bhatia + Alcatel-Lucent + Bangalore + India + + EMail: manav.bhatia@alcatel-lucent.com + + + Vishwas Manral + Ionos Corp. + 4100 Moorpark Ave. + San Jose, CA 95117 + USA + + EMail: vishwas@ionosnetworks.com + + + Acee Lindem + Ericsson + 301 Midenhall Way + Cary, NC 27513 + USA + + EMail: acee.lindem@ericsson.com + + + + + + + + + + + + + + + + + + +Bhatia, et al. Standards Track [Page 23] + |