One document matched: draft-ietf-ospf-security-extension-manual-keying-09.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-ospf-security-extension-manual-keying-09"
ipr="trust200902">
<front>
<title abbrev="OSPF Manual Key Management">Security Extension for OSPFv2
when using Manual Key Management</title>
<author fullname="Manav Bhatia" initials="M.B." surname="Bhatia">
<organization>Ionos Networks</organization>
<address>
<postal>
<street></street>
<city>Bangalore</city>
<code></code>
<region></region>
<country>India</country>
</postal>
<phone></phone>
<email>manav@ionosnetworks.com</email>
</address>
</author>
<author fullname="Sam Hartman" initials="S." surname="Hartman">
<organization>Painless Security</organization>
<address>
<email>hartmans@painless-security.com</email>
</address>
</author>
<author fullname="Dacheng Zhang" initials="D." surname="Zhang">
<organization>Huawei Technologies co., LTD.</organization>
<address>
<postal>
<street></street>
<city>Beijing</city>
<region></region>
<code></code>
<country>China</country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>zhangdacheng@huawei.com</email>
<uri></uri>
</address>
</author>
<author fullname="Acee Lindem" initials="A.C." surname="Lindem">
<organization>Cisco</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>USA</country>
</postal>
<phone></phone>
<email>acee@cisco.com</email>
</address>
</author>
<date/>
<area>Routing Area</area>
<workgroup>OSPF Working Group</workgroup>
<abstract>
<t>The current OSPFv2 cryptographic authentication mechanism as defined
in RFC 2328 and RFC 5709 is vulnerable to both inter-session and intra-session
replay attacks when using manual keying. Additionally, the existing
cryptographic authentication mechanism does not cover the IP header. This
omission can be exploited to carry out various types of attacks.</t>
<t>This draft proposes changes to the authentication sequence number mechanism
that will protect OSPFv2 from both inter-session and intra-session replay attacks
when using manual keys for securing OSPFv2 protocol packets.
Additionally, we also describe some changes in the
cryptographic hash computation that will eliminate attacks resulting
from OSPFv2 not protecting the IP header.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The OSPFv2 cryptographic authentication mechanism as described in
<xref target="RFC2328"/> uses per-packet sequence numbers to provide
protection against replay attacks. The sequence numbers increase
monotonically so that attempts to replay stale packets can be
thwarted. The sequence number values are maintained as a part of
neighbor adjacency state. Therefore, if an adjacency is taken down, the
associated sequence numbers get reinitialized and neighbor adjacency formation
starts over again. Additionally, the cryptographic authentication mechanism
does not specify how to deal with the rollover of a sequence number when
its value wraps. These omissions can be exploited by attackers to implement
various replay attacks (<xref target="RFC6039"/>). In order to address these
issues, we propose extensions to the authentication sequence number mechanism.</t>
<t>The cryptographic authentication as described in <xref
target="RFC2328"/> and later updated in <xref target="RFC5709"/> does
not include the IP header. This omission can be exploited to launch several
attacks as the source address in the IP header is not protected.
The OSPF specification, for broadcast and NBMA (Non-Broadcast Multi-Access Networks),
requires implementations to use the source address in the IP header to determine the
neighbor from which the packet was received. Changing the IP source address of a
packet to a conflicting IP address can be exploited to produce
a number of denial of service attacks <xref target="RFC6039"/>. If the
packet is interpreted as coming from a different neighbor, the received sequence
number state for that neighbor may be incorrectly updated. This attack may
disrupt communication with a legitimate neighbor. Hello packets may be
reflected to cause a neighbor to appear to have one-way communication.
Additionally, Database Description packets may be reflected in cases
where the per-packet sequence numbers are sufficiently divergent in order
to disrupt an adjacency <xref target="RFC6863"/>. This is referred
to as the IP layer issue in <xref target="RFC6862"/>.</t>
<t><xref target="RFC2328"/> states that implementations MUST offer
keyed MD5 authentication. It is likely that this will be deprecated in
favor of the stronger algorithms described in <xref target="RFC5709"/>
and required in <xref target="RFC6094"/>.</t>
<t>This draft proposes a few simple changes to the cryptographic
authentication mechanism, as currently described in <xref
target="RFC5709"/>, to prevent such IP layer attacks.</t>
<section title="Requirements Section">
<t>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 RFC2119 <xref
target="RFC2119"></xref>.</t>
<t>When used in lowercase, these words convey their typical use in
common language, and are not to be interpreted as described in RFC2119
<xref target="RFC2119"></xref>.</t>
</section>
<section title="Acknowledgments">
<t>Thanks to Ran Atkinson for help in the analysis of RFC 6506 errata leading to
clarifications in this document. Thanks to Gabi Nakibly for pointing out the possible
attack on p2p links.
</t>
</section>
</section>
<section title="Replay Protection using Extended Sequence Numbers">
<t>In order to provide replay protection against both inter-session and
intra-session replay attacks, the OSPFv2
sequence number is expanded to 64-bits with the least significant 32-bit
value containing a strictly increasing sequence number and the most
significant 32-bit value containing the boot count. OSPFv2
implementations are required to retain the boot count in
non-volatile storage for the deployment life the OSPF router.
The requirement to preserve the boot count is also
placed on SNMP agents by the SNMPv3 security architecture (refer to
snmpEngineBoots in <xref target="RFC4222"></xref>).</t>
<t>Since there is no room in the OSPFv2 packet for a 64-bit sequence
number, it will occupy the 8 octets following the OSPFv2 packet
and MUST be included when calculating the OSPFv2 packet digest.
These additional 8 bytes are not included in the OSPFv2 packet
header length but are included in the OSPFv2 header Authentication
Data length and the IPv4 packet header length.</t>
<t>The lower order 32-bit sequence number MUST be incremented for every OSPF packet
sent by the OSPF router. Upon reception, the sequence number MUST be greater than
the sequence number in the last OSPF packet of that type accepted from the sending OSPF neighbor.
Otherwise, the OSPF packet is considered a replayed packet and dropped.
OSPF packets of different types may arrive out of order if they are prioritized as
recommended in <xref target="RFC3414"></xref>.</t>
<t>OSPF 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). This is achieved by maintaining a
boot count in non-volatile storage and incrementing it each time the OSPF router
loses its prior sequence number state. The SNMPv3 snmpEngineBoots variable
<xref target="RFC4222"></xref> MAY be used for this purpose. However,
maintaining a separate boot count solely for OSPF sequence numbers has the
advantage of decoupling SNMP reinitialization and OSPF reinitialization. Also, in
the rare event that the lower order 32-bit sequence number wraps, the boot count
can be incremented to preserve the strictly increasing property of the aggregate
sequence number. Hence, a separate OSPF boot count is RECOMMENDED.</t>
</section>
<section title="OSPF Packet Extensions">
<t>The OSPF packet header includes an authentication type field,
and 64-bits of data for use by the appropriate authentication scheme
(determined by the type field). Authentication types 0, 1 and 2 are defined
<xref target="RFC2328"/>. This section of this defines Authentication
type TBD (3 is recommended).</t>
<t>When using this authentication scheme, the 64-bit Authentication field in the
OSPF packet header as defined in section D.3 of <xref target="RFC2328"/> is
changed as shown below. The sequence number is removed and the Key ID is
extended to 32 bits and moved to the former position of the sequence
number.</t>
<t>Additionally, the 64-bit sequence number is moved to the first 64-bits
following the OSPFv2 packet and is protected by the authentication
digest. These additional 64 bits or 8 octets are included in the
IP header length but not the OSPF header packet length.</t>
<figure>
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | Type | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Auth Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| OSPF Protocol Packet |
~ ~
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (Boot Count) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (Strictly Increasing Packet Counter) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Authentication Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - Extended Sequence Number Packet Extensions
</artwork>
</figure>
</section>
<section title="OSPF Packet Key Selection">
<t>This section describes how the proposed security solution selects
long-lived keys from key tables. <xref
target="I-D.ietf-karp-crypto-key-table"/>. Generally, a key
used for OSPFv2 packet authentication should satisfy the
following requirements:
<list style="symbols">
<t>For packet transmission, the key validity interval as
defined by SendLifetimeStart and SendLifetimeEnd must
include the current time.</t>
<t>For packet reception, the key validity interval as
defined by AcceptLifetimeStart and AcceptLifetimeEnd must
include the current time.</t>
<t>The key must be valid for the desired security algorithm.</t>
</list>In the remainder of this section, additional requirements for
keys are enumerated for different scenarios.</t>
<section title="Key Selection for Unicast OSPF Packet Transmission">
<t>Assume that a router R1 tries to send a unicast OSPF packet from
its interface I1 to the interface I2 of a remote router R2 using
security protocol P via interface I at time T. First, consider the
circumstances where R1 and R2 are not connected with a virtual link.
R1 then needs to select a long long-lived symmetric key from its key
table. Because the key should be shared by both R1 and R2 to
protect the communication between I1 and I2, the key should satisfy
the following requirements:
<list style="symbols">
<t>The Peers field is unused. OSPF authentication is interface based.</t>
<t>The Interfaces field includes the local IP address of the interface
for numbered interfaces or the MIB-II <xref target="RFC1213"/> ifIndex
for unnumbered interfaces.</t>
<t>The Direction field is either "out" or "both".</t>
<t>If multiple keys match the Interfaces field, the key with the most recent
SendLifetimeStart time will be selected. This will facilitate graceful
key rollover.</t>
<t>The Key ID field in the OSPFv2 header (refer to figure 1) will be set
to the selected key's LocalKeyName.</t>
</list></t>
<t>When R1 and R2 are connected to a virtual link, the Interfaces field
must identify the virtual endpoint rather than the virtual link. Since there
may be virtual links to the same router, the transit area ID must be part
of the identifier. Hence, the key should satisfy the following requirements:
<list style="symbols">
<t>The Peers field is unused. OSPF authentication is interface based.</t>
<t>The Interfaces field includes both the virtual endpoint's OSPF
router ID and the transit area ID for the virtual link.</t>
<t>The Direction field is either "out" or "both".</t>
<t>If multiple keys match the Interfaces field, the key with the most recent
SendLifetimeStart time will be selected. This will facilitate graceful
key rollover.</t>
<t>The Key ID field in the OSPFv2 header (refer to figure 1) will be set
to the selected key's LocalKeyName.</t>
</list></t>
</section>
<section title="Key Selection for Multicast OSPF Packet Transmission">
<t>If a router R1 sends an OSPF packet from its interface I1 to a
multicast address (i.e., AllSPFRouters or AllDRouters), it needs to
select a key according to the following requirements:
<list style="symbols">
<t>The Peers field is unused. OSPF authentication is interface based.</t>
<t>The Interfaces field includes the local IP address of the interface
for numbered interfaces or the MIB-II <xref target="RFC1213"/> ifIndex
for unnumbered interfaces.</t>
<t>The Direction field is either "out" or "both".</t>
<t>If multiple keys match the Interfaces field, the key with the most recent
SendLifetimeStart time will be selected. This will facilitate graceful
key rollover.</t>
<t>The Key ID field in the OSPFv2 header (refer to figure 1) will be set
to the selected key's LocalKeyName.</t>
</list></t>
</section>
<section title="Key Selection for OSPF Packet Reception ">
<t>When Cryptographic Authentication is used, the ID of the
authentication key is included in the authentication field of the OSPF
packet header. Using this Key ID, it is straight forward for a receiver to
locate the corresponding key. The simple requirements are:
<list style="symbols">
<t>The interface on which the key was received is associated with the
key's interface.</t>
<t>The Key ID obtained from the OSPFv2 packet header corresponds to the
neighbor's PeerKeyName. Since OSPFv2 keys are symmetric, the LocalKeyName
and PeerKeyName for OSPFv2 keys will be identical. Hence, the Key ID will
be used to select the correct local key.</t>
<t>The Direction field is either "in" or "both".</t>
</list></t>
</section>
</section>
<section title="Securing the IP header">
<t>This document updates the definition of the Apad constant,
as it is defined in <xref target="RFC5709"/>, to include the IP
source address from the IP header of the OSPFv2 protocol packet.
The overall cryptographic authentication process defined in <xref
target="RFC5709"/> remains unchanged. To reduce the potential for
confusion, this section minimizes the repetition of text from RFC 5709
<xref target="RFC5709"/>. The changes are:</t>
<t>RFC 5709, Section 3.3, describes how the cryptographic authentication
must be computed. In RFC 5709, the First-Hash includes the OSPF packet
and Authentication Trailer. With this specification, the 64-bit sequence
number will be included in the First-Hash along with the Authentication
Trailer and OSPF packet.</t>
<t> RFC 5709, Section 3.3 also requires the OSPFv2 packet's Authentication Trailer
(which is the appendage described in RFC 2328, Section D.4.3, Page 233,
items (6)(a) and (6)(d)) to be filled with the value Apad. Apad is
a hexadecimal constant with the value 0x878FE1F3 repeated (L/4) times,
where L is the length of the hash being used and is measured in octets
rather than bits.</t>
<t>OSPF routers sending OSPF packets must initialize Apad to the value
of the IP source address
that would be used when sending an OSPFv2 packet, repeated L/4
times, where L is the length of the hash, measured in octets. The basic
idea is to incorporate the IP source address from the IP header in the
cryptographic authentication computation so that any change of IP source
address in a replayed packet can be detected.</t>
<t>When an OSPF packet is received, implementations MUST initialize Apad
as the IP source address from the IP Header of the incoming OSPFv2 packet,
repeated L/4 times, instead of the constant that's
currently defined in <xref target="RFC5709"/>. Besides changing the
value of Apad, this document does not introduce any other changes to the
authentication mechanism described in <xref target="RFC5709"/>.
This would prevent all attacks where a rogue OSPF router changes the
IP source address of an OSPFv2 packet and replays it on the same multi-access
interface or another interface since the IP source address is now included
in the cryptographic hash computation
and modification would result in the OSPFv2 packet being dropped due to an
authentication failure.
</t>
</section>
<section anchor="Cross" title="Mitigating Cross-Protocol Attacks">
<t>In order to prevent cross-protocol replay attacks for protocols sharing common
keys, the two octet OSPFv2 Cryptographic Protocol ID is appended to the authentication key
prior to use. Refer to <xref target="IANA">IANA Considerations</xref>.
</t>
<t> <xref target="RFC5709"/>, Section 3.3 describes the mechanism to prepare the
key used in the hash computation. This document updates the sub section "PREPARATION OF KEY"
as follows:
</t>
<t>The OSPFv2 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 <xref target="RFC2104"/> supports a key that is up to B
octets long, this application uses L as the Ks length consistent
with <xref target="RFC4822"/>, <xref target="RFC5310"/>, and <xref target="RFC5709"/>.
According to
<xref target="FIPS-198"></xref>, Section 3, keys greater than L octets do not
significantly increase the function strength. Ks is computed as
follows: <vspace blankLines="1" />
If the Protocol-Specific Authentication Key (Ks) is L octets
long, then Ko is equal to Ks. If the Protocol-Specific
Authentication Key (Ks) is more than L octets long, then Ko is
set to H(Ks). If the Protocol-Specific Authentication Key
(Ks) is less than L octets long, then Ko is set to the
Protocol-Specific Authentication Key (Ks) with zeros appended
to the end of the Protocol-Specific Authentication Key (Ks)
such that Ko is L octets long.
</t>
<t> Once the cryptographic key (Ko) used with the hash algorithm is
derived the rest of the authentication mechanism described in
<xref target="RFC5709"/> remains unchanged other than one detail that
was unspecified. When XORing Ko and Ipad of Opad, Ko MUST
be padded with zeros to the length of Ipad or Opad. It is expected
that RFC 5709 <xref target="RFC5709"/> implementations perform this
padding implicitly.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document rectifies the manual key management procedure
that currently exists within OSPFv2, as part of the Phase 1 of the KARP
Working Group. Therefore, only the OSPFv2 manual key management
mechanism is considered. Any solution that takes advantage of
the automatic key management mechanism is beyond the scope of this
document.</t>
<t>The proposed sequence number extension offers most of the benefits
of more complicated mechanisms without their attendant challenges.
There are, however,
a couple drawbacks to this approach. First, it requires the OSPF
implementation to be able to save its boot count in
non-volatile storage. If the non-volatile storage is ever repaired
or upgraded such that the contents are lost or the OSPFv2 router is
replaced, the authentication keys MUST be changed to prevent replay
attacks.</t>
<t>Second, if a router is taken out of service completely (either
intentionally or due to a persistent failure), the potential exists for
reestablishment of an OSPFv2 adjacency by replaying the entire OSPFv2
session establishment. However, this scenario is extremely
unlikely, since it would imply an identical OSPFv2 adjacency formation
packet exchange. Without adjacency formation, the replay of OSPFv2 hello
packets alone for an OSPFv2 router that has been taken out of service
should not result in any serious attack as the only consequence is
superfluous processing.
Of course, this attack could also be thwarted by changing the
relevant manual keys.</t>
<t>This document also provides a solution to prevent certain denial of
service attacks that can be launched by changing the source address in
the IP header of an OSPFv2 protocol packet.</t>
<t> Using a single crypto sequence number can leave the router vulnerable
to a replay attack where it uses the same source IP address on two different point-to-point
unnumbered links. In such environments where an attacker can actively tap the point-to-point links, its
recommended that the user employes different keys on each of those unnumbered IP interfaces.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document requests a new code point from the
"OSPF Shortest Path First (OSPF) Authentication Codes" registry:
<list style="symbols">
<t>3 - Cryptographic Authentication with Extended Sequence Numbers.</t>
</list>
</t>
<t>This document also requests a new code point from the
"Authentication Cryptographic Protocol ID" registry defined
under "Keying and Authentication for Routing Protocols (KARP) Parameters":
<list style="symbols">
<t>2 - OSPFv2.</t>
</list>
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.2328'?>
<?rfc include='reference.RFC.5709'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.1213'?>
<?rfc include='reference.RFC.2104'?>
<?rfc include='reference.RFC.4822'?>
<?rfc include='reference.RFC.5310'?>
<?rfc include='reference.RFC.3414'?>
<?rfc include='reference.RFC.4222'?>
<?rfc include='reference.RFC.6039'?>
<?rfc include='reference.RFC.6094'?>
<?rfc include='reference.RFC.6862'?>
<?rfc include='reference.RFC.6863'?>
<?rfc include='reference.I-D.ietf-karp-crypto-key-table'?>
<reference anchor="FIPS-198">
<front>
<title> The Keyed-Hash Message Authentication Code (HMAC)</title>
<author initials="" surname="US National Institute of Standards & Technology">
<organization>Unknown</organization>
</author>
<date month="March" year="2002" />
</front>
<seriesInfo name="FIPS PUB 198" value="" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 23:29:33 |