draft-ietf-ospf-security-extension-manual-keying-09.txt   draft-ietf-ospf-security-extension-manual-keying-10.txt 
OSPF Working Group M. Bhatia OSPF Working Group M. Bhatia
Internet-Draft Ionos Networks Internet-Draft Ionos Networks
Intended status: Standards Track S. Hartman Intended status: Standards Track S. Hartman
Expires: April 9, 2015 Painless Security Expires: April 29, 2015 Painless Security
D. Zhang D. Zhang
Huawei Technologies co., LTD. Huawei Technologies co., LTD.
A. Lindem A. Lindem, Ed.
Cisco Cisco
October 6, 2014 October 26, 2014
Security Extension for OSPFv2 when using Manual Key Management Security Extension for OSPFv2 when using Manual Key Management
draft-ietf-ospf-security-extension-manual-keying-09 draft-ietf-ospf-security-extension-manual-keying-10
Abstract Abstract
The current OSPFv2 cryptographic authentication mechanism as defined The current OSPFv2 cryptographic authentication mechanism as defined
in RFC 2328 and RFC 5709 is vulnerable to both inter-session and in RFC 2328 and RFC 5709 is vulnerable to both inter-session and
intra-session replay attacks when using manual keying. Additionally, intra-session replay attacks when using manual keying. Additionally,
the existing cryptographic authentication mechanism does not cover the existing cryptographic authentication mechanism does not cover
the IP header. This omission can be exploited to carry out various the IP header. This omission can be exploited to carry out various
types of attacks. types of attacks.
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 9, 2015. This Internet-Draft will expire on April 29, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 2, line 29 skipping to change at page 2, line 29
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Section . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Section . . . . . . . . . . . . . . . . . . . 3
1.2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 4 1.2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 4
2. Replay Protection using Extended Sequence Numbers . . . . . . 4 2. Replay Protection using Extended Sequence Numbers . . . . . . 4
3. OSPF Packet Extensions . . . . . . . . . . . . . . . . . . . . 5 3. OSPF Packet Extensions . . . . . . . . . . . . . . . . . . . . 5
4. OSPF Packet Key Selection . . . . . . . . . . . . . . . . . . 6 4. OSPF Packet Key Selection . . . . . . . . . . . . . . . . . . 6
4.1. Key Selection for Unicast OSPF Packet Transmission . . . . 7 4.1. Key Selection for Unicast OSPF Packet Transmission . . . . 7
4.2. Key Selection for Multicast OSPF Packet Transmission . . . 8 4.2. Key Selection for Multicast OSPF Packet Transmission . . . 8
4.3. Key Selection for OSPF Packet Reception . . . . . . . . . 8 4.3. Key Selection for OSPF Packet Reception . . . . . . . . . 8
5. Securing the IP header . . . . . . . . . . . . . . . . . . . . 9 5. Securing the IP header . . . . . . . . . . . . . . . . . . . . 9
6. Mitigating Cross-Protocol Attacks . . . . . . . . . . . . . . 9 6. Mitigating Cross-Protocol Attacks . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
The OSPFv2 cryptographic authentication mechanism as described in The OSPFv2 cryptographic authentication mechanism as described in
[RFC2328] uses per-packet sequence numbers to provide protection [RFC2328] uses per-packet sequence numbers to provide protection
against replay attacks. The sequence numbers increase monotonically against replay attacks. The sequence numbers increase monotonically
so that attempts to replay stale packets can be thwarted. The so that attempts to replay stale packets can be thwarted. The
sequence number values are maintained as a part of neighbor adjacency sequence number values are maintained as a part of neighbor adjacency
skipping to change at page 6, line 40 skipping to change at page 6, line 40
| | | |
~ Authentication Data ~ ~ Authentication Data ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - Extended Sequence Number Packet Extensions Figure 1 - Extended Sequence Number Packet Extensions
4. OSPF Packet Key Selection 4. OSPF Packet Key Selection
This section describes how the proposed security solution selects This section describes how the proposed security solution selects
long-lived keys from key tables. [I-D.ietf-karp-crypto-key-table]. long-lived keys from key tables. [RFC7210]. In this context, we are
Generally, a key used for OSPFv2 packet authentication should satisfy selecting the key and corresponding Security Association (SA) as
the following requirements: defined in section 3.2 of [RFC5709]. Generally, a key used for
OSPFv2 packet authentication should satisfy the following
requirements:
o For packet transmission, the key validity interval as defined by o For packet transmission, the key validity interval as defined by
SendLifetimeStart and SendLifetimeEnd must include the current SendLifetimeStart and SendLifetimeEnd must include the current
time. time.
o For packet reception, the key validity interval as defined by o For packet reception, the key validity interval as defined by
AcceptLifetimeStart and AcceptLifetimeEnd must include the current AcceptLifetimeStart and AcceptLifetimeEnd must include the current
time. time.
o The key must be valid for the desired security algorithm. o The key must be valid for the desired security algorithm.
skipping to change at page 11, line 38 skipping to change at page 11, line 43
This document requests a new code point from the "OSPF Shortest Path This document requests a new code point from the "OSPF Shortest Path
First (OSPF) Authentication Codes" registry: First (OSPF) Authentication Codes" registry:
o 3 - Cryptographic Authentication with Extended Sequence Numbers. o 3 - Cryptographic Authentication with Extended Sequence Numbers.
This document also requests a new code point from the "Authentication This document also requests a new code point from the "Authentication
Cryptographic Protocol ID" registry defined under "Keying and Cryptographic Protocol ID" registry defined under "Keying and
Authentication for Routing Protocols (KARP) Parameters": Authentication for Routing Protocols (KARP) Parameters":
o 2 - OSPFv2. o TBD (3 Suggested) - OSPFv2.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M.,
Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic
Authentication", RFC 5709, October 2009. Authentication", RFC 5709, October 2009.
skipping to change at page 12, line 13 skipping to change at page 12, line 22
Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic
Authentication", RFC 5709, October 2009. Authentication", RFC 5709, October 2009.
9.2. Informative References 9.2. Informative References
[FIPS-198] [FIPS-198]
US National Institute of Standards & Technology, "The US National Institute of Standards & Technology, "The
Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB
198 , March 2002. 198 , March 2002.
[I-D.ietf-karp-crypto-key-table]
Housley, R., Polk, T., Hartman, S., and D. Zhang,
"Database of Long-Lived Symmetric Cryptographic Keys",
draft-ietf-karp-crypto-key-table-10 (work in progress),
December 2013.
[RFC1213] McCloghrie, K. and M. Rose, "Management Information Base [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base
for Network Management of TCP/IP-based internets:MIB-II", for Network Management of TCP/IP-based internets:MIB-II",
STD 17, RFC 1213, March 1991. STD 17, RFC 1213, March 1991.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
February 1997. February 1997.
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management (USM) for version 3 of the Simple Network Management
skipping to change at page 13, line 10 skipping to change at page 13, line 13
Routing Protocols", RFC 6094, February 2011. Routing Protocols", RFC 6094, February 2011.
[RFC6862] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and [RFC6862] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and
Authentication for Routing Protocols (KARP) Overview, Authentication for Routing Protocols (KARP) Overview,
Threats, and Requirements", RFC 6862, March 2013. Threats, and Requirements", RFC 6862, March 2013.
[RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security [RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security
According to the Keying and Authentication for Routing According to the Keying and Authentication for Routing
Protocols (KARP) Design Guide", RFC 6863, March 2013. Protocols (KARP) Design Guide", RFC 6863, March 2013.
[RFC7210] Housley, R., Polk, T., Hartman, S., and D. Zhang,
"Database of Long-Lived Symmetric Cryptographic Keys",
RFC 7210, April 2014.
Authors' Addresses Authors' Addresses
Manav Bhatia Manav Bhatia
Ionos Networks Ionos Networks
Bangalore, Bangalore,
India India
Phone: Phone:
Email: manav@ionosnetworks.com Email: manav@ionosnetworks.com
skipping to change at page 13, line 35 skipping to change at page 13, line 42
Dacheng Zhang Dacheng Zhang
Huawei Technologies co., LTD. Huawei Technologies co., LTD.
Beijing, Beijing,
China China
Phone: Phone:
Fax: Fax:
Email: zhangdacheng@huawei.com Email: zhangdacheng@huawei.com
URI: URI:
Acee Lindem Acee Lindem (editor)
Cisco Cisco
USA USA
Phone: Phone:
Email: acee@cisco.com Email: acee@cisco.com
 End of changes. 13 change blocks. 
20 lines changed or deleted 19 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/