Mobile Ad hoc Networking (MANET) | U. Herberg |
Internet-Draft | Fujitsu Laboratories of America |
Intended status: Standards Track | T. Clausen |
Expires: January 31, 2012 | LIX, Ecole Polytechnique |
July 30, 2011 |
Cryptographical Signatures in NHDP
draft-ietf-manet-nhdp-sec-00
This document specifies an extension to the Neighbor Discovery Protocol (NHDP) which uses cryptographic signatures in HELLO messages to encounter a selection of security threats to NHDP.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (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 as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 31, 2012.
Copyright (c) 2011 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.
This document describes how to use cryptographic signatures for countering a selection of the security threats analyzed in [NHDP-sec-threats]. It specifies the use of such signatures for validating the identity of the originator of a HELLO message, the validity of the content (i.e. links being advertised) of a HELLO message, and the message integrity. The protection so offered against the threats in [NHDP-sec-threats] is evaluated.
This document specifies TLVs for carrying cryptographic signatures in HELLO messages using [RFC5444], and specifies extensions (as enabled by [RFC6130]) to the HELLO message processing in [RFC6130].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
Additionally, this document uses the terminology of [RFC5444], [packetbb-sec], [RFC6130] and [NHDP-sec-threats].
Therefore:
The framework presented in this document provides two functionalities:
When a router running NHDP is about to transmit a HELLO message on an interface, this extension:
The framework allows to add several signatures with different hash and cryptographic functions.
[RFC6130] allows to reject incoming HELLO messages prior to processing by NHDP for reasons such as invalid signatures. This extension specifies that for each SIGNATURE TLV in the Message TLV Block of that incoming message, the value of that TLV (i.e. the contained signature) is verified.
HELLO messages are generated as specified in [RFC6130]. In addition, each HELLO message MUST set the <msg-orig-addr> as well as the <msg-seq-num> field as specified in [RFC5444]. Before transmission of a message, it is signed as described in Section 6.
This section specifies how to sign a message. Note that a message may be signed several times using different signature algorithms. The following constraints MUST be respected when signing a message:
Optionally:
For each signature algorithm that is used to sign the message:
NHDP specifies that
and gives a number of conditions that will lead to a rejection of the HELLO message if any of these conditions is true. The extension to NHDP, specified in this document, adds the following conditions for rejecting a message:
This section specifies how to validate a message timestamp.
This section specifies how to validate a message signature.
This document specifies the following parameters and constants:
The following constraints apply to these parameters:
Before a router is able to sign or validate messages, it must initially parameterize some security settings. In particular, it MUST acquire the cryptographic key(s) and any parameters of the cryptographic algorithm from all other routers that are to participate in the network. This document does not specify how a router acquires the cryptographic keys and parameters used in the MANET.
When the security mechanism as specified in this document is used, the following MUST be observed:
This section analyzes which of the security threats that are detailed in [NHDP-sec-threats] are alleviated by the framework presented in this document.
Since jamming is a physical layer issue, it cannot be alleviated by protocols on the routing layer. This framework does not counteract jamming attacks, therefore.
As only routers possessing valid cryptographic keys are able to correctly sig HELLO messages, identity spoofing is counteracted. If a router does not have access to valid keys or does not sign messages at all, it is not able to create HELLOs that are processed by neighbor routers. Such wrongly signed or unsigned messages are rejected by receiving routers as described in Section 9.
Link spoofing is counteracted by the framework specified in this document, with the same argument as in Section 13.2. A router without access to valid cryptographic keys cannot sign the message correctly, and therefore the message will be rejected by any receiving routers. Hence, all links postulated by an attacker are ignored.
Replay attacks are only counteracted if TIMESTAMP TLVs are included in HELLO messages. This is optional, and depends on synchronized clocks of all routers in the MANET. An attacker which records messages to replay them later can only do so in the time interval between the timestamp that is contained in the TIMESTAMP TLV and MAX_TIMESTAMP_DIFF seconds later. As an attacker cannot modify the content of the TIMESTAMP TLV (since it does not possess the valid cryptographic keys), it cannot replay messages after this time interval. Within this time interval, however, it is still possible to replay attacks.
This document has no actions for IANA.
This document specifies a protocol extension to NHDP which allows to alleviate some of the security threats of NHDP analyzed in [NHDP-sec-threats].
If no synchronized clocks are available in the MANET, replay attacks cannot be counteracted by this framework.
This framework does not avoid or detect security attacks by routers possessing the cryptographic keys that is used to sign messages.
This specification depends on the quality of the used signature algorithm and provides as such the same security considerations as the hash function and the cipher algorithm.
This specification relies on an out-of-band protocol to distribute keys and parameters. The security considerations of that protocol apply.
This specification does not provide a key revocation mechanism.
[packetbb-sec] | Herberg, U and T Clausen, "MANET Cryptographical Signature TLV Definition", work in progress draft-ietf-manet-packetbb-sec-05.txt, July 2011. |
[RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
[RFC6130] | Clausen, T., Dearlove, C. and J. Dean, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 6130, March 2011. |
[NHDP-sec-threats] | Herberg, U. and T.H. Clausen, "Security Threats for NHDP", work in progress draft-herberg-manet-nhdp-sec-threats-00.txt, November 2009. |
[RFC5444] | Clausen, T.H., Dearlove, C.M., Dean, J.W. and C. Adjih, "Generalized MANET Packet/Message Format", RFC 5444, February 2009. |