< draft-ietf-ospf-security-extension-manual-keying-04.txt		draft-ietf-ospf-security-extension-manual-keying-05.txt >
	OSPF Working Group M. Bhatia		OSPF Working Group M. Bhatia
	Internet-Draft Alcatel-Lucent		Internet-Draft Alcatel-Lucent
	Intended status: Standards Track S. Hartman		Intended status: Standards Track S. Hartman
	Expires: August 26, 2013 Painless Security		Expires: November 28, 2013 Painless Security
	D. Zhang		D. Zhang
	Huawei Technologies co., LTD.		Huawei Technologies co., LTD.
	A. Lindem		A. Lindem
	Ericsson		Ericsson
	February 22, 2013		May 27, 2013
	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-04		draft-ietf-ospf-security-extension-manual-keying-05
	Abstract		Abstract
	The current OSPFv2 cryptographic authentication mechanism as defined		The current OSPFv2 cryptographic authentication mechanism as defined
	in the OSPF standards is vulnerable to both inter-session and intra-		in the OSPF standards is vulnerable to both inter-session and intra-
	session replay attacks when its uses manual keying. Additionally,		session replay attacks when its uses manual keying. Additionally,
	the existing cryptographic authentication schemes do not cover the IP		the existing cryptographic authentication schemes do not cover the IP
	header. This omission can be exploited to carry out various types of		header. This omission can be exploited to carry out various types of
	attacks.		attacks.
	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 August 26, 2013.		This Internet-Draft will expire on November 28, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Requirements Section . . . . . . . . . . . . . . . . . . . 4		1.1. Requirements Section . . . . . . . . . . . . . . . . . . . 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 . . . 7		4.2. Key Selection for Multicast OSPF Packet Transmission . . . 7
	4.3. Key Selection for OSPF Packet Reception . . . . . . . . . 8		4.3. Key Selection for OSPF Packet Reception . . . . . . . . . 8
	5. Mechanism to secure the IP header . . . . . . . . . . . . . . 8		5. Securing the IP header . . . . . . . . . . . . . . . . . . . . 8
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 9		6. Mitigating Cross-Protocol Attacks . . . . . . . . . . . . . . 9
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 10		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	8.2. Informative References . . . . . . . . . . . . . . . . . . 10		9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11		9.2. Informative References . . . . . . . . . . . . . . . . . . 11
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
	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 the attempts to replay the stale packets can be thwarted.		so that the attempts to replay the stale packets can be thwarted.
	The sequence number values are maintained as a part of adjacency		The sequence number values are maintained as a part of adjacency
	states. Therefore, if an adjacency is broken down, the associated		states. Therefore, if an adjacency is broken down, the associated
	sequence numbers get reinitialized and the neighbors start all over		sequence numbers get reinitialized and the neighbors start all over
	again. Additionally, the cryptographic authentication mechanism does		again. Additionally, the cryptographic authentication mechanism does
	not specify how to deal with the rollover of a sequence number when		not specify how to deal with the rollover of a sequence number when
	its value would wrap. These omissions can be taken advantage of by		its value would wrap. These omissions can be taken advantage of by
	attackers to implement various replay attacks ([RFC6039]). In order		attackers to implement various replay attacks ([RFC6039]). In order
	to address these issues, we propose extensions to the authentication		to address these issues, we propose extensions to the authentication
	skipping to change at page 3, line 38 ¶		skipping to change at page 3, line 38 ¶
	the implementations to look at the source address in the IP header to		the implementations to look at the source address in the IP header to
	determine the neighbor from witch the packet was received. Changing		determine the neighbor from witch the packet was received. Changing
	the IP source address of a packet which can confuse the receiver and		the IP source address of a packet which can confuse the receiver and
	can be exploited to produce a number of denial of service attacks		can be exploited to produce a number of denial of service attacks
	[RFC6039]. If the packet is interpreted as coming from a different		[RFC6039]. If the packet is interpreted as coming from a different
	neighbor, the sequence number received from the neighbor may be		neighbor, the sequence number received from the neighbor may be
	updated. This may disrupt communication with the legitimate		updated. This may disrupt communication with the legitimate
	neighbor. Hello packets may be reflected to cause a neighbor to		neighbor. Hello packets may be reflected to cause a neighbor to
	appear to have one-way communication. Old Database descriptions may		appear to have one-way communication. Old Database descriptions may
	be reflected in cases where the per-packet sequence numbers are		be reflected in cases where the per-packet sequence numbers are
	sufficiently divergent in order to disrupt an adjacency		sufficiently divergent in order to disrupt an adjacency [RFC6863].
	[I-D.ietf-karp-ospf-analysis]. This is referred to as the IP layer		This is referred to as the IP layer issue in [RFC6862].
	issue in [I-D.ietf-karp-threats-reqs].
	[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] in future		of the stronger algorithms described in [RFC5709] in future
	deployments [RFC6094].		deployments [RFC6094].
	This draft proposes a simple change in the cryptographic		This draft proposes 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
			Thanks to Ran Atkinson for help in the analysis of RFC 6506 errata
			leading to clarifications in this document.
	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
	skipping to change at page 8, line 24 ¶		skipping to change at page 8, line 24 ¶
	o The interface on which the key was received is associated with the		o The interface on which the key was received is associated with the
	key's interface.		key's interface.
	o The PeerKeyName field includes the key ID obtained from the		o The PeerKeyName field includes the key ID obtained from the
	authentication field. Since OSPF keys are symmetric, the		authentication field. Since OSPF keys are symmetric, the
	LocalKeyName and PeerKeyName for OSPF keys will be identical.		LocalKeyName and PeerKeyName for OSPF keys will be identical.
	o The Direction field is either "in" or "both".		o The Direction field is either "in" or "both".
	5. Mechanism to secure the IP header		5. Securing the IP header
	This document updates the definition of Apad which is currently a		This document updates the definition of Apad which is currently a
	constant defined in [RFC5709] to the source address from the IP		constant defined in [RFC5709] to the source address from the IP
	header of the OSPFv2 protocol packet. The overall cryptographic		header of the OSPFv2 protocol packet. The overall cryptographic
	authentication process defined in [RFC5709] remains unchanged. To		authentication process defined in [RFC5709] remains unchanged. To
	reduce the potential for confusion, this section minimizes the		reduce the potential for confusion, this section minimizes the
	repetition of text from RFC 5709 and is incorporated here by		repetition of text from RFC 5709 and is incorporated here by
	reference [RFC5709].		reference [RFC5709].
	RFC 5709, Section 3.3, describes how the cryptographic authentication		RFC 5709, Section 3.3, describes how the cryptographic authentication
	skipping to change at page 9, line 14 ¶		skipping to change at page 9, line 14 ¶
	L/4 times, instead of the constant that's currently defined in		L/4 times, instead of the constant that's currently defined in
	[RFC5709]. Besides changing the value of Apad, this document does		[RFC5709]. Besides changing the value of Apad, this document does
	not introduce any other changes to the authentication mechanism		not introduce any other changes to the authentication mechanism
	described in [RFC5709]. This would prevent all attacks where a rogue		described in [RFC5709]. This would prevent all attacks where a rogue
	OSPF router changes the IP source address of an OSPFv2 packet and		OSPF router changes the IP source address of an OSPFv2 packet and
	replays it on the same multi-access interface or another interface		replays it on the same multi-access interface or another interface
	since the IP source address is now protected and such changes would		since the IP source address is now protected and such changes would
	cause the authentication check to fail and the replayed packet to be		cause the authentication check to fail and the replayed packet to be
	rejected.		rejected.
	6. Security Considerations		6. Mitigating Cross-Protocol Attacks
			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 IANA
			Considerations (Section 8).
			[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:
			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
			[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], Section 3, keys
			greater than L octets do not significantly increase the function
			strength. Ks is computed as follows:
			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.
			Once the cryptographic key (Ko) used with the hash algorithm is
			derived the rest of the authentication mechanism described in
			[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
			[RFC5709] implementation perform this padding implicitly.
			7. Security Considerations
	This document attempts to fix the manual key management procedure		This document attempts to fix the manual key management procedure
	that currently exists within OSPFv2, as part of the Phase 1 of the		that currently exists within OSPFv2, as part of the Phase 1 of the
	KARP Working Group. Therefore, only the OSPFv2 manual key management		KARP 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 proposed sequence number extension offers most of the benefits of
	of more complicated mechanisms involving challenges. There are,		of more complicated mechanisms involving challenges. There are,
	skipping to change at page 9, line 46 ¶		skipping to change at page 10, line 37 ¶
	formation packet exchange. The replay of OSPFv2 hello packets alone		formation packet exchange. The replay of OSPFv2 hello packets alone
	for an OSPFv2 router that has been taken out of service should not		for an OSPFv2 router that has been taken out of service should not
	result in any serious attack as the only consequence is superfluous		result in any serious attack as the only consequence is superfluous
	processing. Of course, this attack could also be thwarted by		processing. Of course, this attack could also be thwarted by
	changing the relevant manual keys.		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 the OSPFv2 protocol packet.		in the IP header of the OSPFv2 protocol packet.
	7. IANA Considerations		8. 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 TBD - Cryptographic Authentication with Extended Sequence Numbers.		o 3 - Cryptographic Authentication with Extended Sequence Numbers.
	The value 3 is recommended.
	8. References		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":
	8.1. Normative References		o 2 - OSPFv2.
	[I-D.ietf-karp-crypto-key-table]		9. References
	Housley, R., Polk, T., Hartman, S., and D. Zhang,		9.1. Normative References
	"Database of Long-Lived Symmetric Cryptographic Keys",
	draft-ietf-karp-crypto-key-table-06 (work in progress),
	February 2013.
	[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.
	8.2. Informative References		9.2. Informative References
	[I-D.ietf-karp-ospf-analysis]		[FIPS-198]
	Hartman, S. and D. Zhang, "Analysis of OSPF Security		US National Institute of Standards & Technology, "The
	According to KARP Design Guide",		Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB
	draft-ietf-karp-ospf-analysis-06 (work in progress),		198 , March 2002.
	May 2013.
	[I-D.ietf-karp-threats-reqs]		[I-D.ietf-karp-crypto-key-table]
	Lebovitz, G., Bhatia, M., and B. Weis, "The Threat		Housley, R., Polk, T., Hartman, S., and D. Zhang,
	Analysis and Requirements for Cryptographic Authentication		"Database of Long-Lived Symmetric Cryptographic Keys",
	of Routing Protocols' Transports",		draft-ietf-karp-crypto-key-table-07 (work in progress),
	draft-ietf-karp-threats-reqs-07 (work in progress),		March 2013.
	December 2012.
	[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-
			Hashing for Message Authentication", RFC 2104,
			February 1997.
	[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model		[RFC3414] 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)", STD 62, RFC 3414, December 2002.
	[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
			Authentication", RFC 4822, February 2007.
			[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
			and M. Fanto, "IS-IS Generic Cryptographic
			Authentication", RFC 5310, February 2009.
	[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.
			[RFC6862] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and
			Authentication for Routing Protocols (KARP) Overview,
			Threats, and Requirements", RFC 6862, March 2013.
			[RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security
			According to the Keying and Authentication for Routing
			Protocols (KARP) Design Guide", RFC 6863, March 2013.
	Authors' Addresses		Authors' Addresses
	Manav Bhatia		Manav Bhatia
	Alcatel-Lucent		Alcatel-Lucent
	Bangalore,		Bangalore,
	India		India
	Phone:		Phone:
	Email: manav.bhatia@alcatel-lucent.com		Email: manav.bhatia@alcatel-lucent.com
End of changes. 23 change blocks.
	40 lines changed or deleted		96 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/