draft-ietf-manet-nhdp-sec-00.txt   draft-ietf-manet-nhdp-sec-01.txt 
Mobile Ad hoc Networking (MANET) U. Herberg Mobile Ad hoc Networking (MANET) U. Herberg
Internet-Draft Fujitsu Laboratories of America Internet-Draft Fujitsu Laboratories of America
Intended status: Standards Track T. Clausen Intended status: Standards Track T. Clausen
Expires: January 30, 2012 LIX, Ecole Polytechnique Expires: September 13, 2012 LIX, Ecole Polytechnique
July 29, 2011 March 12, 2012
Cryptographical Signatures in NHDP Using Integrity Check Values and Timestamps in NHDP
draft-ietf-manet-nhdp-sec-00 draft-ietf-manet-nhdp-sec-01
Abstract Abstract
This document specifies an extension to the Neighbor Discovery This document specifies a security extension to the MANET Neighbor
Protocol (NHDP) which uses cryptographic signatures in HELLO messages Discovery Protocol (NHDP). The extension introduces the use of
to encounter a selection of security threats to NHDP. Integrity Check Values (ICVs) and Timestamps in HELLO messages in
order to counter a selection of security threats to NHDP.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 January 30, 2012. This Internet-Draft will expire on September 13, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 3
4. Protocol Overview and Functioning . . . . . . . . . . . . . . 4 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 4
5. Transmitting a Message in NHDP . . . . . . . . . . . . . . . . 4 5. HELLO Message Content . . . . . . . . . . . . . . . . . . . . 5
6. Signing a Message . . . . . . . . . . . . . . . . . . . . . . 5 6. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 5
7. Processing a Message . . . . . . . . . . . . . . . . . . . . . 5 7. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 6
8. Validating a Timestamp . . . . . . . . . . . . . . . . . . . . 6 8. Validating ICVs . . . . . . . . . . . . . . . . . . . . . . . 6
9. Validating a Signature . . . . . . . . . . . . . . . . . . . . 6 9. Validating a Timestamp . . . . . . . . . . . . . . . . . . . . 7
10. Parameters and Constants . . . . . . . . . . . . . . . . . . . 7 10. Provisioning of NHDP Routers . . . . . . . . . . . . . . . . . 8
11. Preconditions . . . . . . . . . . . . . . . . . . . . . . . . 7 11. Summary of NHDP Interaction . . . . . . . . . . . . . . . . . 8
12. Summary of NHDP Interaction . . . . . . . . . . . . . . . . . 7 12. Security Threats Alleviation Analysis . . . . . . . . . . . . 9
13. Security Threats Alleviation Analysis . . . . . . . . . . . . 8 12.1. Jamming . . . . . . . . . . . . . . . . . . . . . . . . . 9
13.1. Jamming . . . . . . . . . . . . . . . . . . . . . . . . . 8 12.2. Identity Spoofing . . . . . . . . . . . . . . . . . . . . 9
13.2. Identity Spoofing . . . . . . . . . . . . . . . . . . . . 8 12.3. Link Spoofing . . . . . . . . . . . . . . . . . . . . . . 9
13.3. Link Spoofing . . . . . . . . . . . . . . . . . . . . . . 8 12.4. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 9
13.4. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 9 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 14. Security Considerations . . . . . . . . . . . . . . . . . . . 10
15. Security Considerations . . . . . . . . . . . . . . . . . . . 9 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
16. Normative References . . . . . . . . . . . . . . . . . . . . . 9 16. Normative References . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
This document describes how to use cryptographic signatures for This document specifies the use of Integrity Check Values (ICVs) in
the MANET Neighborhood Discovery Protocol (NHDP) [RFC6130] for
countering a selection of the security threats analyzed in countering a selection of the security threats analyzed in
[NHDP-sec-threats]. It specifies the use of such signatures for [NHDP-sec-threats]. It specifies the use of such ICVs for validating
validating the identity of the originator of a HELLO message, the the identity of the originator of a HELLO message, for validating of
validity of the content (i.e. links being advertised) of a HELLO the content (i.e., the links being advertised) of a HELLO message,
message, and the message integrity. The protection so offered and for validating the message integrity. The protection so offered
against the threats in [NHDP-sec-threats] is evaluated. against the threats in [NHDP-sec-threats] is evaluated.
This document specifies TLVs for carrying cryptographic signatures in This document uses the TLVs defined in [packetbb-sec] within NHDP
HELLO messages using [RFC5444], and specifies extensions (as enabled HELLO messages, and specifies extensions (as enabled by Section 16 in
by [RFC6130]) to the HELLO message processing in [RFC6130]. [RFC6130]) to the HELLO message processing.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119]. 2119 [RFC2119].
Additionally, this document uses the terminology of [RFC5444], Additionally, this document uses the terminology of [RFC5444],
[packetbb-sec], [RFC6130] and [NHDP-sec-threats]. [packetbb-sec], [RFC6130] and [NHDP-sec-threats].
Additionally, this document introduces the following terminology:
NHDP Router: A MANET router, running NHDP as specified in [RFC6130].
3. Applicability Statement 3. Applicability Statement
o [RFC6130] enables extensions to recognize additional reasons for [RFC6130] enables extensions to recognize additional reasons for
rejecting a message as malformed, and mentions security as an rejecting a message as malformed, and mentions security as an
explicit example. explicit example.
o This document, therefore, elaborates on how this in details can be This document:
done, providing a framework for signing and validating messages in
NHDP.
o Note that there is no "no one-size-fits-all", therefore this o Specifies an extension to [RFC6130] by providing a framework for
document uses the containers for carrying signatures and associating ICVs to messages and for using such invalid ICVs as
registries for cryptographic code-points as specified in one such "additional reason" for rejecting a message as malformed.
[packetbb-sec]. The specification should therefore be generally
be applicable where cryptographic signatures are thought an
appropriate security solution. Note that the the choice of the
cryptographic algorithm are to be made for each given deployment,
and that the choice of such is out of scope for this document.
o This document does not specify how to distribute cryptographic o Uses the containers for carrying ICVs and timestamps, as well as
keys, shared secrets, parameters for signature algorithms, etc. the registries for cryptographic code-points, specified in
[packetbb-sec].
o Note also that this document assumes that a router which is able o Is applicable where ICVs are an appropriate security solution.
to sign messages correctly (e.g. having valid cryptographic keys), Note that the choice of the cryptographic algorithm are to be made
is considered trusted. This document does not handle compromised for each given deployment, and that the choice of such is out of
routers with valid keys (e.g. a router that is compromised by a scope for this document.
computer virus).
o This document assumes that the TLV type extension of the SIGNATURE o Assumes that a router which is able to generate correct ICVs
Message TLV, as defined in [packetbb-sec] is 1, i.e. that a (e.g., has valid cryptographic keys), is considered trusted.
signature is composed of a cryptographic function over a hash
value of the message.
Therefore: o Assumes that the TLV type extension of the ICV Message TLV, as
defined in [packetbb-sec] is 1, i.e., that an ICV is composed of a
cryptographic function over a hash value of the message as defined
in Section 12 of [packetbb-sec].
o This document is generally applicable when [RFC6130] is used, and This document does NOT:
uses the [RFC5444] extension specified in [packetbb-sec].
o Specify how to distribute cryptographic keys, shared secrets,
parameters for cryptographic algorithms, etc.
o Specify how to detect compromised routers with valid keys.
o Specify how to handle compromised routers with valid keys, i.e.,
key-revocation etc.
4. Protocol Overview and Functioning 4. Protocol Overview and Functioning
The framework presented in this document provides two The framework presented in this document provides two
functionalities: functionalities:
o Signing a HELLO message, and o Generation of an ICV for an outgoing HELLO message.
o Checking whether a signed incoming HELLO message is valid. o Verification of an ICV in order to determine if an incoming HELLO
message SHOULD be rejected as malformed.
When a router running NHDP is about to transmit a HELLO message on an When an NHDP Router generates a HELLO message on an interface, this
interface, this extension: extension:
o Specifies to calculate a digital signature of the message, and o Specifies how to calculate an ICV for the message.
o Specifies how to add that signature to a message for transmission, o Specifies how to include that ICV by way of a TLV.
by way of a SIGNATURE TLV.
The framework allows to add several signatures with different hash The framework allows to add several ICVs with different hash and
and cryptographic functions. cryptographic functions.
[RFC6130] allows to reject incoming HELLO messages prior to [RFC6130] allows to reject incoming HELLO messages prior to
processing by NHDP for reasons such as invalid signatures. This processing by NHDP. This extension specifies that for each ICV TLV
extension specifies that for each SIGNATURE TLV in the Message TLV in the Message TLV Block of an incoming message, the message MUST be
Block of that incoming message, the value of that TLV (i.e. the rejected if the ICV can not be verified.
contained signature) is verified.
5. Transmitting a Message in NHDP 5. HELLO Message Content
HELLO messages are generated as specified in [RFC6130]. In addition, HELLO messages MUST be generated as specified in [RFC6130]. In
each HELLO message MUST set the <msg-orig-addr> as well as the <msg- addition, in order to conform to this specification, each HELLO
seq-num> field as specified in [RFC5444]. Before transmission of a message MUST contain:
message, it is signed as described in Section 6.
6. Signing a Message o A <msg-orig-addr> element (as specified in [RFC5444]).
This section specifies how to sign a message. Note that a message o A <msg-seq-num> element (as specified in [RFC5444]).
may be signed several times using different signature algorithms.
The following constraints MUST be respected when signing a message:
o The originator address of the message MUST be included. o One, or more, ICV TLVs (as specified in [packetbb-sec]), generated
according to Section 6.
o The sequence number of the message MUST be included. If protection against replay attacks is desired, then a HELLO message
MUST also contain:
Optionally: o A TIMESTAMP TLV (as specified in [packetbb-sec]).
o A TIMESTAMP TLV (as defined in [packetbb-sec]) MAY be added to the 6. HELLO Message Generation
message if no such TLV is already included in the message TLV
block of that message. The value of the TIMESTAMP TLV is the
current POSIX timestamp (32-bit) of the router, and the type
extension is 1 (one).
For each signature algorithm that is used to sign the message: After the HELLO message generation and before HELLO message
transmission, as permitted by [RFC6130], the additional elements
specified in Section 5 MUST (unless already present) be added to an
outgoing HELLO message.
1. All TLVs of type SIGNATURE are temporarily removed from the The following processing steps MUST be taken for each cryptographic
message and stored in temporary variables. The message size is algorithm that is used for generating ICVs for a HELLO message:
recalculated accordingly, i.e. to the size of the message without
the SIGNATURE TLVs.
2. The signature value is calculated over the whole message (as 1. All existing TLVs (if any) of type ICV are temporarily removed
resulting after step 1) according to the chosen signature from the message. Any temporarily removed TLVs MUST be stored,
algorithm. for being reinserted into the message in step 5.
3. A TLV of type SIGNATURE and type extension 1 is added in the 2. The message size is recalculated to the size of the message
message TLV block. The TLV value is set to the signature without the temporarily removed ICV TLVs.
calculated in step 2 as well as the chosen hash and cryptographic
algorithms.
4. All other SIGNATURE TLVs that have been temporary removed, are 3. The ICV value is calculated over the whole message (as resulting
after step 2) according to the chosen hash and cryptographic
function and according to Section 12.1 of [packetbb-sec].
4. A TLV of type ICV and with type extension 1 is added in the
message TLV block, with the content according to Section 12.1 of
[packetbb-sec].
5. All other ICV TLVs that have been temporary removed, are
restored. restored.
5. The message size is recalculated. 6. The message size is recalculated, including the new ICV TLV as
well as any restored temporarily removed ICV TLVs.
7. Processing a Message 7. HELLO Message Processing
[RFC6130] specifies that:
NHDP specifies that
"On receiving a HELLO message, a router MUST first check if the "On receiving a HELLO message, a router MUST first check if the
message is invalid for processing by this router" message is invalid for processing by this router"
and gives a number of conditions that will lead to a rejection of the [RFC6130] proceeds to give a number of conditions that, each, will
HELLO message if any of these conditions is true. The extension to lead to a rejection of the HELLO message. This document adds the
NHDP, specified in this document, adds the following conditions for following conditions to that list which, if true, MUST cause NHDP to
rejecting a message: consider the HELLO message as invalid for processing:
o The message does not include the <msg-orig-addr> or the <msg-seq- o The HELLO message does not include a <msg-orig-addr> element.
num> field.
o The message contains more than one TIMESTAMP TLV. o The HELLO message does not include a <msg-seq-num> element.
o Any signature of the message is invalid as specified in Section 9. o The Message TLV block of the HELLO message contains more than one
TIMESTAMP TLV with the same "Type Extension".
o The timestamp of the message is invalid as specified in Section 8. o Any ICV in the Message TLV block of the HELLO message is invalid,
according to Section 8.
8. Validating a Timestamp o The value of the TIMESTAMP TLV of the message is invalid as
specified in Section 9.
This section specifies how to validate a message timestamp. 8. Validating ICVs
1. If the message includes a TIMESTAMP Message TLV, and the value of The included ICVs in an incoming HELLO message are processed as
the TIMESTAMP TLV differs from the current POSIX time of more follows:
than MAX_TIMESTAMP_DIFF, the message MUST be discarded.
9. Validating a Signature 1. For each ICV Message TLV in the HELLO message, the ICV TLV is
temporarily removed if:
This section specifies how to validate a message signature. * The ICV TLV "Type Extension" is not equal to 1; OR
1. For all SIGNATURE Message TLVs: * The ICV TLV "Type Extension" is equal to 1, AND the hash
function and the cryptographic function indicated in that ICV
TLV are unknown to the NHDP Router.
A. If the TLV type extension is not 1, or if the hash function 2. If no ICV TLVs remain after step 1, validation fails and the
and the cryptographic function defined in that TLV are known message MUST be considered invalid for processing and MUST be
to the router: goto step 2. discarded.
B. Otherwise goto step 1 3. Otherwise, the message with the remaining ICV TLVs (henceforth:
"Known ICV TLVs") is processed as follows:
2. If no signature algorithm has been recognized in step 1, the 1. All Known ICV TLVs are temporarily removed from the message,
message MUST be discarded. and the message size is recalculated.
3. All SIGNATURE TLVs are removed from the message, and the message 2. Each of the temporarily removed Known ICV TLVs from the step
size is recalculated. above is, then, validated as follows:
4. The signature is recalculated using the same hash function and + Calculate the message-hash-value over the HELLO message,
cryptographic function as indicated in the TLV, and compared with using the hash function indicated by <hash-function> in
the signature from the SIGNATURE TLV that has been removed in the ICV TLV.
step 3.
5. If the verification fails, the message MUST be discarded. + Calculate the message-ICV-Value over the resulting
message-hash-value, using the cryptographic function, and
the key ID, indicated by <cryptographic-function> and
<key-id> in the ICV TLV.
6. Otherwise: + If message-ICV-Value differs from the value of <ICV-data>
in the ICV, then the ICV validation has failed:
A. All SIGNATURE TLVs are restored. - The HELLO message MUST be considered invalid for
processing and MUST be discarded.
4. Then:
A. All temporarily removed ICV TLVs are restored (i.e., all ICV
TLVs temporarily removed in both step 1 and step 3).
B. The message size is restored. B. The message size is restored.
7. The message can now be processed according to [RFC6130]. 5. The message can now be processed according to [RFC6130].
10. Parameters and Constants 9. Validating a Timestamp
This document specifies the following parameters and constants: If an NHDP Router is configured to require protection against replay
attacks, then TIMESTAMP TLVs in incoming HELLO messages MUST be
validated. Unless this validation succeeds, the HELLO message MUST
be discarded.
o MAX_TIMESTAMP_DIFF - The maximum age a message that is to be In order to undertake this validation, an NHDP Router which requires
validated may have. If the current POSIX time of the router protection against replay attacks MUST:
validating the message minus the timestamp indicated in the
TIMESTAMP TLV of the message is greater than MAX_TIMESTAMP_DIFF,
the message will be discarded.
The following constraints apply to these parameters: o Be configured with a list of TIMESTAMP "Type Extensions", which it
supports.
o MAX_TIMESTAMP_DIFF > 0 o For each of these TIMESTAMP "Type Extensions", define
MAX_TIMESTAMP_DIFF as the maximum allowed difference between the
"expected timestamp value" and the "timestamp value" encoded in
the TIMESTAMP TLV of an incoming HELLO message (e.g., to
accommodate for propagation delays across a network).
11. Preconditions An incoming HELLO message MUST be considered invalid if:
Before a router is able to sign or validate messages, it must o The Message TLV Block of the HELLO message does not contain a
initially parameterize some security settings. In particular, it TIMESTAMP TLV with a "Type Extension" matching (one of) the
MUST acquire the cryptographic key(s) and any parameters of the timestamp types, known by the receiving NHDP Router.
o The Message TLV Block of the HELLO message does contain a
TIMESTAMP TLV with a Type Extension matching (one of) the
timestamp types, known by the receiving NHDP Router, but where the
value of that TIMESTAMP TLV differs from the expected value by
more than MAX_TIMESTAMP_DIFF.
10. Provisioning of NHDP Routers
Before an NHDP Router is able to generate ICVs or validate messages,
it MUST acquire the cryptographic key(s) and any parameters of the
cryptographic algorithm from all other routers that are to cryptographic algorithm from all other routers that are to
participate in the network. This document does not specify how a participate in the network. This document does not specify how a
router acquires the cryptographic keys and parameters used in the router acquires the cryptographic keys and parameters used in the
MANET. MANET.
12. Summary of NHDP Interaction 11. Summary of NHDP Interaction
When the security mechanism as specified in this document is used, When using the NHDP security extension, specified in this document,
the following MUST be observed: the following MUST be observed:
o NHDP must generate HELLO messages as usual. o HELLO messages MUST be generated according to [RFC6130].
o NHDP MUST allow this security mechanism access to the HELLO o Outgoing HELLO messages, generated by [RFC6130] MUST be processed
message after its generation and prior to transmission, in order according to Section 6 after their generation and prior to their
that a SIGNATURE TLV can be generated and inserted, as allowed by transmission by [RFC6130], in order that (an) ICV TLV(s) can be
Section 16 in [RFC6130]. generated and inserted, as allowed by Section 16 in [RFC6130].
o Any other NHDP extension which adds information to a HELLO message o Any other extension to [RFC6130] which adds information to a HELLO
and which wishes this added information to be included when message MUST do so prior to the HELLO message being handed off for
calculating the cryptographic signature MUST do so prior to the ICV generation according to this specification.
HELLO message being handed off for signature generation.
o An incoming HELLO message MUST be processed according to this o An incoming HELLO message MUST be processed according to Section 7
specification prior to processing by [RFC6130] as allowed in prior to processing by [RFC6130] as allowed in Section 16 in
Section 16 in [RFC6130]. [RFC6130].
o Any other NHDP extension, which has added information to a HELLO o Any other NHDP extension, which has added information to a HELLO
message and which wishes that the HELLO message is rejected if a message and which wishes that the HELLO message is rejected if an
cryptographic signature is not valid, MUST likewise process the ICV is not valid, MUST likewise process the HELLO message only
HELLO message only after its processing according to this after its processing according to this specification.
specification.
13. Security Threats Alleviation Analysis 12. Security Threats Alleviation Analysis
This section analyzes which of the security threats that are detailed This section briefly summarizes which of the security threats, from
in [NHDP-sec-threats] are alleviated by the framework presented in among those detailed in [NHDP-sec-threats], that are alleviated by
this document. the framework presented in this document.
13.1. Jamming 12.1. Jamming
Since jamming is a physical layer issue, it cannot be alleviated by Since jamming is a physical layer issue, it cannot be alleviated by
protocols on the routing layer. This framework does not counteract protocols on the routing layer. This framework does not counteract
jamming attacks, therefore. jamming attacks.
13.2. Identity Spoofing 12.2. Identity Spoofing
As only routers possessing valid cryptographic keys are able to As only NHDP Routers possessing valid cryptographic keys are able to
correctly sig HELLO messages, identity spoofing is counteracted. If add ICV TLVs HELLO messages, in a way which permits that these be
a router does not have access to valid keys or does not sign messages validated successfully, identity spoofing is counteracted.
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.
13.3. Link Spoofing 12.3. Link Spoofing
Link spoofing is counteracted by the framework specified in this Link spoofing is counteracted by the framework specified in this
document, with the same argument as in Section 13.2. A router document, with the same argument as in Section 12.2. A router
without access to valid cryptographic keys cannot sign the message without access to valid cryptographic keys cannot generate valid ICVs
correctly, and therefore the message will be rejected by any for inclusion in a HELLO message.
receiving routers. Hence, all links postulated by an attacker are
ignored.
13.4. Replay Attack 12.4. Replay Attack
Replay attacks are only counteracted if TIMESTAMP TLVs are included Replay attacks are only counteracted if TIMESTAMP TLVs are included
in HELLO messages. This is optional, and depends on synchronized in HELLO messages. This is optional, and depends on synchronized
clocks of all routers in the MANET. An attacker which records clocks of all routers in the MANET. An attacker which records
messages to replay them later can only do so in the time interval messages to replay them later can only do so in the time interval
between the timestamp that is contained in the TIMESTAMP TLV and between the timestamp that is contained in the TIMESTAMP TLV and
MAX_TIMESTAMP_DIFF seconds later. As an attacker cannot modify the MAX_TIMESTAMP_DIFF seconds later. As an attacker cannot modify the
content of the TIMESTAMP TLV (since it does not possess the valid content of the TIMESTAMP TLV (since it does not possess the valid
cryptographic keys), it cannot replay messages after this time cryptographic keys for generating valid ICV TLVs), it cannot replay
interval. Within this time interval, however, it is still possible messages after this time interval. Within this time interval,
to replay attacks. however, it is still possible to replay attacks.
14. IANA Considerations 13. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
15. Security Considerations 14. Security Considerations
This document specifies a protocol extension to NHDP which allows to This document specifies a protocol extension to NHDP which allows to
alleviate some of the security threats of NHDP analyzed in alleviate some of the security threats of NHDP analyzed in
[NHDP-sec-threats]. [NHDP-sec-threats].
If no synchronized clocks are available in the MANET, replay attacks If no synchronized clocks are available in the MANET, replay attacks
cannot be counteracted by this framework. cannot be counteracted by the framework provided by this document.
This framework does not avoid or detect security attacks by routers The framework provided by this document does not avoid or detect
possessing the cryptographic keys that is used to sign messages. security attacks by routers possessing the cryptographic keys that
are used to generate ICVs for messages.
This specification depends on the quality of the used signature This document depends on the quality of the used cipher algorithm and
algorithm and provides as such the same security considerations as hash function, and is as such subject the same security
the hash function and the cipher algorithm. considerations as applies to these.
This specification relies on an out-of-band protocol to distribute This document relies on an out-of-band protocol or mechanism for
keys and parameters. The security considerations of that protocol distributing keys and cryptographic parameters. The security
apply. considerations of such protocol or mechanism also apply.
This specification does not provide a key revocation mechanism. This document does also not provide a key revocation mechanism.
15. Acknowledgments
The authors would like to thank Jiazi Yi (Ecole Polytechnique) for
his review and comments to this document.
16. Normative References 16. Normative References
[NHDP-sec-threats] [NHDP-sec-threats]
Herberg, U. and T. Clausen, "Security Threats for NHDP", Herberg, U., Clausen, T., and J. Yi, "Security Threats for
work in NHDP", work in
progress draft-herberg-manet-nhdp-sec-threats-00.txt, progress draft-herberg-manet-nhdp-sec-threats-01.txt,
November 2009. March 2012.
[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.
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
"Generalized MANET Packet/Message Format", RFC 5444, "Generalized MANET Packet/Message Format", RFC 5444,
February 2009. February 2009.
[RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
Network (MANET) Neighborhood Discovery Protocol (NHDP)", Network (MANET) Neighborhood Discovery Protocol (NHDP)",
RFC 6130, March 2011. RFC 6130, March 2011.
[packetbb-sec] [packetbb-sec]
Herberg, U. and T. Clausen, "MANET Cryptographical Herberg, U. and T. Clausen, "Integrity Check Value and
Signature TLV Definition", work in Timestamp TLV Definitions for MANETs", work in
progress draft-ietf-manet-packetbb-sec-05.txt, July 2011. progress draft-ietf-manet-packetbb-sec-09.txt, March 2012.
Authors' Addresses Authors' Addresses
Ulrich Herberg Ulrich Herberg
Fujitsu Laboratories of America Fujitsu Laboratories of America
1240 E. Arques Ave. M/S 345 1240 E. Arques Ave.
Sunnyvale, CA, 94085, Sunnyvale, CA, 94085,
USA USA
Email: ulrich@herberg.name Email: ulrich@herberg.name
URI: http://www.herberg.name/ URI: http://www.herberg.name/
Thomas Heide Clausen Thomas Heide Clausen
LIX, Ecole Polytechnique LIX, Ecole Polytechnique
91128 Palaiseau Cedex, 91128 Palaiseau Cedex,
France France
 End of changes. 95 change blocks. 
215 lines changed or deleted 254 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/