< draft-herberg-manet-nhdp-sec-01.txt   draft-herberg-manet-nhdp-sec-02.txt >
Mobile Ad hoc Networking (MANET) U. Herberg Mobile Ad hoc Networking (MANET) U. Herberg
Internet-Draft T. Clausen Internet-Draft T. Clausen
Intended status: Experimental LIX, Ecole Polytechnique Intended status: Experimental LIX, Ecole Polytechnique
Expires: September 30, 2011 March 29, 2011 Expires: January 9, 2012 July 8, 2011
Cryptographical Signatures in NHDP Cryptographical Signatures in NHDP
draft-herberg-manet-nhdp-sec-01 draft-herberg-manet-nhdp-sec-02
Abstract Abstract
This document specifies an extension to the Neighbor Discovery This document specifies an extension to the Neighbor Discovery
Protocol (NHDP) which uses cryptographic signatures in HELLO messages Protocol (NHDP) which uses cryptographic signatures in HELLO messages
to encounter a selection of security threats to NHDP. to encounter 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
skipping to change at page 1, line 32 skipping to change at page 1, line 32
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 September 30, 2011. This Internet-Draft will expire on January 9, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
skipping to change at page 2, line 23 skipping to change at page 2, line 23
7. Processing a Message . . . . . . . . . . . . . . . . . . . . . 5 7. Processing a Message . . . . . . . . . . . . . . . . . . . . . 5
8. Validating a Timestamp . . . . . . . . . . . . . . . . . . . . 6 8. Validating a Timestamp . . . . . . . . . . . . . . . . . . . . 6
9. Validating a Signature . . . . . . . . . . . . . . . . . . . . 6 9. Validating a Signature . . . . . . . . . . . . . . . . . . . . 6
10. Parameters and Constants . . . . . . . . . . . . . . . . . . . 7 10. Parameters and Constants . . . . . . . . . . . . . . . . . . . 7
11. Preconditions . . . . . . . . . . . . . . . . . . . . . . . . 7 11. Preconditions . . . . . . . . . . . . . . . . . . . . . . . . 7
12. Summary of NHDP Interaction . . . . . . . . . . . . . . . . . 7 12. Summary of NHDP Interaction . . . . . . . . . . . . . . . . . 7
13. Security Threats Alleviation Analysis . . . . . . . . . . . . 8 13. Security Threats Alleviation Analysis . . . . . . . . . . . . 8
13.1. Jamming . . . . . . . . . . . . . . . . . . . . . . . . . 8 13.1. Jamming . . . . . . . . . . . . . . . . . . . . . . . . . 8
13.2. Identity Spoofing . . . . . . . . . . . . . . . . . . . . 8 13.2. Identity Spoofing . . . . . . . . . . . . . . . . . . . . 8
13.3. Link Spoofing . . . . . . . . . . . . . . . . . . . . . . 8 13.3. Link Spoofing . . . . . . . . . . . . . . . . . . . . . . 8
13.4. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 8 13.4. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 9
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
15. Security Considerations . . . . . . . . . . . . . . . . . . . 9 15. Security Considerations . . . . . . . . . . . . . . . . . . . 9
16. Normative References . . . . . . . . . . . . . . . . . . . . . 9 16. Normative References . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
This document describes how to use cryptographic signatures for This document describes how to use cryptographic signatures 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 signatures for
validating the identity of the originator of a HELLO message, the validating the identity of the originator of a HELLO message, the
validity of the content (i.e. links being advertised) of a HELLO validity of the content (i.e. links being advertised) of a HELLO
message, and the message integrity. The protection so offered message, and 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 specifies TLVs for carrying cryptographic signatures in
HELLO messages using [RFC5444], and specifies extensions (as enabled HELLO messages using [RFC5444], and specifies extensions (as enabled
by [NHDP]) to the HELLO message processing in [NHDP]. by [RFC6130]) to the HELLO message processing in [RFC6130].
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], [NHDP] and [NHDP-sec-threats]. [packetbb-sec], [RFC6130] and [NHDP-sec-threats].
3. Applicability Statement 3. Applicability Statement
o [NHDP] enables extensions to recognize additional reasons for o [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 o This document, therefore, elaborates on how this in details can be
done, providing a framework for signing and validating messages in done, providing a framework for signing and validating messages in
NHDP. NHDP.
o Note that there is no "no one-size-fits-all", therefore this o Note that there is no "no one-size-fits-all", therefore this
document uses the containers for carrying signatures and document uses the containers for carrying signatures and
registries for cryptographic code-points as specified in registries for cryptographic code-points as specified in
skipping to change at page 4, line 11 skipping to change at page 4, line 11
o This document does not specify how to distribute cryptographic o This document does not specify how to distribute cryptographic
keys, shared secrets, parameters for signature algorithms, etc. keys, shared secrets, parameters for signature algorithms, etc.
o Note also that this document assumes that a router which is able o Note also that this document assumes that a router which is able
to sign messages correctly (e.g. having valid cryptographic keys), to sign messages correctly (e.g. having valid cryptographic keys),
is considered trusted. This document does not handle compromised is considered trusted. This document does not handle compromised
routers with valid keys (e.g. a router that is compromised by a routers with valid keys (e.g. a router that is compromised by a
computer virus). computer virus).
o This document assumes that the TLV type extension of the SIGNATURE
Message TLV, as defined in [packetbb-sec] is 1, i.e. that a
signature is composed of a cryptographic function over a hash
value of the message.
Therefore: Therefore:
o This document is generally applicable when [NHDP] is used, and o This document is generally applicable when [RFC6130] is used, and
uses the [RFC5444] extension specified in [packetbb-sec]. uses the [RFC5444] extension specified in [packetbb-sec].
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 Signing a HELLO message, and
o Checking whether a signed incoming HELLO message is valid. o Checking whether a signed incoming HELLO message is valid.
skipping to change at page 4, line 36 skipping to change at page 4, line 41
interface, this extension: interface, this extension:
o Specifies to calculate a digital signature of the message, and o Specifies to calculate a digital signature of the message, and
o Specifies how to add that signature to a message for transmission, o Specifies how to add that signature to a message for transmission,
by way of a SIGNATURE TLV. by way of a SIGNATURE TLV.
The framework allows to add several signatures with different hash The framework allows to add several signatures with different hash
and cryptographic functions. and cryptographic functions.
[NHDP] allows to reject incoming HELLO messages prior to processing [RFC6130] allows to reject incoming HELLO messages prior to
by NHDP for reasons such as invalid signatures. This extension processing by NHDP for reasons such as invalid signatures. This
specifies that for each SIGNATURE TLV in the Message TLV Block of extension specifies that for each SIGNATURE TLV in the Message TLV
that incoming message, the value of that TLV (i.e. the contained Block of that incoming message, the value of that TLV (i.e. the
signature) is verified. contained signature) is verified.
5. Transmitting a Message in NHDP 5. Transmitting a Message in NHDP
HELLO messages are generated as specified in [NHDP]. In addition, HELLO messages are generated as specified in [RFC6130]. In addition,
each HELLO message MUST set the <msg-orig-addr> as well as the <msg- 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 seq-num> field as specified in [RFC5444]. Before transmission of a
message, it is signed as described in Section 6. message, it is signed as described in Section 6.
6. Signing a Message 6. Signing a Message
This section specifies how to sign a message. Note that a message This section specifies how to sign a message. Note that a message
may be signed several times using different signature algorithms. may be signed several times using different signature algorithms.
The following constraints MUST be respected when signing a message: The following constraints MUST be respected when signing a message:
skipping to change at page 5, line 34 skipping to change at page 5, line 36
1. All TLVs of type SIGNATURE are temporarily removed from the 1. All TLVs of type SIGNATURE are temporarily removed from the
message and stored in temporary variables. The message size is message and stored in temporary variables. The message size is
recalculated accordingly, i.e. to the size of the message without recalculated accordingly, i.e. to the size of the message without
the SIGNATURE TLVs. the SIGNATURE TLVs.
2. The signature value is calculated over the whole message (as 2. The signature value is calculated over the whole message (as
resulting after step 1) according to the chosen signature resulting after step 1) according to the chosen signature
algorithm. algorithm.
3. A TLV of type SIGNATURE is added in the message TLV block. The 3. A TLV of type SIGNATURE and type extension 1 is added in the
TLV value is set to the signature calculated in step 2 as well as message TLV block. The TLV value is set to the signature
the chosen hash and cryptographic algorithms. calculated in step 2 as well as the chosen hash and cryptographic
algorithms.
4. All other SIGNATURE TLVs that have been temporary removed, are 4. All other SIGNATURE TLVs that have been temporary removed, are
restored. restored.
5. The message size is recalculated. 5. The message size is recalculated.
7. Processing a Message 7. Processing a Message
NHDP 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 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 HELLO message if any of these conditions is true. The extension to
NHDP, specified in this document, adds the following conditions for NHDP, specified in this document, adds the following conditions for
rejecting a message: rejecting a message:
o The message does not include the <msg-orig-addr> or the <msg-seq- o The message does not include the <msg-orig-addr> or the <msg-seq-
num> field. num> field.
skipping to change at page 6, line 30 skipping to change at page 6, line 35
1. If the message includes a TIMESTAMP Message TLV, and the value of 1. If the message includes a TIMESTAMP Message TLV, and the value of
the TIMESTAMP TLV differs from the current POSIX time of more the TIMESTAMP TLV differs from the current POSIX time of more
than MAX_TIMESTAMP_DIFF, the message MUST be discarded. than MAX_TIMESTAMP_DIFF, the message MUST be discarded.
9. Validating a Signature 9. Validating a Signature
This section specifies how to validate a message signature. This section specifies how to validate a message signature.
1. For all SIGNATURE Message TLVs: 1. For all SIGNATURE Message TLVs:
A. If the hash function and the cryptographic function defined A. If the TLV type extension is not 1, or if the hash function
in that TLV are known to the router: goto step 2. and the cryptographic function defined in that TLV are known
to the router: goto step 2.
B. Otherwise goto step 1 B. Otherwise goto step 1
2. If no signature algorithm has been recognized in step 1, the 2. If no signature algorithm has been recognized in step 1, the
message MUST be discarded. message MUST be discarded.
3. All SIGNATURE TLVs are removed from the message, and the message 3. All SIGNATURE TLVs are removed from the message, and the message
size is recalculated. size is recalculated.
4. The signature is recalculated using the same hash function and 4. The signature is recalculated using the same hash function and
skipping to change at page 7, line 9 skipping to change at page 7, line 14
step 3. step 3.
5. If the verification fails, the message MUST be discarded. 5. If the verification fails, the message MUST be discarded.
6. Otherwise: 6. Otherwise:
A. All SIGNATURE TLVs are restored. A. All SIGNATURE TLVs are restored.
B. The message size is restored. B. The message size is restored.
7. The message can now be processed according to [NHDP]. 7. The message can now be processed according to [RFC6130].
10. Parameters and Constants 10. Parameters and Constants
This document specifies the following parameters and constants: This document specifies the following parameters and constants:
o MAX_TIMESTAMP_DIFF - The maximum age a message that is to be o MAX_TIMESTAMP_DIFF - The maximum age a message that is to be
validated may have. If the current POSIX time of the router validated may have. If the current POSIX time of the router
validating the message minus the timestamp indicated in the validating the message minus the timestamp indicated in the
TIMESTAMP TLV of the message is greater than MAX_TIMESTAMP_DIFF, TIMESTAMP TLV of the message is greater than MAX_TIMESTAMP_DIFF,
the message will be discarded. the message will be discarded.
skipping to change at page 7, line 45 skipping to change at page 8, line 5
12. Summary of NHDP Interaction 12. Summary of NHDP Interaction
When the security mechanism as specified in this document is used, When the security mechanism as specified in this document is used,
the following MUST be observed: the following MUST be observed:
o NHDP must generate HELLO messages as usual. o NHDP must generate HELLO messages as usual.
o NHDP MUST allow this security mechanism access to the HELLO o NHDP MUST allow this security mechanism access to the HELLO
message after its generation and prior to transmission, in order message after its generation and prior to transmission, in order
that a SIGNATURE TLV can be generated and inserted, as allowed by that a SIGNATURE TLV can be generated and inserted, as allowed by
Section 16 in [NHDP]. Section 16 in [RFC6130].
o Any other NHDP extension which adds information to a HELLO message o Any other NHDP extension which adds information to a HELLO message
and which wishes this added information to be included when and which wishes this added information to be included when
calculating the cryptographic signature MUST do so prior to the calculating the cryptographic signature MUST do so prior to the
HELLO message being handed off for signature generation. 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 this
specification prior to processing by [NHDP] as allowed in Section specification prior to processing by [RFC6130] as allowed in
16 in [NHDP]. Section 16 in [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 a
cryptographic signature is not valid, MUST likewise process the cryptographic signature is not valid, MUST likewise process the
HELLO message only after its processing according to this HELLO message only after its processing according to this
specification. specification.
13. Security Threats Alleviation Analysis 13. Security Threats Alleviation Analysis
This section analyzes which of the security threats that are detailed This section analyzes which of the security threats that are detailed
skipping to change at page 9, line 40 skipping to change at page 9, line 46
the hash function and the cipher algorithm. the hash function and the cipher algorithm.
This specification relies on an out-of-band protocol to distribute This specification relies on an out-of-band protocol to distribute
keys and parameters. The security considerations of that protocol keys and parameters. The security considerations of that protocol
apply. apply.
This specification does not provide a key revocation mechanism. This specification does not provide a key revocation mechanism.
16. Normative References 16. Normative References
[NHDP] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
Network (MANET) Neighborhood Discovery Protocol (NHDP)",
RFC 6130, March 2011.
[NHDP-sec-threats] [NHDP-sec-threats]
Herberg, U. and T. Clausen, "Security Threats for NHDP", Herberg, U. and T. Clausen, "Security Threats for NHDP",
work in work in
progress draft-herberg-manet-nhdp-sec-threats-00.txt, progress draft-herberg-manet-nhdp-sec-threats-00.txt,
November 2009. November 2009.
[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
Network (MANET) Neighborhood Discovery Protocol (NHDP)",
RFC 6130, March 2011.
[packetbb-sec] [packetbb-sec]
Herberg, U. and T. Clausen, "MANET Cryptographical Herberg, U. and T. Clausen, "MANET Cryptographical
Signature TLV Definition", work in Signature TLV Definition", work in
progress draft-ietf-manet-packetbb-sec-03.txt, March 2011. progress draft-ietf-manet-packetbb-sec-04.txt, July 2011.
Authors' Addresses Authors' Addresses
Ulrich Herberg Ulrich Herberg
LIX, Ecole Polytechnique LIX, Ecole Polytechnique
91128 Palaiseau Cedex, 91128 Palaiseau Cedex,
France France
Email: ulrich@herberg.name Email: ulrich@herberg.name
URI: http://www.herberg.name/ URI: http://www.herberg.name/
 End of changes. 20 change blocks. 
29 lines changed or deleted 35 lines changed or added

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