draft-ietf-ospf-ospfv3-auth-05.txt   draft-ietf-ospf-ospfv3-auth-06.txt 
Network Working Group M. Gupta Network Working Group M. Gupta
Internet Draft Nokia Internet Draft Nokia
Document: draft-ietf-ospf-ospfv3-auth-05.txt N. Melam Document: draft-ietf-ospf-ospfv3-auth-06.txt N. Melam
Expires: April 2005 Nokia Expires: June 2005 Nokia
October 2004 December 2004
Authentication/Confidentiality for OSPFv3 Authentication/Confidentiality for OSPFv3
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of RFC 3668. aware will be disclosed, in accordance with Section 6 of RFC 3668.
skipping to change at page 2, line 8 skipping to change at page 2, line 8
Conventions used in this document Conventions used in this document
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 RFC-2119 [N7]. document are to be interpreted as described in RFC-2119 [N7].
Table of Contents Table of Contents
1. Introduction...................................................2 1. Introduction...................................................2
2. Transport Mode vs Tunnel Mode..................................2 2. Transport Mode vs Tunnel Mode..................................3
3. Authentication.................................................3 3. Authentication.................................................3
4. Confidentiality................................................3 4. Confidentiality................................................3
5. Distinguishing OSPFv3 from OSPFv2..............................4 5. Distinguishing OSPFv3 from OSPFv2..............................4
6. IPsec Requirements.............................................4 6. IPsec Requirements.............................................4
7. Key Management.................................................4 7. Key Management.................................................4
8. SA Granularity and Selectors...................................6 8. SA Granularity and Selectors...................................6
9. Virtual Links..................................................7 9. Virtual Links..................................................7
10. Changing Keys.................................................8 10. Rekeying......................................................8
11. IPsec rules...................................................8 10.1 Rekeying Procedure........................................8
12. Mandatory Encryption and Authentication Algorithms...........10 10.2 KeyRolloverInterval.......................................9
13. Replay Protection............................................10 10.3 Rekeying Interval.........................................9
Security Considerations..........................................10 11. IPsec rules...................................................9
Normative References.............................................11 12. Mandatory Encryption and Authentication Algorithms...........11
Informative References...........................................11 13. Entropy of manual keys.......................................11
Acknowledgments..................................................11 14. Replay Protection............................................11
Authors' Addresses...............................................12 Security Considerations..........................................12
Normative References.............................................12
Informative References...........................................13
Acknowledgments..................................................13
Authors' Addresses...............................................14
1. Introduction 1. Introduction
OSPF (Open Shortest Path First) Version 2 [N1] defines fields AuType OSPF (Open Shortest Path First) Version 2 [N1] defines fields AuType
and Authentication in its protocol header in order to provide and Authentication in its protocol header in order to provide
security. In OSPF for IPv6 (OSPFv3) [N2], both of the authentication security. In OSPF for IPv6 (OSPFv3) [N2], both of the authentication
fields were removed from OSPF headers. OSPFv3 relies on the fields were removed from OSPF headers. OSPFv3 relies on the IPv6
IPv6 Authentication Header (AH) and IPv6 Encapsulating Security Authentication Header (AH) and IPv6 Encapsulating Security Payload
Payload (ESP) to provide integrity, authentication and/or (ESP) to provide integrity, authentication and/or confidentiality.
confidentiality.
This document describes how IPv6 AH/ESP extension headers can be used This document describes how IPv6 AH/ESP extension headers can be used
to provide authentication/confidentiality to OSPFv3. to provide authentication/confidentiality to OSPFv3.
It is assumed that the reader is familiar with OSPFv3 [N2], AH [N5], It is assumed that the reader is familiar with OSPFv3 [N2], AH [N5],
ESP [N4], the concept of security associations, tunnel and transport ESP [N4], the concept of security associations, tunnel and transport
mode of IPsec and the key management options available for AH and ESP mode of IPsec and the key management options available for AH and ESP
(manual keying [N3] and Internet Key Exchange (IKE)[I1]). (manual keying [N3] and Internet Key Exchange (IKE)[I1]).
2. Transport Mode vs Tunnel Mode 2. Transport Mode vs Tunnel Mode
skipping to change at page 8, line 9 skipping to change at page 8, line 11
received in intra-area-prefix-LSAs from the virtual neighbor in the received in intra-area-prefix-LSAs from the virtual neighbor in the
transit area MUST be used as the destination address for packets transit area MUST be used as the destination address for packets
exchanged over the virtual link. When multiple intra-area-prefix- exchanged over the virtual link. When multiple intra-area-prefix-
LSAs are received they are considered as being concatenated and are LSAs are received they are considered as being concatenated and are
ordered by ascending Link State ID. ordered by ascending Link State ID.
This makes both the source and destination addresses of the packets This makes both the source and destination addresses of the packets
exchanged over the virtual link, predictable on both the routers for exchanged over the virtual link, predictable on both the routers for
security purposes. security purposes.
10. Changing Keys 10. Rekeying
To maintain the security of a link, the key values SHOULD be changed To maintain the security of a link, the authentication and encryption
from time to time. The following three-step procedure SHOULD be key values SHOULD be changed from time to time.
provided to rekey the routers on a link without dropping OSPFv3
protocol packets or disrupting the adjacency. 10.1 Rekeying Procedure
The following three-step procedure SHOULD be provided to rekey the
routers on a link without dropping OSPFv3 protocol packets or
disrupting the adjacency.
(1) For every router on the link, create an additional inbound SA for (1) For every router on the link, create an additional inbound SA for
the interface being rekeyed using a new SPI and the new key. the interface being rekeyed using a new SPI and the new key.
(2) For every router on the link, replace the original outbound SA (2) For every router on the link, replace the original outbound SA
with one using the new SPI and key values. The SA replacement with one using the new SPI and key values. The SA replacement
operation should be atomic with respect to sending OSPFv3 packets operation should be atomic with respect to sending OSPFv3 packets
on the link so that no OSPFv3 packets are sent without on the link so that no OSPFv3 packets are sent without
authentication/encryption. authentication/encryption.
skipping to change at page 8, line 45 skipping to change at page 9, line 5
it waits for this interval and then moves to step 3. it waits for this interval and then moves to step 3.
In order to achieve smooth key transition, all the routers on a link In order to achieve smooth key transition, all the routers on a link
should use the same value for KeyRolloverInterval, and should should use the same value for KeyRolloverInterval, and should
initiate the key rollover process within this time period. initiate the key rollover process within this time period.
At the end of this procedure, all the routers will have a single At the end of this procedure, all the routers will have a single
inbound and outbound SA for OSPFv3 on the link with the new SPI and inbound and outbound SA for OSPFv3 on the link with the new SPI and
key values. key values.
10.2 KeyRolloverInterval
The configured value of KeyRolloverInterval should be long enough to
allow the administrator to change keys on all the involved routers.
As this value can vary significantly depending upon the
implementation and the deployment, it is left to the administrator to
choose the appropriate value.
10.3 Rekeying Interval
This section analyzes the security provided by the manual keying and
recommends that the encryption and authentication keys SHOULD be
changed at least every 90 days.
The weakest security provided by the security mechanisms discussed in
this specification is when NULL encryption is used with the HMAC-MD5
authentication. Any other algorithm combinations will at least be as
hard to break as the one mentioned above as shown by the following
examples:
O NULL Encryption and HMAC-SHA-1 Authentication will be more secure
as HMAC-SHA-1 is considered to be more secure than HMAC-MD5
O NON-NULL Encryption and NULL Authentication is not applicable as
this specification mandates the authentication when OSPFv3 security
is enabled
O DES Encryption and HMAC-MD5 Authentication will be more secure
because of the additional security provided by DES
O Other encryption algorithms like 3DES, AES will be more secure than
DES
RFC 3562 [I4] analyzes the rekeying requirements for the TCP MD5
signature option. The analysis provided in this RFC is also
applicable to OSPFv3 security specification as the analysis is
independent of data patterns.
11. IPsec rules 11. IPsec rules
The following set of transport mode rules can be installed in a The following set of transport mode rules can be installed in a
typical IPsec implementation to provide the typical IPsec implementation to provide the
authentication/confidentiality to OSPFv3 packets. authentication/confidentiality to OSPFv3 packets.
Outbound Rules for interface running OSPFv3 security: Outbound Rules for interface running OSPFv3 security:
No. source destination protocol action No. source destination protocol action
1 fe80::/10 any OSPF apply 1 fe80::/10 any OSPF apply
skipping to change at page 10, line 15 skipping to change at page 11, line 11
security is turned on. On the other hand installing these rules on security is turned on. On the other hand installing these rules on
all the interfaces increases the processing overhead on the all the interfaces increases the processing overhead on the
interfaces where there is no IPsec processing otherwise. The interfaces where there is no IPsec processing otherwise. The
decision of installing these rules on all the interfaces or on just decision of installing these rules on all the interfaces or on just
the interfaces that are connected to the transit area is a private the interfaces that are connected to the transit area is a private
decision and doesn't affect the interoperability in any way. So this decision and doesn't affect the interoperability in any way. So this
decision is left to the implementers. decision is left to the implementers.
12. Mandatory Encryption and Authentication Algorithms 12. Mandatory Encryption and Authentication Algorithms
The implementation MUST allow the user to choose AES-CBC as the The implementation MUST allow the user to choose AES-CBC [N8] as the
encryption algorithm and HMAC-SHA1 as the authentication algorithm encryption algorithm and HMAC-SHA1-96 [N9] as the authentication
for securing OSPFv3 packets. algorithm for securing OSPFv3 packets.
The implementation MUST NOT allow the user to choose stream ciphers The implementation MUST NOT allow the user to choose stream ciphers
as the encryption algorithm for securing OSPFv3 packets as the stream as the encryption algorithm for securing OSPFv3 packets as the stream
ciphers are not suitable for manual keys. ciphers are not suitable for manual keys.
13. Replay Protection 13. Entropy of manual keys
The implementations MUST allow the administrator to configure the
cryptographic and authentication keys in hexadecimal format instead
of restricting it a subset of ASCII characters (letters, numbers
etc). Otherwise the entropy of the keys reduces significantly as
discussed in [I2].
14. Replay Protection
As it is not possible as per the current standards to provide As it is not possible as per the current standards to provide
complete replay protection while using manual keying, the proposed complete replay protection while using manual keying, the proposed
solution will not provide protection against replay attacks. solution will not provide protection against replay attacks. This
section analyzes the protection built in OSPF protocol to guard
itself against replay attacks.
OSPF protocol has the following types of packets:
Hello: OSPF does not have any protection against replayed hello
messages thus OSPF will be vulnerable to the attacks performed by
replaying hello messages even after enabling security.
Database Description: These packets are exchanged while building the
adjacencies to describe the OSPF database. There are no known
threats of replaying these type of packets.
Link State Request, Link State Acknowledgment and Link State Updates:
Fields LS age, LS Sequence Number and LS checksum in LSA header are Fields LS age, LS Sequence Number and LS checksum in LSA header are
kept intact in OSPFv3. Though these fields do not provide the kept intact in OSPFv3. Though these fields do not provide the
complete protection, they certainly help against replay attacks. complete protection, they certainly help against replay attacks of
Link State packets.
Detailed analysis of various vulnerabilities of the routing protocols
is discussed in [I3].
Security Considerations Security Considerations
This memo discusses the use of IPsec AH and ESP headers in order to This memo discusses the use of IPsec AH and ESP headers in order to
provide security to OSPFv3 for IPv6. Hence security permeates provide security to OSPFv3 for IPv6. Hence security permeates
throughout this document. throughout this document.
OSPF Security Vulnerabilities Analysis [I2] identifies OSPF
vulnerabilities in two scenarios - One with no authentication or
simple password authentication and the other with cryptographic
authentication. The solution described in this specification
provides security against all the vulnerabilities identified for
scenario with cryptographic authentication with the following
exceptions:
Limitations of manual key:
This specification mandates the usage of manual keys. The following This specification mandates the usage of manual keys. The following
are the known limitations of the usage of manual keys. are the known limitations of the usage of manual keys.
O As the sequence numbers can not be negotiated, replay protection
can not be provided. This leaves OSPF insecure against all the
attacks that can be performed by replaying OSPF packets.
O Manual keys are usually long lived (changing them very often is O Manual keys are usually long lived (changing them very often is
a tedious task). This gives an attacker enough time to discover a tedious task). This gives an attacker enough time to discover
the keys. the keys.
O As the administrator is manually configuring the keys, there is O As the administrator is manually configuring the keys, there is
a chance that the configured keys are weak (there are known weak a chance that the configured keys are weak (there are known weak
keys for DES/3DES at least). keys for DES/3DES at least).
O As the sequence numbers can not be negotiated, replay protection Impersonating Attacks:
can not be provided. The usage of the same key on all the routers on the same link for
securing OSPF leaves it insecure against impersonating attacks if one
of the routers is compromised, malfunctioning or misconfigured.
Inspite of the above known limitations, the security provided by the Detailed analysis of various vulnerabilities of the routing protocols
usage of the manual keys should be adequate for a routing protocol. is discussed in [I3].
Normative References Normative References
N1. Moy, J., "OSPF version 2", RFC 2328, April 1998 N1. Moy, J., "OSPF version 2", RFC 2328, April 1998.
N2. Coltun, R., Ferguson, D. and J. Moy, "OSPF for IPv6", RFC 2740, N2. Coltun, R., Ferguson, D. and J. Moy, "OSPF for IPv6", RFC 2740,
December 1999 December 1999.
N3. Kent, S. and K. Seo, "Security Architecture for the Internet N3. Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC XXXX, date [Note to RFC-Editor: Replace XXXX with Protocol", RFC XXXX, date [Note to RFC-Editor: Replace XXXX with
the number of the RFC 2401 replacement]. the number of the RFC 2401 replacement].
N4. Kent, S., "IP Encapsulating Security Payload (ESP)", RFC XXXY, N4. Kent, S., "IP Encapsulating Security Payload (ESP)", RFC XXXY,
date [Note to RFC-Editor: Replace XXXY with the number of the RFC date [Note to RFC-Editor: Replace XXXY with the number of the RFC
2406 replacement]. 2406 replacement].
N5. Kent, S., "IP Authentication Header (AH)", RFC XXXZ, date [Note to N5. Kent, S., "IP Authentication Header (AH)", RFC XXXZ, date [Note to
skipping to change at page 11, line 38 skipping to change at page 13, line 25
replacement]. replacement].
N6. Eastlake, D., "Cryptographic Algorithm Implementation Requirements N6. Eastlake, D., "Cryptographic Algorithm Implementation Requirements
For ESP And AH", RFC XXYY, date [Note to RFC-Editor: Replace XXYY For ESP And AH", RFC XXYY, date [Note to RFC-Editor: Replace XXYY
with the number of the RFC that the draft draft-ietf-ipsec-esp-ah- with the number of the RFC that the draft draft-ietf-ipsec-esp-ah-
algorithms-02.txt gets]. algorithms-02.txt gets].
N7. Bradner, S., "Key words for use in RFCs to Indicate Requirement N7. Bradner, S., "Key words for use in RFCs to Indicate Requirement
Level", BCP 14, RFC 2119, March 1997. Level", BCP 14, RFC 2119, March 1997.
N8. Frankel, S., Glenn, R. and S. Kelly, "The AES-CBC Cipher Algorithm
and Its Use with IPsec", RFC 3602, September 2003.
N9. Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and
AH", RFC 2404, November 1998.
Informative References Informative References
I1. Kaufman, C., "The Internet Key Exchange (IKEv2) Protocol", RFC I1. Kaufman, C., "The Internet Key Exchange (IKEv2) Protocol", RFC
XXZZ, date [Note to RFC-Editor: Replace XXZZ with the number of the XXZZ, date [Note to RFC-Editor: Replace XXZZ with the number of the
RFC 2409 replacement]. RFC 2409 replacement].
I2. Jones, E. and O. Moigne, "OSPF Security Vulnerabilities Analysis",
draft-ietf-rpsec-ospf-vuln-01.txt, work in progress.
I3. Barbir, A., Murphy, S. and Y. Yang, "Generic Threats to Routing
Protocols", draft-ietf-rpsec-routing-threats-07.txt, work in
progress.
I4. Leech, M., "Key Management Considerations for the TCP MD5
Signature Option", RFC 3562, July 2003.
Acknowledgments Acknowledgments
Authors would like to extend sincere thanks to Marc Solsona, Janne Authors would like to extend sincere thanks to Marc Solsona, Janne
Peltonen, John Cruz, Dhaval Shah, Abhay Roy and Paul Wells for Peltonen, John Cruz, Dhaval Shah, Abhay Roy and Paul Wells for
providing useful information and critiques in order to write this providing useful information and critiques in order to write this
memo. memo.
We would also like to thank IPsec and OSPF WG people to provide We would also like to thank IPsec and OSPF WG people to provide
valuable review comments. valuable review comments.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/