draft-ietf-ospf-security-extension-manual-keying-10.txt   draft-ietf-ospf-security-extension-manual-keying-11.txt 
OSPF Working Group M. Bhatia OSPF Working Group M. Bhatia
Internet-Draft Ionos Networks Internet-Draft Ionos Networks
Intended status: Standards Track S. Hartman Updates: 2328, 5709 S. Hartman
Expires: April 29, 2015 Painless Security (if approved) Painless Security
D. Zhang Intended status: Standards Track D. Zhang
Huawei Technologies co., LTD. Expires: May 11, 2015 Huawei Technologies co., LTD.
A. Lindem, Ed. A. Lindem, Ed.
Cisco Cisco
October 26, 2014 November 7, 2014
Security Extension for OSPFv2 when using Manual Key Management Security Extension for OSPFv2 when using Manual Key Management
draft-ietf-ospf-security-extension-manual-keying-10 draft-ietf-ospf-security-extension-manual-keying-11
Abstract Abstract
The current OSPFv2 cryptographic authentication mechanism as defined The current OSPFv2 cryptographic authentication mechanism as defined
in RFC 2328 and RFC 5709 is vulnerable to both inter-session and in RFC 2328 and RFC 5709 is vulnerable to both inter-session and
intra-session replay attacks when using manual keying. Additionally, intra-session replay attacks when using manual keying. Additionally,
the existing cryptographic authentication mechanism does not cover the existing cryptographic authentication mechanism does not cover
the IP header. This omission can be exploited to carry out various the IP header. This omission can be exploited to carry out various
types of attacks. types of attacks.
This draft proposes changes to the authentication sequence number This document defines changes to the authentication sequence number
mechanism that will protect OSPFv2 from both inter-session and intra- mechanism that will protect OSPFv2 from both inter-session and intra-
session replay attacks when using manual keys for securing OSPFv2 session replay attacks when using manual keys for securing OSPFv2
protocol packets. Additionally, we also describe some changes in the protocol packets. Additionally, we also describe some changes in the
cryptographic hash computation that will eliminate attacks resulting cryptographic hash computation that will eliminate attacks resulting
from OSPFv2 not protecting the IP header. from OSPFv2 not protecting the IP header.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 29, 2015. This Internet-Draft will expire on May 11, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 2, line 29 skipping to change at page 2, line 29
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Section . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Section . . . . . . . . . . . . . . . . . . . 3
1.2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 4 1.2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 4
2. Replay Protection using Extended Sequence Numbers . . . . . . 4 2. Replay Protection using Extended Sequence Numbers . . . . . . 4
3. OSPF Packet Extensions . . . . . . . . . . . . . . . . . . . . 5 3. OSPF Packet Extensions . . . . . . . . . . . . . . . . . . . . 5
4. OSPF Packet Key Selection . . . . . . . . . . . . . . . . . . 6 4. OSPF Packet Key Selection . . . . . . . . . . . . . . . . . . 6
4.1. Key Selection for Unicast OSPF Packet Transmission . . . . 7 4.1. Key Selection for Unicast OSPF Packet Transmission . . . . 7
4.2. Key Selection for Multicast OSPF Packet Transmission . . . 8 4.2. Key Selection for Multicast OSPF Packet Transmission . . . 8
4.3. Key Selection for OSPF Packet Reception . . . . . . . . . 8 4.3. Key Selection for OSPF Packet Reception . . . . . . . . . 8
5. Securing the IP header . . . . . . . . . . . . . . . . . . . . 9 5. Securing the IP header . . . . . . . . . . . . . . . . . . . . 9
6. Mitigating Cross-Protocol Attacks . . . . . . . . . . . . . . 10 6. Mitigating Cross-Protocol Attacks . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
The OSPFv2 cryptographic authentication mechanism as described in The OSPFv2 cryptographic authentication mechanism as described in
[RFC2328] uses per-packet sequence numbers to provide protection [RFC2328] uses per-packet sequence numbers to provide protection
against replay attacks. The sequence numbers increase monotonically against replay attacks. The sequence numbers increase monotonically
so that attempts to replay stale packets can be thwarted. The so that attempts to replay stale packets can be thwarted. The
sequence number values are maintained as a part of neighbor adjacency sequence number values are maintained as a part of neighbor adjacency
state. Therefore, if an adjacency is taken down, the associated state. Therefore, if an adjacency is taken down, the associated
sequence numbers get reinitialized and neighbor adjacency formation sequence numbers get reinitialized and neighbor adjacency formation
starts over again. Additionally, the cryptographic authentication starts over again. Additionally, the cryptographic authentication
mechanism does not specify how to deal with the rollover of a mechanism does not specify how to deal with the rollover of a
sequence number when its value wraps. These omissions can be sequence number when its value wraps. These omissions can be
exploited by attackers to implement various replay attacks exploited by attackers to implement various replay attacks
([RFC6039]). In order to address these issues, we propose extensions ([RFC6039]). In order to address these issues, we define extensions
to the authentication sequence number mechanism. to the authentication sequence number mechanism.
The cryptographic authentication as described in [RFC2328] and later The cryptographic authentication as described in [RFC2328] and later
updated in [RFC5709] does not include the IP header. This omission updated in [RFC5709] does not include the IP header. This omission
can be exploited to launch several attacks as the source address in can be exploited to launch several attacks as the source address in
the IP header is not protected. The OSPF specification, for the IP header is not protected. The OSPF specification, for
broadcast and NBMA (Non-Broadcast Multi-Access Networks), requires broadcast and NBMA (Non-Broadcast Multi-Access Networks), requires
implementations to use the source address in the IP header to implementations to use the source address in the IP header to
determine the neighbor from which the packet was received. Changing determine the neighbor from which the packet was received. Changing
the IP source address of a packet to a conflicting IP address can be the IP source address of a packet to a conflicting IP address can be
skipping to change at page 3, line 45 skipping to change at page 3, line 45
Description packets may be reflected in cases where the per-packet Description packets may be reflected in cases where the per-packet
sequence numbers are sufficiently divergent in order to disrupt an sequence numbers are sufficiently divergent in order to disrupt an
adjacency [RFC6863]. This is referred to as the IP layer issue in adjacency [RFC6863]. This is referred to as the IP layer issue in
[RFC6862]. [RFC6862].
[RFC2328] states that implementations MUST offer keyed MD5 [RFC2328] states that implementations MUST offer keyed MD5
authentication. It is likely that this will be deprecated in favor authentication. It is likely that this will be deprecated in favor
of the stronger algorithms described in [RFC5709] and required in of the stronger algorithms described in [RFC5709] and required in
[RFC6094]. [RFC6094].
This draft proposes a few simple changes to the cryptographic This document defines a few simple changes to the cryptographic
authentication mechanism, as currently described in [RFC5709], to authentication mechanism, as currently described in [RFC5709], to
prevent such IP layer attacks. prevent such IP layer attacks.
1.1. Requirements Section 1.1. Requirements Section
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119]. document are to be interpreted as described in RFC2119 [RFC2119].
When used in lowercase, these words convey their typical use in When used in lowercase, these words convey their typical use in
common language, and are not to be interpreted as described in common language, and are not to be interpreted as described in
RFC2119 [RFC2119]. RFC2119 [RFC2119].
1.2. Acknowledgments 1.2. Acknowledgments
Thanks to Ran Atkinson for help in the analysis of RFC 6506 errata Thanks to Ran Atkinson for help in the analysis of RFC 6506 errata
leading to clarifications in this document. Thanks to Gabi Nakibly leading to clarifications in this document.
for pointing out the possible attack on p2p links.
Thanks to Gabi Nakibly for pointing out a possible attack on p2p
links.
Thanks to Suresh Krishnan for comments made during the Gen-Art
review. In particular, thanks for pointing out an ambiguity in the
initialization of Apad.
Thanks to Shaun Cooley for the security directorate review.
Thanks to Adrian Farrel for comments during the IESG last call.
2. Replay Protection using Extended Sequence Numbers 2. Replay Protection using Extended Sequence Numbers
In order to provide replay protection against both inter-session and In order to provide replay protection against both inter-session and
intra-session replay attacks, the OSPFv2 sequence number is expanded intra-session replay attacks, the OSPFv2 sequence number is expanded
to 64-bits with the least significant 32-bit value containing a to 64-bits with the least significant 32-bit value containing a
strictly increasing sequence number and the most significant 32-bit strictly increasing sequence number and the most significant 32-bit
value containing the boot count. OSPFv2 implementations are required value containing the boot count. OSPFv2 implementations are required
to retain the boot count in non-volatile storage for the deployment to retain the boot count in non-volatile storage for the deployment
life the OSPF router. The requirement to preserve the boot count is life the OSPF router. The requirement to preserve the boot count is
also placed on SNMP agents by the SNMPv3 security architecture (refer also placed on SNMP agents by the SNMPv3 security architecture (refer
to snmpEngineBoots in [RFC4222]). to snmpEngineBoots in section 2.2 of [RFC2574]).
Since there is no room in the OSPFv2 packet for a 64-bit sequence 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 number, it will occupy the 8 octets following the OSPFv2 packet and
MUST be included when calculating the OSPFv2 packet digest. These MUST be included when calculating the OSPFv2 packet digest. These
additional 8 bytes are not included in the OSPFv2 packet header additional 8 octets are not included in the OSPFv2 packet header
length but are included in the OSPFv2 header Authentication Data length but are included in the OSPFv2 header Authentication Data
length and the IPv4 packet header length. length and the IPv4 packet header length.
The lower order 32-bit sequence number MUST be incremented for every The lower order 32-bit sequence number MUST be incremented for every
OSPF packet sent by the OSPF router. Upon reception, the sequence OSPF packet sent by the OSPF router. Upon reception, the sequence
number MUST be greater than the sequence number in the last OSPF number MUST be greater than the sequence number in the last OSPF
packet of that type accepted from the sending OSPF neighbor. packet of that type accepted from the sending OSPF neighbor.
Otherwise, the OSPF packet is considered a replayed packet and Otherwise, the OSPF packet is considered a replayed packet and
dropped. OSPF packets of different types may arrive out of order if dropped. OSPF packets of different types may arrive out of order if
they are prioritized as recommended in [RFC3414]. they are prioritized as recommended in [RFC4222].
OSPF routers implementing this specification MUST use available OSPF routers implementing this specification MUST use available
mechanisms to preserve the sequence number's strictly increasing mechanisms to preserve the sequence number's strictly increasing
property for the deployed life of the OSPFv3 router (including cold property for the deployed life of the OSPFv2 router (including cold
restarts). This is achieved by maintaining a boot count in non- restarts). This is achieved by maintaining a boot count in non-
volatile storage and incrementing it each time the OSPF router loses volatile storage and incrementing it each time the OSPF router loses
its prior sequence number state. The SNMPv3 snmpEngineBoots variable its prior sequence number state. The SNMPv3 snmpEngineBoots variable
[RFC4222] MAY be used for this purpose. However, maintaining a [RFC2574] MAY be used for this purpose. However, maintaining a
separate boot count solely for OSPF sequence numbers has the separate boot count solely for OSPF sequence numbers has the
advantage of decoupling SNMP reinitialization and OSPF advantage of decoupling SNMP reinitialization and OSPF
reinitialization. Also, in the rare event that the lower order 32- reinitialization. Also, in the rare event that the lower order 32-
bit sequence number wraps, the boot count can be incremented to bit sequence number wraps, the boot count can be incremented to
preserve the strictly increasing property of the aggregate sequence preserve the strictly increasing property of the aggregate sequence
number. Hence, a separate OSPF boot count is RECOMMENDED. number. Hence, a separate OSPF boot count is RECOMMENDED.
3. OSPF Packet Extensions 3. OSPF Packet Extensions
The OSPF packet header includes an authentication type field, and 64- The OSPF packet header includes an authentication type field, and 64-
bits of data for use by the appropriate authentication scheme bits of data for use by the appropriate authentication scheme
(determined by the type field). Authentication types 0, 1 and 2 are (determined by the type field). Authentication types 0, 1 and 2 are
defined [RFC2328]. This section of this defines Authentication type defined [RFC2328]. This section defines Authentication type TBD (3
TBD (3 is recommended). is recommended).
When using this authentication scheme, the 64-bit Authentication When using this authentication scheme, the 64-bit Authentication
field in the OSPF packet header as defined in section D.3 of field in the OSPF packet header as defined in section D.3 of
[RFC2328] is changed as shown below. The sequence number is removed [RFC2328] and [RFC6549] is changed as shown below. The sequence
and the Key ID is extended to 32 bits and moved to the former number is removed and the Key ID is extended to 32 bits and moved to
position of the sequence number. the former position of the sequence number.
Additionally, the 64-bit sequence number is moved to the first 64- Additionally, the 64-bit sequence number is moved to the first 64-
bits following the OSPFv2 packet and is protected by the bits following the OSPFv2 packet and is protected by the
authentication digest. These additional 64 bits or 8 octets are authentication digest. These additional 64 bits or 8 octets are
included in the IP header length but not the OSPF header packet included in the IP header length but not the OSPF header packet
length. length.
Finally, the 0 field at the start of the OSPFv2 header authentication
is extended from 16 bits to 24 bits.
0 1 2 3 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 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 | | Version # | Type | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID | | Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID | | Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType | | Checksum | Instance ID | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Auth Data Len | | 0 | Auth Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID | | Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| OSPF Protocol Packet | | OSPF Protocol Packet |
~ ~ ~ ~
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (Boot Count) | | Sequence Number (Boot Count) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (Strictly Increasing Packet Counter) | | Sequence Number (Strictly Increasing Packet Counter) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Authentication Data ~ ~ Authentication Data ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - Extended Sequence Number Packet Extensions Figure 1 - Extended Sequence Number Packet Extensions
4. OSPF Packet Key Selection 4. OSPF Packet Key Selection
This section describes how the proposed security solution selects This section describes how this security solution selects long-lived
long-lived keys from key tables. [RFC7210]. In this context, we are keys from key tables. [RFC7210]. In this context, we are selecting
selecting the key and corresponding Security Association (SA) as the key and corresponding Security Association (SA) as defined in
defined in section 3.2 of [RFC5709]. Generally, a key used for section 3.2 of [RFC5709]. Generally, a key used for OSPFv2 packet
OSPFv2 packet authentication should satisfy the following authentication should satisfy the following requirements:
requirements:
o For packet transmission, the key validity interval as defined by o For packet transmission, the key validity interval as defined by
SendLifetimeStart and SendLifetimeEnd must include the current SendLifetimeStart and SendLifetimeEnd must include the current
time. time.
o For packet reception, the key validity interval as defined by o For packet reception, the key validity interval as defined by
AcceptLifetimeStart and AcceptLifetimeEnd must include the current AcceptLifetimeStart and AcceptLifetimeEnd must include the current
time. time.
o The key must be valid for the desired security algorithm. o The key must be valid for the desired security algorithm.
skipping to change at page 9, line 29 skipping to change at page 9, line 27
bit sequence number will be included in the First-Hash along with the bit sequence number will be included in the First-Hash along with the
Authentication Trailer and OSPF packet. Authentication Trailer and OSPF packet.
RFC 5709, Section 3.3 also requires the OSPFv2 packet's RFC 5709, Section 3.3 also requires the OSPFv2 packet's
Authentication Trailer (which is the appendage described in RFC 2328, 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 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 the value Apad. Apad is a hexadecimal constant with the value
0x878FE1F3 repeated (L/4) times, where L is the length of the hash 0x878FE1F3 repeated (L/4) times, where L is the length of the hash
being used and is measured in octets rather than bits. being used and is measured in octets rather than bits.
OSPF routers sending OSPF packets must initialize Apad to the value OSPF routers sending OSPF packets must initialize the first 4 octets
of the IP source address that would be used when sending an OSPFv2 of Apad to the value of the IP source address that would be used when
packet, repeated L/4 times, where L is the length of the hash, sending the OSPFv2 packet. The remainder of Apad will contain the
measured in octets. The basic idea is to incorporate the IP source value 0x878FE1F3 repeated (L - 4)/4 times, where L is the length of
address from the IP header in the cryptographic authentication the hash, measured in octets. The basic idea is to incorporate the
computation so that any change of IP source address in a replayed IP source address from the IP header in the cryptographic
packet can be detected. authentication computation so that any change of IP source address in
a replayed packet can be detected.
When an OSPF packet is received, implementations MUST initialize Apad When an OSPF packet is received, implementations MUST initialize Apad
as the IP source address from the IP Header of the incoming OSPFv2 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 packet, repeated L/4 times, instead of the constant that's currently
defined in [RFC5709]. Besides changing the value of Apad, this defined in [RFC5709]. Besides changing the value of Apad, this
document does not introduce any other changes to the authentication document does not introduce any other changes to the authentication
mechanism described in [RFC5709]. This would prevent all attacks mechanism described in [RFC5709]. This would prevent all attacks
where a rogue OSPF router changes the IP source address of an OSPFv2 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 packet and replays it on the same multi-access interface or another
interface since the IP source address is now included in the interface since the IP source address is now included in the
cryptographic hash computation and modification would result in the cryptographic hash computation and modification would result in the
OSPFv2 packet being dropped due to an authentication failure. OSPFv2 packet being dropped due to an authentication failure.
6. Mitigating Cross-Protocol Attacks 6. Mitigating Cross-Protocol Attacks
In order to prevent cross-protocol replay attacks for protocols In order to prevent cross-protocol replay attacks for protocols
sharing common keys, the two octet OSPFv2 Cryptographic Protocol ID sharing common keys, the two octet OSPFv2 Cryptographic Protocol ID
is appended to the authentication key prior to use. Refer to IANA is appended to the authentication key prior to use. Refer to IANA
Considerations (Section 8). Considerations (Section 9).
[RFC5709], Section 3.3 describes the mechanism to prepare the key [RFC5709], Section 3.3 describes the mechanism to prepare the key
used in the hash computation. This document updates the sub section used in the hash computation. This document updates the sub section
"PREPARATION OF KEY" as follows: "PREPARATION OF KEY" as follows:
The OSPFv2 Cryptographic Protocol ID is appended to the The OSPFv2 Cryptographic Protocol ID is appended to the
Authentication Key (K) yielding a Protocol-Specific Authentication Authentication Key (K) yielding a Protocol-Specific Authentication
Key (Ks). In this application, Ko is always L octets long. While Key (Ks). In this application, Ko is always L octets long. While
[RFC2104] supports a key that is up to B octets long, this [RFC2104] supports a key that is up to B octets long, this
application uses L as the Ks length consistent with [RFC4822], application uses L as the Ks length consistent with [RFC4822],
skipping to change at page 10, line 40 skipping to change at page 10, line 35
zeros appended to the end of the Protocol-Specific Authentication Key zeros appended to the end of the Protocol-Specific Authentication Key
(Ks) such that Ko is L octets long. (Ks) such that Ko is L octets long.
Once the cryptographic key (Ko) used with the hash algorithm is Once the cryptographic key (Ko) used with the hash algorithm is
derived the rest of the authentication mechanism described in derived the rest of the authentication mechanism described in
[RFC5709] remains unchanged other than one detail that was [RFC5709] remains unchanged other than one detail that was
unspecified. When XORing Ko and Ipad of Opad, Ko MUST be padded with 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 zeros to the length of Ipad or Opad. It is expected that RFC 5709
[RFC5709] implementations perform this padding implicitly. [RFC5709] implementations perform this padding implicitly.
7. Security Considerations 7. Backward Compatibility
This security extension uses a new authentication type, AuType in the
OSPFv2 header (refer to figure 1). When an OSPFv2 packet is received
and the AuType doesn't match the configured authentication type for
the interface, the OSPFv2 packet will be dropped as specified in RFC
2328 [RFC2328]. This guarantees backward compatible behavior
consistent with any other authentication type mismatch.
8. Security Considerations
This document rectifies the manual key management procedure that This document rectifies the manual key management procedure that
currently exists within OSPFv2, as part of the Phase 1 of the KARP currently exists within OSPFv2, as part of the Phase 1 of the KARP
Working Group. Therefore, only the OSPFv2 manual key management Working Group. Therefore, only the OSPFv2 manual key management
mechanism is considered. Any solution that takes advantage of the mechanism is considered. Any solution that takes advantage of the
automatic key management mechanism is beyond the scope of this automatic key management mechanism is beyond the scope of this
document. document.
The proposed sequence number extension offers most of the benefits of The described sequence number extension offers most of the benefits
more complicated mechanisms without their attendant challenges. of more complicated mechanisms without their attendant challenges.
There are, however, a couple drawbacks to this approach. First, it There are, however, a couple drawbacks to this approach. First, it
requires the OSPF implementation to be able to save its boot count in requires the OSPF implementation to be able to save its boot count in
non-volatile storage. If the non-volatile storage is ever repaired non-volatile storage. If the non-volatile storage is ever repaired
or upgraded such that the contents are lost or the OSPFv2 router is or upgraded such that the contents are lost or the OSPFv2 router is
replaced, the authentication keys MUST be changed to prevent replay replaced, the authentication keys MUST be changed to prevent replay
attacks. attacks.
Second, if a router is taken out of service completely (either Second, if a router is taken out of service completely (either
intentionally or due to a persistent failure), the potential exists intentionally or due to a persistent failure), the potential exists
for reestablishment of an OSPFv2 adjacency by replaying the entire for reestablishment of an OSPFv2 adjacency by replaying the entire
skipping to change at page 11, line 29 skipping to change at page 11, line 35
could also be thwarted by changing the relevant manual keys. could also be thwarted by changing the relevant manual keys.
This document also provides a solution to prevent certain denial of This document also provides a solution to prevent certain denial of
service attacks that can be launched by changing the source address service attacks that can be launched by changing the source address
in the IP header of an OSPFv2 protocol packet. in the IP header of an OSPFv2 protocol packet.
Using a single crypto sequence number can leave the router vulnerable 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 to a replay attack where it uses the same source IP address on two
different point-to-point unnumbered links. In such environments different point-to-point unnumbered links. In such environments
where an attacker can actively tap the point-to-point links, its where an attacker can actively tap the point-to-point links, its
recommended that the user employes different keys on each of those recommended that the user employs different keys on each of those
unnumbered IP interfaces. unnumbered IP interfaces.
8. IANA Considerations 9. IANA Considerations
This document requests a new code point from the "OSPF Shortest Path This document requests a new code point from the "OSPF Shortest Path
First (OSPF) Authentication Codes" registry: First (OSPF) Authentication Codes" registry:
o 3 - Cryptographic Authentication with Extended Sequence Numbers. o 3 - Cryptographic Authentication with Extended Sequence Numbers.
This document also requests a new code point from the "Authentication This document also requests a new code point from the "Authentication
Cryptographic Protocol ID" registry defined under "Keying and Cryptographic Protocol ID" registry defined under "Keying and
Authentication for Routing Protocols (KARP) Parameters": Authentication for Routing Protocols (KARP) Parameters":
o TBD (3 Suggested) - OSPFv2. o TBD (3 Suggested) - OSPFv2.
9. References 10. References
9.1. Normative References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M.,
Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic
Authentication", RFC 5709, October 2009. Authentication", RFC 5709, October 2009.
9.2. Informative References 10.2. Informative References
[FIPS-198] [FIPS-198]
US National Institute of Standards & Technology, "The US National Institute of Standards & Technology, "The
Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB
198 , March 2002. 198 , March 2002.
[RFC1213] McCloghrie, K. and M. Rose, "Management Information Base [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base
for Network Management of TCP/IP-based internets:MIB-II", for Network Management of TCP/IP-based internets:MIB-II",
STD 17, RFC 1213, March 1991. STD 17, RFC 1213, March 1991.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
February 1997. February 1997.
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model [RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management (USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. Protocol (SNMPv3)", RFC 2574, April 1999.
[RFC4222] Choudhury, G., "Prioritized Treatment of Specific OSPF [RFC4222] Choudhury, G., "Prioritized Treatment of Specific OSPF
Version 2 Packets and Congestion Avoidance", BCP 112, Version 2 Packets and Congestion Avoidance", BCP 112,
RFC 4222, October 2005. RFC 4222, October 2005.
[RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic [RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic
Authentication", RFC 4822, February 2007. Authentication", RFC 4822, February 2007.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic and M. Fanto, "IS-IS Generic Cryptographic
Authentication", RFC 5310, February 2009. Authentication", RFC 5310, February 2009.
[RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues
with Existing Cryptographic Protection Methods for Routing with Existing Cryptographic Protection Methods for Routing
Protocols", RFC 6039, October 2010. Protocols", RFC 6039, October 2010.
[RFC6094] Bhatia, M. and V. Manral, "Summary of Cryptographic [RFC6094] Bhatia, M. and V. Manral, "Summary of Cryptographic
Authentication Algorithm Implementation Requirements for Authentication Algorithm Implementation Requirements for
Routing Protocols", RFC 6094, February 2011. Routing Protocols", RFC 6094, February 2011.
[RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi-
Instance Extensions", RFC 6549, March 2012.
[RFC6862] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and [RFC6862] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and
Authentication for Routing Protocols (KARP) Overview, Authentication for Routing Protocols (KARP) Overview,
Threats, and Requirements", RFC 6862, March 2013. Threats, and Requirements", RFC 6862, March 2013.
[RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security [RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security
According to the Keying and Authentication for Routing According to the Keying and Authentication for Routing
Protocols (KARP) Design Guide", RFC 6863, March 2013. Protocols (KARP) Design Guide", RFC 6863, March 2013.
[RFC7210] Housley, R., Polk, T., Hartman, S., and D. Zhang, [RFC7210] Housley, R., Polk, T., Hartman, S., and D. Zhang,
"Database of Long-Lived Symmetric Cryptographic Keys", "Database of Long-Lived Symmetric Cryptographic Keys",
RFC 7210, April 2014. RFC 7210, April 2014.
Authors' Addresses Authors' Addresses
Manav Bhatia Manav Bhatia
Ionos Networks Ionos Networks
Bangalore, Bangalore,
India India
Phone:
Email: manav@ionosnetworks.com Email: manav@ionosnetworks.com
Sam Hartman Sam Hartman
Painless Security Painless Security
Email: hartmans@painless-security.com Email: hartmans@painless-security.com
Dacheng Zhang Dacheng Zhang
Huawei Technologies co., LTD. Huawei Technologies co., LTD.
Beijing, Beijing,
China China
Phone:
Fax:
Email: zhangdacheng@huawei.com Email: zhangdacheng@huawei.com
URI: URI:
Acee Lindem (editor) Acee Lindem (editor)
Cisco Cisco
USA USA
Phone:
Email: acee@cisco.com Email: acee@cisco.com
 End of changes. 34 change blocks. 
58 lines changed or deleted 81 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/