wdiff draft-bhatia-manral-auth-trailer-ospfv3-00.txt draft-bhatia-manral-auth-trailer-ospfv3-01.txt

KARP
OSPF Working Group Manav M. Bhatia
Internet Draft
Internet-Draft Alcatel-Lucent
Intended status: Standards Track Vishwas V. Manral
Expires: March, April 18, 2011 IP Infusion
September
A. Lindem
Ericsson
October 15, 2010

Supporting Authentication Trailer for OSPFv3

draft-bhatia-manral-auth-trailer-ospfv3-00.txt
draft-bhatia-manral-auth-trailer-ospfv3-01

Abstract

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.

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. (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

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 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 April 18, 2011.

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.

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 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 6
2.1. AT-Bit in Options Field . . . . . . . . . . . . . . . . . 6
2.2. Basic Operation...............................................4 Operation . . . . . . . . . . . . . . . . . . . . . 7
3. OSPFv3 Security Association...................................5 Association . . . . . . . . . . . . . . . . . 8
4. Authentication Procedure......................................6 Procedure . . . . . . . . . . . . . . . . . . . 10
4.1. Authentication Trailer...................................6 Trailer . . . . . . . . . . . . . . . . . . 10
4.2. Cryptographic Authentication Procedure...................7 Procedure . . . . . . . . . . 11
4.3. Cryptographic Aspects....................................8 Aspects . . . . . . . . . . . . . . . . . . 11
4.4. Message Verification....................................10 Verification . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations......................................10 Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations..........................................11 Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. References...................................................11 References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Normative References....................................11 References . . . . . . . . . . . . . . . . . . . 16
7.2. Informative References..................................11 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].

When used in lowercase, these words convey their typical use in
common language, and are not to be interpreted as described in
RFC2119 [RFC2119].

1. Introduction

Unlike OSPF (Open Open Shortest Path First) Version First version 2 [RFC2328] (OSPFv2) [RFC2328], OSPF
for IPv6 (OSPFv3) [RFC5340], does not have Auth Type include the AuType and
Authentication fields in its headers for authenticating the protocol
packets. It instead Instead, OSPFv3 relies on the IPv6 Authentication Header (AH) [RFC4302]
(AH)[RFC4302] and IPv6 Encapsulating Security Payload (ESP) [RFC4303]
to provide integrity, authentication, and/or confidentiality.

[RFC4552]

[RFC4522] describes how IPv6 AH/ESP AH and ESP extension headers can be used
to provide authentication/confidentiality authentication and/or confidentiality to OSPFv3.

There however

However, there are some environments (mobile ad-hoc), environments, e.g., Mobile Ad-hoc Networks
(MANETs), 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 an additional
license which may be expensive.

[RFC4552]
license.

[RFC4522] discusses, at length, the reasoning behind using manually
configured keys, rather than some automated key management protocol
such as IKEv2 [RFC5996]. [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] [RFC4522] 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. 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.
[I-D.ietf-opsec-routing-protocols-crypto-issues].

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
[RFC5709]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.

