KARP Working Group Manav Bhatia
Internet Draft Alcatel-Lucent
Intended status: Standards Track Vishwas Manral
Expires: March, 2011 IP Infusion
September 2010
Supporting Authentication Trailer for OSPFv3
draft-bhatia-manral-auth-trailer-ospfv3-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance
with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months 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 current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described
in Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the Simplified BSD License.
Bhatia and Manral Standards Track [Page 1]
Internet-Draft September 2010
Abstract
Currently OSPFv3 uses IPsec for authenticating the protocol
packets. There however are some environments (mobile ad-hoc),
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 security.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in RFC 2119. [RFC2119]
Table of Contents
1. Introduction..................................................2
2. Basic Operation...............................................4
3. OSPFv3 Security Association...................................5
4. Authentication Procedure......................................6
4.1. Authentication Trailer...................................6
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
Unlike OSPF (Open Shortest Path First) Version 2 [RFC2328] OSPF
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.
Bhatia and Manral Expires March 2011 [Page 2]
Internet-Draft September 2010
[RFC4552] describes how IPv6 AH/ESP extension headers can be
used to provide authentication/confidentiality to OSPFv3.
There however are some environments (mobile ad-hoc), where IPsec
is difficult to configure and maintain, and this mechanism
cannot be used. There is also an issue with IPsec not being
available on some platforms or it requiring some additional
license which may be expensive.
[RFC4552] 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.
Regarding replay protection [RFC4552] states that:
As it is not possible as per the current standards to provide
complete replay protection while using manual keying, the
proposed solution will not provide protection against replay
attacks.
Since there is no replay protection provided there are a number
of vulnerabilities in OSPFv3 which have been discussed in
[crypto-issues].
OSPFv3 uses IPsec for data integrity and rarely employs it for
confidentiality, therefore [RFC4552] mandates the use of ESP-
NULL.
Since there is no deterministic way to differentiate between
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
for providing authentication to the OSPFv3 packets and attempts
to solve the problems described above for OSPFv3.
Additionally this document describes how HMAC-SHA authentication
can be used for OSPFv3.
Bhatia and Manral Expires March 2011 [Page 3]
Internet-Draft September 2010
By definition, HMAC ([RFC2104], [FIPS-198]) requires a
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
[FIPS-198] and it is also believed that algorithms in [RFC4634]
are mathematically identical to [FIPS-180-3].
2. Basic Operation
The OSPFv3 authentication information is appended to the OSPFv3
packet and is not actually considered part of the OSPFv3 protocol
packet. Thus the authentication information is not included in
the OSPFv3 header's packet length, but is instead included in the
IPv6 packet's payload length.
This is very similar to how the message digest is carried in the
OSPFv2 packet. The only difference between this mechanism and
OSPFv2's authentication mechanism is that for OSPFv3 we carry
some more authentication information in addition to the message
digest. The additional information carried is detailed in the
next section.
Packet format before applying Authentication:
+----------------+-----------------+
|orig IP header | OSPFv3 Payload |
|(any options) | |
+----------------+-----------------+
Packet format after applying Authentication:
+----------------+----------------+-----------------+
|orig IP header | OSPFv3 Payload | Authentication |
|(any options) | | Trailer |
+----------------+----------------+-----------------+
The procedure followed for computing the Authentication trailer
is exactly the same as described in [RFC5709] and [RFC2328].
Bhatia and Manral Expires March 2011 [Page 4]
Internet-Draft September 2010
3. OSPFv3 Security Association
An OSPFv3 Security Association contains a set of parameters
shared between any two legitimate OSPFv3 speakers.
Parameters associated with an OSPFv3 SA:
Key Identifier (Key ID)
This is a 32-bit unsigned integer used to uniquely identify an
OSPFV3 SA, as manually configured by the network operator.
The receiver determines the active SA by looking at the Key ID
field in the incoming protocol packet.
The sender based on the active configuration, selects the
Security Association to use and puts the correct Key ID value
associated with the Security Association in the OSPFV3 protocol
packet. If multiple valid and active OSPFV3 Security
Associations exist for a given outbound interface at the time an
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
operation convenient. Each key ID specifies two independent
parts, the authentication protocol and the authentication key,
as explained below.
Normally, an implementation would allow the network operator to
configure a set of keys in a key chain, with each key in the
chain having fixed lifetime. The actual operation of these
mechanisms is outside the scope of this document.
Note that each key ID can indicate a key with a different
authentication protocol. This allows multiple authentication
mechanisms to be used at various times without disrupting an
OSPFv3 peering, including the introduction of new authentication
mechanisms.
Authentication Algorithm
This signifies the authentication algorithm to be used with the
OSPFv3 SA. This information is never sent in cleartext over the
wire. Because this information is not sent on the wire, the
implementer chooses an implementation specific representation
for this information.
Bhatia and Manral Expires March 2011 [Page 5]
Internet-Draft September 2010
At present, the following values are possible:
HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384 and HMAC-SHA-512.
Authentication Key
This value denotes the cryptographic authentication key
associated with the OSPFv3 SA. The length of this key is
variable and depends upon the authentication algorithm specified
by the OSPFv3 SA.
4. Authentication Procedure
4.1. Authentication Trailer
The authentication trailer that is appended to the OSPFv3
protocol packet is described below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Key ID | Auth Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptographic Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authentication Data (Variable) |
~ ~
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
The idea is to keep the fields as similar as possible with
OSPFv2 so that most of the source code can be reused for
authenticating the OSPFv3 protocol packets.
The various fields in the Authentication trailer are:
Reserved
16-bit reserved field. The value MUST be initialized to zero by
the sender, and MUST be ignored by the receiver.
Bhatia and Manral Expires March 2011 [Page 6]
Internet-Draft September 2010
Key ID (Identifier)
32-bit field that identifies the algorithm and the secret key
used to create the message digest appended to the OSPFv3
protocol packet. Key Identifiers are unique per-interface.
Cryptographic Sequence Number
32-bit non-decreasing sequence number that is used to guard
against replay attacks.
Authentication Data
Variable data that is carrying the digest of the protocol
packet.
4.2. Cryptographic Authentication Procedure
As noted earlier the algorithms used to generate and verify the
message digest are specified implicitly by the secret key. This
specification discusses the computation of OSPFv3 Cryptographic
Authentication data when any of the NIST SHS family of
algorithms is used in the Hashed Message Authentication Code
(HMAC) mode.
The currently valid algorithms (including mode) for OSPFv3
Cryptographic Authentication include:
HMAC-SHA-1
HMAC-SHA-256
HMAC-SHA-384
HMAC-SHA-512
Of the above, implementations of this specification MUST include
support for at least:
HMAC-SHA-256
and SHOULD include support for:
HMAC-SHA-1
and MAY also include support for:
HMAC-SHA-384
HMAC-SHA-512
Bhatia and Manral Expires March 2011 [Page 7]
Internet-Draft September 2010
4.3. Cryptographic Aspects
In the algorithm description below, the following nomenclature,
which is consistent with [FIPS-198], is used:
H is the specific hashing algorithm (e.g. SHA-256).
K is the Authentication Key for the OSPFv3 security association.
Ko is the cryptographic key used with the hash algorithm.
B is the block size of H, measured in octets rather than bits.
Note that B is the internal block size, not the hash size.
For SHA-1 and SHA-256: B == 64
For SHA-384 and SHA-512: B == 128
L is the length of the hash, measured in octets rather than
bits.
XOR is the exclusive-or operation.
Opad is the hexadecimal value 0x5c repeated B times.
Ipad is the hexadecimal value 0x36 repeated B times.
Apad is 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.
(1)Preparation of the Key
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.
(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.
Bhatia and Manral Expires March 2011 [Page 8]
Internet-Draft September 2010
Then, a First-Hash, also known as the inner hash, is computed
as follows:
First-Hash = H(Ko XOR Ipad || (OSPFv3 Packet))
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.
The definition of Apad (above) ensures it is always the same
length as the hash output. This is consistent with RFC 2328.
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
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:
Second-Hash = H(Ko XOR Opad || First-Hash)
(4)Result
The resulting Second-Hash becomes the authentication data
that is sent in the Authentication Trailer of the OSPFv3
packet. The length of the authentication data is always
identical to the message digest size of the specific hash
function H that is being used.
This also means that the use of hash functions with larger
output sizes will also increase the size of the OSPFv3 packet
as transmitted on the wire.
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.
Bhatia and Manral Expires March 2011 [Page 9]
Internet-Draft September 2010
4.4. Message Verification
An incoming router would implicitly know that OSPFv3 non IPsec
cryptographic authentication is in use if it finds that the
length indicated by the IPv6 header is more than the packet
length given in the OSPFv3 header.
Authentication algorithm dependent processing needs to be
performed, using the algorithm specified by the appropriate
OSPFv3 SA for the received packet.
Before an implementation performs any processing it needs to
save the values of the Authentication data field from the
Authentication trailer appended to the OSPFv3 packet.
It should then set the Authentication data field with Apad
before the authentication data is computed. The calculated data
is compared with the received authentication data in the
Authentication trailer and the packet is discarded if the two do
not match. In such a case, an error event SHOULD be logged.
An implementation MAY have a transition mode where it includes
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.
It should be noted that authentication method described in this
document is not being used to authenticate the specific
originator of a packet, but is rather being used to confirm that
the packet has indeed been issued by a router which had access
to the password.
The mechanism described here is not perfect and does not need to
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.
Bhatia and Manral Expires March 2011 [Page 10]
Internet-Draft September 2010
There is a transition mode suggested where routers can ignore
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
The Generic Authentication extension header number is assigned
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
7.1. Normative References
[RFC2119] Bradner, S.,"Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[FIPS-180-3] US National Institute of Standards & Technology,
"Secure Hash Standard (SHS)", FIPS PUB 180-3, October
2008.
[FIPS-198] US National Institute of Standards & Technology, "The
Keyed-Hash Message Authentication Code (HMAC)", FIPS
PUB 198, March 2002.
7.2. Informative References
[RFC2104] Krawczk, H., "HMAC: Keyed-Hashing for Message
Authentication", RFC 2104, February 1997.
[RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[RFC5340] Coltun, R., et. al., "OSPF for Ipv6", RFC 5340, July
2008
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC5996] Kaufman, C., et. al., "Internet Key Exchange Protocol
Version 2 (IKEv2)", RFC 5996, September 2010.
Bhatia and Manral Expires March 2011 [Page 11]
Internet-Draft September 2010
[RFC4552] Gupta, M. and Melam, N.,
"Authentication/Confidentiality for OSPFv3", RFC 4552,
June 2006
[RFC4634] Eastlake 3rd, D. and T. Hansen, "US Secure Hash
Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006.
[RFC5709] Bhatia, M., et. al.,"OSPFv2 HMAC-SHA Cryptographic
Authentication", RFC 5709, October 2009
[crypto-issues] Bhatia, M., et. al., "Issues with existing
Cryptographic Protection Methods for Routing
Protocols", Work in Progress
Author's Addresses
Manav Bhatia
Alcatel-Lucent
Bangalore
India
Email: manav.bhatia@alcatel-lucent.com
Vishwas Manral
IP Infusion
USA
Email: vishwas@ipinfusion.com
Bhatia and Manral Expires March 2011 [Page 12]