< draft-bhatia-manral-auth-trailer-ospfv3-00.txt		draft-bhatia-manral-auth-trailer-ospfv3-01.txt >
	KARP Working Group Manav Bhatia		OSPF Working Group M. Bhatia
	Internet Draft Alcatel-Lucent		Internet-Draft Alcatel-Lucent
	Intended status: Standards Track Vishwas Manral		Intended status: Standards Track V. Manral
	Expires: March, 2011 IP Infusion		Expires: April 18, 2011 IP Infusion
	September 2010		A. Lindem
			Ericsson
			October 15, 2010
	Supporting Authentication Trailer for OSPFv3		Supporting Authentication Trailer for OSPFv3
			draft-bhatia-manral-auth-trailer-ospfv3-01
	draft-bhatia-manral-auth-trailer-ospfv3-00.txt		Abstract
	Status of this Memo		Currently OSPFv3 uses IPsec for authenticating protocol packets.
			However, there are some environments, e.g., Mobile Ad-hoc Networks
			(MANETs), where IPsec is difficult to configure and maintain, and
			this mechanism cannot be used. This draft proposes an alternative
			mechanism that can be used so that OSPFv3 does not depend upon IPsec
			for authentication.
	This Internet-Draft is submitted to IETF in full conformance		Status of this Memo
	with the provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet		This Internet-Draft is submitted in full conformance with the
	Engineering Task Force (IETF), its areas, and its working		provisions of BCP 78 and BCP 79.
	groups. Note that other groups may also distribute working
	documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are working documents of the Internet Engineering
	months and may be updated, replaced, or obsoleted by other		Task Force (IETF). Note that other groups may also distribute
	documents at any time. It is inappropriate to use Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts as reference material or to cite them other than as "work		Drafts is at http://datatracker.ietf.org/drafts/current/.
	in progress."
	The list of current Internet-Drafts can be accessed at		Internet-Drafts are draft documents valid for a maximum of six months
	http://www.ietf.org/1id-abstracts.html		and may be updated, replaced, or obsoleted by other documents at any
			time. It is inappropriate to use Internet-Drafts as reference
			material or to cite them other than as "work in progress."
	The list of Internet-Draft Shadow Directories can be accessed at		This Internet-Draft will expire on April 18, 2011.
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on March 2011.		Copyright Notice
	Copyright Notice		Copyright (c) 2010 IETF Trust and the persons identified as the
			document authors. All rights reserved.
	Copyright (c) 2010 IETF Trust and the persons identified as the		This document is subject to BCP 78 and the IETF Trust's Legal
	document authors. All rights reserved.		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.
	This document is subject to BCP 78 and the IETF Trust's Legal		Table of Contents
	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.
	Abstract		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
			2. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 6
			2.1. AT-Bit in Options Field . . . . . . . . . . . . . . . . . 6
			2.2. Basic Operation . . . . . . . . . . . . . . . . . . . . . 7
			3. OSPFv3 Security Association . . . . . . . . . . . . . . . . . 8
			4. Authentication Procedure . . . . . . . . . . . . . . . . . . . 10
			4.1. Authentication Trailer . . . . . . . . . . . . . . . . . . 10
			4.2. Cryptographic Authentication Procedure . . . . . . . . . . 11
			4.3. Cryptographic Aspects . . . . . . . . . . . . . . . . . . 11
			4.4. Message Verification . . . . . . . . . . . . . . . . . . . 13
			5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
			6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
			7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
			7.1. Normative References . . . . . . . . . . . . . . . . . . . 16
			7.2. Informative References . . . . . . . . . . . . . . . . . . 16
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
			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 [RFC2119].
	Currently OSPFv3 uses IPsec for authenticating the protocol		When used in lowercase, these words convey their typical use in
	packets. There however are some environments (mobile ad-hoc),		common language, and are not to be interpreted as described in
	where IPsec is difficult to configure and maintain, and this		RFC2119 [RFC2119].
	mechanism cannot be used. This draft proposes an alternative
	mechanism that can be used so that OSPFv3 does not depend upon
	IPsec for security.
	Conventions used in this document		1. Introduction
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL		Unlike Open Shortest Path First version 2 (OSPFv2) [RFC2328], OSPF
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and		for IPv6 (OSPFv3) [RFC5340], does not include the AuType and
	"OPTIONAL" in this document are to be interpreted as described		Authentication fields in its headers for authenticating protocol
	in RFC 2119. [RFC2119]		packets. Instead, OSPFv3 relies on the IPv6 Authentication Header
			(AH)[RFC4302] and IPv6 Encapsulating Security Payload (ESP) [RFC4303]
			to provide integrity, authentication, and/or confidentiality.
	Table of Contents		[RFC4522] describes how IPv6 AH and ESP extension headers can be used
			to provide authentication and/or confidentiality to OSPFv3.
	1. Introduction..................................................2		However, there are some environments, e.g., Mobile Ad-hoc Networks
	2. Basic Operation...............................................4		(MANETs), where IPsec is difficult to configure and maintain, and
	3. OSPFv3 Security Association...................................5		this mechanism cannot be used. There is also an issue with IPsec not
	4. Authentication Procedure......................................6		being available on some platforms or it requiring an additional
	4.1. Authentication Trailer...................................6		license.
	4.2. Cryptographic Authentication Procedure...................7
	4.3. Cryptographic Aspects....................................8
	4.4. Message Verification....................................10
	5. Security Considerations......................................10
	6. IANA Considerations..........................................11
	7. References...................................................11
	7.1. Normative References....................................11
	7.2. Informative References..................................11
	1. Introduction		[RFC4522] discusses, at length, the reasoning behind using manually
			configured keys, rather than some automated key management protocol
			such as IKEv2 [RFC5996] . The primary problem is the lack of
			suitable key management mechanism, as OSPF 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.
	Unlike OSPF (Open Shortest Path First) Version 2 [RFC2328] OSPF		Regarding replay protection [RFC4522] states that:
	for IPv6 (OSPFv3) [RFC5340], does not have Auth Type and
	Authentication fields in its headers for authenticating the
	protocol packets. It instead relies on the IPv6 Authentication
	Header (AH) [RFC4302] and IPv6 Encapsulating Security Payload
	(ESP) [RFC4303] to provide integrity, authentication, and/or
	confidentiality.
	[RFC4552] describes how IPv6 AH/ESP extension headers can be		"As it is not possible as per the current standards to provide
	used to provide authentication/confidentiality to OSPFv3.		complete replay protection while using manual keying, the proposed
			solution will not provide protection against replay attacks."
	There however are some environments (mobile ad-hoc), where IPsec		Since there is no replay protection provided there are a number of
	is difficult to configure and maintain, and this mechanism		vulnerabilities in OSPFv3 which have been discussed in
	cannot be used. There is also an issue with IPsec not being		[I-D.ietf-opsec-routing-protocols-crypto-issues].
	available on some platforms or it requiring some additional
	license which may be expensive.
	[RFC4552] discusses, at length, the reasoning behind using		Since there is no deterministic way to differentiate between
	manually configured keys, rather than some automated key		encrypted and unencrypted ESP packets by simply examining the packet,
	management protocol such as IKEv2 [RFC5996]. The primary problem		it could become tricky for some implementations to prioritize certain
	is the lack of suitable key management mechanism, as OSPF		OSPFv3 packets (Hellos for example) over the others.
	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:		This draft proposes a new mechanism that works similar to OSPFv2
			[RFC5709]for providing authentication to the OSPFv3 packets and
			attempts to solve the problems described above for OSPFv3.
	As it is not possible as per the current standards to provide		Additionally this document describes how HMAC-SHA authentication can
	complete replay protection while using manual keying, the		be used for OSPFv3.
	proposed solution will not provide protection against replay
	attacks.
	Since there is no replay protection provided there are a number		By definition, HMAC ([RFC2104] , [FIPS-198]) requires a cryptographic
	of vulnerabilities in OSPFv3 which have been discussed in		hash function. This document proposes to use any one of SHA-1, SHA-
	[crypto-issues].		256, SHA-384, or SHA-512 [FIPS-180-3] to authenticate the OSPFv3
			packets.
	OSPFv3 uses IPsec for data integrity and rarely employs it for		It is believed that [RFC2104] is mathematically identical to
	confidentiality, therefore [RFC4552] mandates the use of ESP-		[FIPS-198] and it is also believed that algorithms in [RFC4634] are
	NULL.		mathematically identical to [FIPS-180-3].
	Since there is no deterministic way to differentiate between		2. Proposed Solution
	encrypted and unencrypted ESP packets by simply examining the
	packet, it could become tricky for some implementations to
	prioritize certain OSPFv3 packets (Hellos for example) over the
	others.
	This draft proposes a new mechanism that works similar to OSPFv2		To perform non-IPsec cryptographic authentication, OSPFv3 routers
	for providing authentication to the OSPFv3 packets and attempts		append a special data block, henceforth referred to as, the
	to solve the problems described above for OSPFv3.		authentication trailer to the end of the OSPFv3 packets. The length
			of the authentication trailer is not included into the length of the
			OSPFv3 packet, but is included in the IPv6 payload length.
	Additionally this document describes how HMAC-SHA authentication		+---------------------+ -- -- +---------------------+
	can be used for OSPFv3.		| IPv6 Header | ^ ^ | IPv6 Header |
			| Length = HL+X | | Header Length | | Length = HL+X+Y |
			| | v v | |
			+---------------------+ -- -- +---------------------+
			| OSPF Header | ^ ^ | OSPFv3 Header |
			| Length = X | | | | Length = X |
			| | | | | |
			|.....................| | X | X |.....................|
			| | | | | |
			| OSPFv3 Data | | | | OSPFv3 Data |
			| | v v | |
			+---------------------+ -- -- +---------------------+
			^ | |
			| | Authentication |
			| Y ~ Trailer ~
			| | |
			v | |
			-- +---------------------+
	By definition, HMAC ([RFC2104], [FIPS-198]) requires a		Figure 1: Authentication Trailer in OSPFv3
	cryptographic hash function. This document proposes to use any
	one of SHA-1, SHA-256, SHA-384, or SHA-512 [FIPS-180-3] to
	authenticate the OSPFv3 packets.
	It is believed that [RFC2104] is mathematically identical to		For the sake of consistency and simplicity the authentication trailer
	[FIPS-198] and it is also believed that algorithms in [RFC4634]		in the OSPFv3 packets MUST be inserted before the link local
	are mathematically identical to [FIPS-180-3].		signalling (LLS) [RFC5613] block, if it exists. This is inline with
			the authentication mechanism that currently exists for OSPFv2.
	2. Basic Operation		2.1. AT-Bit in Options Field
	The OSPFv3 authentication information is appended to the OSPFv3		A new AT-bit (AT stands for Authentication Trailer) is introduced
	packet and is not actually considered part of the OSPFv3 protocol		into the OSPFv3 Options field. OSPFv3 routers MUST set the AT-bit in
	packet. Thus the authentication information is not included in		OSPFv3 Hello and Database Description packets to indicate that the
	the OSPFv3 header's packet length, but is instead included in the		OSPFv3 router will include the authentication trailer in all OSPFv3
	IPv6 packet's payload length.		packets on the link. In other words, the authentication trailer is
			only examined if the AT-bit is set.
	This is very similar to how the message digest is carried in the		0 1 2
	OSPFv2 packet. The only difference between this mechanism and		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
	OSPFv2's authentication mechanism is that for OSPFv3 we carry		+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+--+-+--+
	some more authentication information in addition to the message		| | | | | | | | | | | | | |AT|L|AF|*|*|DC|R|N|MC|E|V6|
	digest. The additional information carried is detailed in the		+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+--+-+--+
	next section.
	Packet format before applying Authentication:		Figure 2: OSPFv3 Options Field
	+----------------+-----------------+		The AT-bit must be set in all OSPFv3 protocol packets that contain an
	|orig IP header | OSPFv3 Payload |		authentication trailer.
	|(any options) | |
	+----------------+-----------------+
	Packet format after applying Authentication:		2.2. Basic Operation
	+----------------+----------------+-----------------+		The procedure followed for computing the Authentication Trailer is
	|orig IP header | OSPFv3 Payload | Authentication |		exactly the same as described in [RFC5709] and [RFC2328].
	|(any options) | | Trailer |
	+----------------+----------------+-----------------+
	The procedure followed for computing the Authentication trailer		The way the authentication data is carried in the Authentication
	is exactly the same as described in [RFC5709] and [RFC2328].		Trailer is very similar to how its done in case of [RFC2328]. The
			only difference between this mechanism and OSPFv2's authentication
			mechanism is that for OSPFv3 some additional authentication
			information in addition to the message digest, is appended to the
			protocol packet.
	3. OSPFv3 Security Association		3. OSPFv3 Security Association
	An OSPFv3 Security Association contains a set of parameters		An OSPFv3 Security Association (SA) contains a set of parameters
	shared between any two legitimate OSPFv3 speakers.		shared between any two legitimate OSPFv3 speakers.
	Parameters associated with an OSPFv3 SA:		Parameters associated with an OSPFv3 SA:
	Key Identifier (Key ID)		o Key Identifier (Key ID)
	This is a 32-bit unsigned integer used to uniquely identify an		This is a 32-bit unsigned integer used to uniquely identify an
	OSPFV3 SA, as manually configured by the network operator.		OSPFv3 SA, as manually configured by the network operator.
	The receiver determines the active SA by looking at the Key ID		The receiver determines the active SA by looking at the Key ID
	field in the incoming protocol packet.		field in the incoming protocol packet.
	The sender based on the active configuration, selects the		The sender based on the active configuration, selects an SA to use
	Security Association to use and puts the correct Key ID value		and puts the correct Key ID value associated with the SA in the
	associated with the Security Association in the OSPFV3 protocol		OSPFV3 protocol packet. If multiple valid and active OSPFv3 SAs
	packet. If multiple valid and active OSPFV3 Security		exist for a given interface, the sender may use any of those SAs
	Associations exist for a given outbound interface at the time an		to protect the packet.
	OSPFV3 packet is sent, the sender may use any of those security
	associations to protect the packet.
	Using Key IDs makes changing keys while maintaining protocol		Using Key IDs makes changing keys while maintaining protocol
	operation convenient. Each key ID specifies two independent		operation convenient. Each key ID specifies two independent
	parts, the authentication protocol and the authentication key,		parts, the authentication protocol and the authentication key, as
	as explained below.		explained below.
	Normally, an implementation would allow the network operator to		Normally, an implementation would allow the network operator to
	configure a set of keys in a key chain, with each key in the		configure a set of keys in a key chain, with each key in the chain
	chain having fixed lifetime. The actual operation of these		having fixed lifetime. The actual operation of these mechanisms
	mechanisms is outside the scope of this document.		is outside the scope of this document.
	Note that each key ID can indicate a key with a different		Note that each key ID can indicate a key with a different
	authentication protocol. This allows multiple authentication		authentication protocol. This allows the introduction of new
	mechanisms to be used at various times without disrupting an		authentication mechanisms without disrupting existing OSPFv3
	OSPFv3 peering, including the introduction of new authentication		adjacencies.
	mechanisms.
	Authentication Algorithm		o Authentication Algorithm
	This signifies the authentication algorithm to be used with the		This signifies the authentication algorithm to be used with the
	OSPFv3 SA. This information is never sent in cleartext over the		OSPFv3 SA. This information is never sent in cleartext over the
	wire. Because this information is not sent on the wire, the		wire. Because this information is not sent on the wire, the
	implementer chooses an implementation specific representation		implementer chooses an implementation specific representation for
	for this information.		this information.
	At present, the following values are possible:		At present, the following values are possible:
	HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384 and HMAC-SHA-512.		HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512.
	Authentication Key		o Authentication Key
	This value denotes the cryptographic authentication key		This value denotes the cryptographic authentication key associated
	associated with the OSPFv3 SA. The length of this key is		with the OSPFv3 SA. The length of this key is variable and
	variable and depends upon the authentication algorithm specified		depends upon the authentication algorithm specified by the OSPFv3
	by the OSPFv3 SA.		SA.
	4. Authentication Procedure		4. Authentication Procedure
	4.1. Authentication Trailer		4.1. Authentication Trailer
	The authentication trailer that is appended to the OSPFv3		The authentication trailer that is appended to the OSPFv3 protocol
	protocol packet is described below:		packet is described below:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 0 | Key ID | Auth Data Len |		| 0 | Key ID | Auth Data Len |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Cryptographic Sequence Number |		| Cryptographic Sequence Number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| Authentication Data (Variable) |		| Authentication Data (Variable) |
	~ ~		~ ~
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1		Figure 3: Authentication Trailer Format
	The idea is to keep the fields as similar as possible with		The idea is to keep the fields as similar as possible with OSPFv2 so
	OSPFv2 so that most of the source code can be reused for		that most of the source code can be reused for authenticating the
	authenticating the OSPFv3 protocol packets.		OSPFv3 protocol packets.
	The various fields in the Authentication trailer are:		The various fields in the Authentication trailer are:
	Reserved		o Reserved
	16-bit reserved field. The value MUST be initialized to zero by		16-bit reserved field. The value MUST be initialized to zero by
	the sender, and MUST be ignored by the receiver.		the sender, and MUST be ignored by the receiver.
	Key ID (Identifier)		o Key ID (Identifier)
	32-bit field that identifies the algorithm and the secret key		32-bit field that identifies the algorithm and the secret key used
	used to create the message digest appended to the OSPFv3		to create the message digest appended to the OSPFv3 protocol
	protocol packet. Key Identifiers are unique per-interface.		packet. Key Identifiers are unique per-interface.
	Cryptographic Sequence Number		o Cryptographic Sequence Number
	32-bit non-decreasing sequence number that is used to guard		32-bit non-decreasing sequence number that is used to guard
	against replay attacks.		against replay attacks.
	Authentication Data		o Authentication Data
	Variable data that is carrying the digest of the protocol		Variable data that is carrying the digest of the protocol packet.
	packet.
	4.2. Cryptographic Authentication Procedure		4.2. Cryptographic Authentication Procedure
	As noted earlier the algorithms used to generate and verify the		As noted earlier the algorithms used to generate and verify the
	message digest are specified implicitly by the secret key. This		message digest are specified implicitly by the secret key. This
	specification discusses the computation of OSPFv3 Cryptographic		specification discusses the computation of OSPFv3 Cryptographic
	Authentication data when any of the NIST SHS family of		Authentication data when any of the NIST SHS family of algorithms is
	algorithms is used in the Hashed Message Authentication Code		used in the Hashed Message Authentication Code (HMAC) mode.
	(HMAC) mode.
	The currently valid algorithms (including mode) for OSPFv3		The currently valid algorithms (including mode) for OSPFv3
	Cryptographic Authentication include:		Cryptographic Authentication include:
	HMAC-SHA-1		HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384 and HMAC-SHA-512
	HMAC-SHA-256
	HMAC-SHA-384
	HMAC-SHA-512
	Of the above, implementations of this specification MUST include		Of the above, implementations of this specification MUST include
	support for at least:		support for at least HMAC-SHA-1 and SHOULD include support for HMAC-
			SHA-256 and MAY also include support for HMAC-SHA-384 and HMAC-SHA-
			512.
	HMAC-SHA-256		4.3. Cryptographic Aspects
	and SHOULD include support for:		In the algorithm description below, the following nomenclature, which
			is consistent with [FIPS-198], is used:
	HMAC-SHA-1		H is the specific hashing algorithm (e.g. SHA-256).
	and MAY also include support for:		K is the Authentication Key for the OSPFv3 security association.
	HMAC-SHA-384		Ko is the cryptographic key used with the hash algorithm.
	HMAC-SHA-512
	4.3. Cryptographic Aspects		B is the block size of H, measured in octets rather than bits.
	In the algorithm description below, the following nomenclature,		Note that B is the internal block size, not the hash size.
	which is consistent with [FIPS-198], is used:
	H is the specific hashing algorithm (e.g. SHA-256).		For SHA-1 and SHA-256: B == 64
	K is the Authentication Key for the OSPFv3 security association.		For SHA-384 and SHA-512: B == 128
	Ko is the cryptographic key used with the hash algorithm.		L is the length of the hash, measured in octets rather than bits.
	B is the block size of H, measured in octets rather than bits.		XOR is the exclusive-or operation.
	Note that B is the internal block size, not the hash size.		Opad is the hexadecimal value 0x5c repeated B times.
	For SHA-1 and SHA-256: B == 64		Ipad is the hexadecimal value 0x36 repeated B times.
	For SHA-384 and SHA-512: B == 128
	L is the length of the hash, measured in octets rather than		Apad is the hexadecimal value 0x878FE1F3 repeated (L/4) times.
	bits.
	XOR is the exclusive-or operation.		Implementation Note:
	Opad is the hexadecimal value 0x5c repeated B times.
	Ipad is the hexadecimal value 0x36 repeated B times.
	Apad is the hexadecimal value 0x878FE1F3 repeated (L/4) times.
	Implementation Note:		This definition of Apad means that Apad is always the same length as
			the hash output.
	This definition of Apad means that Apad is always the same		1. Preparation of the Key
	length as the hash output.
	(1)Preparation of the Key		In this application, Ko is always L octets long.
	In this application, Ko is always L octets long.		If the Authentication Key (K) is L octets long, then Ko is equal
			to K. If the Authentication Key (K) is more than L octets long,
			then Ko is set to H(K). If the Authentication Key (K) is less
			than L octets long, then Ko is set to the Authentication Key (K)
			with zeros appended to the end of the Authentication Key (K) such
			that Ko is L octets long.
	If the Authentication Key (K) is L octets long, then Ko is		2. First Hash
	equal to K. If the Authentication Key (K) is more than L
	octets long, then Ko is set to H(K). If the Authentication
	Key (K) is less than L octets long, then Ko is set to the
	Authentication Key (K) with zeros appended to the end of the
	Authentication Key (K) such that Ko is L octets long.
	(2)First Hash		First, the OSPFv3 packet's Authentication Trailer (which is very
			similar to the appendage described in RFC 2328, Section D.4.3,
			Page 233, items(6)(a) and (6)(d)) is filled with the value Apad.
	First, the OSPFv3 packet's Authentication Trailer (which is		Then, a First-Hash, also known as the inner hash, is computed as
	very similar to the appendage described in RFC 2328, Section		follows:
	D.4.3, Page 233, items(6)(a) and (6)(d)) is filled with the
	value Apad.
	Then, a First-Hash, also known as the inner hash, is computed		First-Hash = H(Ko XOR Ipad || (OSPFv3 Packet))
	as follows:
	First-Hash = H(Ko XOR Ipad || (OSPFv3 Packet))		Implementation Notes:
	Implementation Notes:		Note that the First-Hash above includes the Authentication
			Trailer containing the Apad value, as well as the OSPFv3
			packet, as per RFC 2328, Section D.4.3.
	Note that the First-Hash above includes the		The definition of Apad (above) ensures it is always the same
	Authentication Trailer containing the Apad value, as well		length as the hash output. This is consistent with RFC 2328.
	as the OSPFv3 packet, as per RFC 2328, Section D.4.3.		The "(OSPFv3 Packet)" mentioned in the First-Hash (above) does
			include the OSPF Authentication Trailer.
	The definition of Apad (above) ensures it is always the same		The digest length for SHA-1 is 20 bytes; for SHA-256, 32 bytes;
	length as the hash output. This is consistent with RFC 2328.		for SHA-384, 48 bytes; and for SHA-512, 64 bytes.
	The "(OSPFv3 Packet)" mentioned in the First-Hash (above)
	does include the OSPF Authentication Trailer.
	The digest length for SHA-1 is 20 bytes; for SHA-256, 32		3. Second Hash
	bytes; for SHA-384, 48 bytes; and for SHA-512, 64 bytes.
	(3)Second Hash		Then a second hash, also known as the outer hash, is computed as
			follows:
	Then a second hash, also known as the outer hash, is		Second-Hash = H(Ko XOR Opad || First-Hash)
	computed as follows:
	Second-Hash = H(Ko XOR Opad || First-Hash)		4. Result
	(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.
	The resulting Second-Hash becomes the authentication data		This also means that the use of hash functions with larger output
	that is sent in the Authentication Trailer of the OSPFv3		sizes will also increase the size of the OSPFv3 packet as
	packet. The length of the authentication data is always		transmitted on the wire.
	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		Implementation Note:
	output sizes will also increase the size of the OSPFv3 packet
	as transmitted on the wire.
	Implementation Note:		RFC 2328, 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 OSPFv3's own
			Length field, but is included in IPv6's payload length.
	RFC 2328, Appendix D specifies that the Authentication		4.4. Message Verification
	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 OSPFv3's own Length field, but is included
	in IPv6's payload length.
	4.4. Message Verification		A router would determine that OSPFv3 is using an Authentication
			trailer 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.
	An incoming router would implicitly know that OSPFv3 non IPsec		Authentication algorithm dependent processing needs to be performed,
	cryptographic authentication is in use if it finds that the		using the algorithm specified by the appropriate OSPFv3 SA for the
	length indicated by the IPv6 header is more than the packet		received packet.
	length given in the OSPFv3 header.
	Authentication algorithm dependent processing needs to be		Before an implementation performs any processing it needs to save the
	performed, using the algorithm specified by the appropriate		values of the Authentication data field from the Authentication
	OSPFv3 SA for the received packet.		Trailer appended to the OSPFv3 packet.
	Before an implementation performs any processing it needs to		It should then set the Authentication data field with Apad before the
	save the values of the Authentication data field from the		authentication data is computed. The calculated data is compared
	Authentication trailer appended to the OSPFv3 packet.		with the received authentication data in the Authentication trailer
			and the packet MUST be discarded if the two do not match. In such a
			case, an error event SHOULD be logged.
	It should then set the Authentication data field with Apad		An implementation MAY have a transition mode where it includes the
	before the authentication data is computed. The calculated data		Authentication Trailer in the packets but does not verify this
	is compared with the received authentication data in the		information. This is provided as a transition aid for networks in
	Authentication trailer and the packet is discarded if the two do		the process of migrating to the mechanism described in this draft.
	not match. In such a case, an error event SHOULD be logged.
	An implementation MAY have a transition mode where it includes		5. Security Considerations
	the Authentication Trailer in the packets but does not verify
	this information. This is provided as a transition aid for
	networks in the process of migrating to the mechanism described
	in this draft.
	5. Security Considerations		The document proposes extensions to OSPFv3 which would make it more
			secure than what it is today. 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 the packets which is of interest to us.
	The document proposes extensions to OSPFv3 which would make it		It should be noted that authentication method described in this
	more secure than what it is today. It does not provide		document is not being used to authenticate the specific originator of
	confidentiality as a routing protocol contains information		a packet, but is rather being used to confirm that the packet has
	that does not need to be kept secret. It does, however, provide		indeed been issued by a router which had access to the password.
	means to authenticate the sender of the packets which is of
	interest to us.
	It should be noted that authentication method described in this		The mechanism described here is not perfect and does not need to be
	document is not being used to authenticate the specific		perfect. Instead, this mechanism represents a significant increase
	originator of a packet, but is rather being used to confirm that		in the work function of an adversary attacking the OSPFv3 protocol,
	the packet has indeed been issued by a router which had access		while not causing undue implementation, deployment, or operational
	to the password.		complexity.
	The mechanism described here is not perfect and does not need to		6. IANA Considerations
	be perfect. Instead, this mechanism represents a significant
	increase in the work function of an adversary attacking the
	OSPFv3 protocol, while not causing undue implementation,
	deployment, or operational complexity.
	There is a transition mode suggested where routers can ignore		IANA is requested to allocate AT-bit in the OSPFv3 "Options Registry"
	the Generic Authentication extension header information carried
	in the protocol packets. The operator must ensure that this mode
	is only used when migrating to the new Generic Authentication
	based scheme as this leaves the router vulnerable to an attack.
	6. IANA Considerations		7. References
	The Generic Authentication extension header number is assigned		7.1. Normative References
	by IANA out of the IP Protocol Number space (and as recorded at
	the IANA web page at
	http://www.iana.org/assignments/protocol-numbers) is: TBD.
	7. References		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", BCP 14, RFC 2119, March 1997.
	7.1. Normative References		[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
	[RFC2119] Bradner, S.,"Key words for use in RFCs to Indicate		[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M.,
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic
			Authentication", RFC 5709, October 2009.
	[FIPS-180-3] US National Institute of Standards & Technology,		7.2. Informative References
	"Secure Hash Standard (SHS)", FIPS PUB 180-3, October
	2008.
	[FIPS-198] US National Institute of Standards & Technology, "The		[FIPS-180-3]
	Keyed-Hash Message Authentication Code (HMAC)", FIPS		US National Institute of Standards & Technology, "Secure
	PUB 198, March 2002.		Hash Standard (SHS)", FIPS PUB 180-3 , October 2008.
	7.2. Informative References		[FIPS-198]
			US National Institute of Standards & Technology, "The
			Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB
			198 , March 2002.
	[RFC2104] Krawczk, H., "HMAC: Keyed-Hashing for Message		[I-D.hartman-ospf-analysis]
	Authentication", RFC 2104, February 1997.		Hartman, S. and D. Zhang, "Analysis of OSPF Security
			According to KARP Design Guide",
			draft-hartman-ospf-analysis-01 (work in progress),
			June 2010.
	[RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998.		[I-D.ietf-opsec-routing-protocols-crypto-issues]
			Jaeggli, J., Hares, S., Bhatia, M., Manral, V., and R.
			White, "Issues with existing Cryptographic Protection
			Methods for Routing Protocols",
			draft-ietf-opsec-routing-protocols-crypto-issues-07 (work
			in progress), August 2010.
	[RFC5340] Coltun, R., et. al., "OSPF for Ipv6", RFC 5340, July		[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
	2008		Hashing for Message Authentication", RFC 2104,
			February 1997.
	[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,		[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
	December 2005.		December 2005.
	[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",		[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
	RFC 4303, December 2005.		RFC 4303, December 2005.
	[RFC5996] Kaufman, C., et. al., "Internet Key Exchange Protocol		[RFC4522] Legg, S., "Lightweight Directory Access Protocol (LDAP):
	Version 2 (IKEv2)", RFC 5996, September 2010.
	[RFC4552] Gupta, M. and Melam, N.,		The Binary Encoding Option", RFC 4522, June 2006.
	"Authentication/Confidentiality for OSPFv3", RFC 4552,
	June 2006
	[RFC4634] Eastlake 3rd, D. and T. Hansen, "US Secure Hash		[RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
	Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006.		(SHA and HMAC-SHA)", RFC 4634, July 2006.
	[RFC5709] Bhatia, M., et. al.,"OSPFv2 HMAC-SHA Cryptographic		[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
	Authentication", RFC 5709, October 2009		for IPv6", RFC 5340, July 2008.
	[crypto-issues] Bhatia, M., et. al., "Issues with existing		[RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D.
	Cryptographic Protection Methods for Routing		Yeung, "OSPF Link-Local Signaling", RFC 5613, August 2009.
	Protocols", Work in Progress
	Author's Addresses		[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
			"Internet Key Exchange Protocol Version 2 (IKEv2)",
			RFC 5996, September 2010.
	Manav Bhatia		Authors' Addresses
	Alcatel-Lucent
	Bangalore
	India
	Email: manav.bhatia@alcatel-lucent.com		Manav Bhatia
			Alcatel-Lucent
			Bangalore,
			India
	Vishwas Manral		Phone:
	IP Infusion		Email: manav.bhatia@alcatel-lucent.com
	USA
	Email: vishwas@ipinfusion.com		Vishwas
			IP Infusion
			USA
			Phone:
			Email: vishwas@ipinfusion.com
			Acee Lindem
			Ericsson
			102 Carric Bend Court
			Cary, NC 27519
			USA
			Phone:
			Email: acee.lindem@ericsson.com
End of changes. 144 change blocks.
	380 lines changed or deleted		390 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/