By definition, HMAC ([RFC2104], ([RFC2104] , [FIPS-198]) requires a cryptographic
hash function. This document proposes to use any one of SHA-1, SHA-256, 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 Proposed Solution

To perform non-IPsec cryptographic authentication, OSPFv3 routers
append a special data block, henceforth referred to as, the
authentication information is appended trailer to the OSPFv3
packet and is not actually considered part end of the OSPFv3 protocol
packet. Thus packets. The length
of the authentication information trailer is not included in into the length of the
OSPFv3 header's packet length, packet, but is instead included in the IPv6 packet's payload length.

This is very similar to how the message digest is carried

+---------------------+ -- -- +---------------------+
| 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 | |
-- +---------------------+

Figure 1: Authentication Trailer in OSPFv3

For the
OSPFv2 packet. The only difference between this mechanism sake of consistency and
OSPFv2's simplicity the authentication mechanism trailer
in the OSPFv3 packets MUST be inserted before the link local
signalling (LLS) [RFC5613] block, if it exists. This is inline with
the authentication mechanism that currently exists for OSPFv2.

2.1. AT-Bit in Options Field

A new AT-bit (AT stands for Authentication Trailer) is introduced
into the OSPFv3 we carry
some more authentication information Options field. OSPFv3 routers MUST set the AT-bit in addition
OSPFv3 Hello and Database Description packets to indicate that the message
digest. The additional information carried is detailed
OSPFv3 router will include the authentication trailer in all OSPFv3
packets on the
next section.

Packet format before applying Authentication:

+----------------+-----------------+
|orig IP header link. In other words, the authentication trailer is
only examined if the AT-bit is set.

0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+--+-+--+
| | | OSPFv3 Payload |
|(any options) | |
+----------------+-----------------+

Packet format after applying Authentication:

+----------------+----------------+-----------------+
|orig IP header | OSPFv3 Payload | Authentication |
|(any options) | | Trailer |
+----------------+----------------+-----------------+ | |AT|L|AF|*|*|DC|R|N|MC|E|V6|
+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+--+-+--+

Figure 2: OSPFv3 Options Field

The AT-bit must be set in all OSPFv3 protocol packets that contain an
authentication trailer.

2.2. Basic Operation

The procedure followed for computing the Authentication trailer Trailer is
exactly the same as described in [RFC5709] and [RFC2328].

The way the authentication data is carried in the Authentication
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

An OSPFv3 Security Association (SA) contains a set of parameters
shared between any two legitimate OSPFv3 speakers.

Parameters associated with an OSPFv3 SA:

o Key Identifier (Key ID)

This is a 32-bit unsigned integer used to uniquely identify an
OSPFV3
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 an SA to use
and puts the correct Key ID value associated with the Security Association SA in the
OSPFV3 protocol packet. If multiple valid and active OSPFV3 Security
Associations OSPFv3 SAs
exist for a given outbound interface at the time an
OSPFV3 packet is sent, interface, the sender may use any of those security
associations SAs
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. mechanisms without disrupting existing OSPFv3
adjacencies.

o 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.

At present, the following values are possible:

HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384 HMAC-SHA-384, and HMAC-SHA-512.

o 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 3: Authentication Trailer Format

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:

o Reserved

16-bit reserved field. The value MUST be initialized to zero by
the sender, and MUST be ignored by the receiver.

o 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.

o Cryptographic Sequence Number

32-bit non-decreasing sequence number that is used to guard
against replay attacks.

o 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-1, HMAC-SHA-256, HMAC-SHA-384 and HMAC-SHA-512

Of the above, implementations of this specification MUST include
support for at least:

HMAC-SHA-256 least HMAC-SHA-1 and SHOULD include support for:

HMAC-SHA-1 for HMAC-
SHA-256 and MAY also include support for: for HMAC-SHA-384
HMAC-SHA-512 and HMAC-SHA-
512.

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

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

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.

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

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

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.

4.4. Message Verification

An incoming

A router would implicitly know determine that OSPFv3 non IPsec
cryptographic authentication is using an Authentication
trailer by examining the AT-bit in use if it finds that the
length indicated by Options field in the IPv6 OSPFv3
header is more than the packet
length given for Hello and Database Description packets. The specification
in the Hello and Database description options indicates that other
OSPFv3 header. packets will include the authentication trailer.

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
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 MUST be 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.

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 is requested to allocate AT-bit in the IANA web page at
http://www.iana.org/assignments/protocol-numbers) is: TBD. OSPFv3 "Options Registry"

7. References

7.1. Normative References

[RFC2119] Bradner, S.,"Key S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M.,
Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic
Authentication", RFC 5709, October 2009.

7.2. Informative References

[FIPS-180-3]
US National Institute of Standards & Technology, "Secure
Hash Standard (SHS)", FIPS PUB 180-3, 180-3 , October 2008.

[FIPS-198]
US National Institute of Standards & Technology, "The
Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB 198,
198 , March 2002.

7.2. Informative References

[I-D.hartman-ospf-analysis]
Hartman, S. and D. Zhang, "Analysis of OSPF Security
According to KARP Design Guide",
draft-hartman-ospf-analysis-01 (work in progress),
June 2010.

[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.

[RFC2104] Krawczk, Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 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

[RFC4522] Legg, S., "Lightweight Directory Access Protocol
Version 2 (IKEv2)", RFC 5996, September 2010.

[RFC4552] Gupta, M. and Melam, N.,
"Authentication/Confidentiality for OSPFv3", (LDAP):

The Binary Encoding Option", RFC 4552, 4522, June 2006 2006.

[RFC4634] Eastlake 3rd, Eastlake, 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

[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for Routing
Protocols", Work in Progress

Author's IPv6", RFC 5340, July 2008.

[RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D.
Yeung, "OSPF Link-Local Signaling", RFC 5613, August 2009.

[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010.

Authors' Addresses

Manav Bhatia
Alcatel-Lucent
Bangalore
Bangalore,
India

Phone:
Email: manav.bhatia@alcatel-lucent.com

Vishwas Manral
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