Mobile Ad hoc Networking (MANET)                              U. Herberg
Internet-Draft                           Fujitsu Laboratories of America
Intended status: Standards Track                              T. Clausen
Expires: January 30, September 13, 2012                     LIX, Ecole Polytechnique
                                                           July 29, 2011

                   Cryptographical Signatures
                                                          March 12, 2012

          Using Integrity Check Values and Timestamps in NHDP


   This document specifies an a security extension to the MANET Neighbor
   Discovery Protocol (NHDP) which uses cryptographic signatures (NHDP).  The extension introduces the use of
   Integrity Check Values (ICVs) and Timestamps in HELLO messages in
   order to encounter counter a selection of security threats to NHDP.

Status of this Memo

   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

   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 30, September 13, 2012.

Copyright Notice

   Copyright (c) 2011 2012 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
   ( 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.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Applicability Statement  . . . . . . . . . . . . . . . . . . .  3
   4.  Protocol Overview and Functioning  . . . . . . . . . . . . . .  4
   5.  Transmitting a  HELLO Message in NHDP Content  . . . . . . . . . . . . . . . .  4
   6.  Signing a Message . . . .  5
   6.  HELLO Message Generation . . . . . . . . . . . . . . . . . . .  5
   7.  Processing a  HELLO Message Processing . . . . . . . . . . . . . . . . . . . . .  5  6
   8.  Validating a Timestamp ICVs  . . . . . . . . . . . . . . . . . . . . . . .  6
   9.  Validating a Signature Timestamp . . . . . . . . . . . . . . . . . . . .  6  7
   10. Parameters and Constants . . Provisioning of NHDP Routers . . . . . . . . . . . . . . . . .  7  8
   11. Preconditions  . . . . Summary of NHDP Interaction  . . . . . . . . . . . . . . . . .  8
   12. Security Threats Alleviation Analysis  . . .  7
   12. Summary of NHDP Interaction . . . . . . . . .  9
     12.1.  Jamming . . . . . . . .  7
   13. Security Threats Alleviation Analysis . . . . . . . . . . . .  8
     13.1.  Jamming . . . . .  9
     12.2.  Identity Spoofing . . . . . . . . . . . . . . . . . . . .  8
     13.2.  Identity  9
     12.3.  Link Spoofing . . . . . . . . . . . . . . . . . . . .  8
     13.3.  Link Spoofing . .  9
     12.4.  Replay Attack . . . . . . . . . . . . . . . . . . . .  8
     13.4.  Replay Attack . .  9
   13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   14. IANA Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   15. Acknowledgments  . .  9
   15. Security Considerations . . . . . . . . . . . . . . . . . . .  9 . . 10
   16. Normative References . . . . . . . . . . . . . . . . . . . . .  9 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 11

1.  Introduction

   This document describes how to specifies the use cryptographic signatures of Integrity Check Values (ICVs) in
   the MANET Neighborhood Discovery Protocol (NHDP) [RFC6130] for
   countering a selection of the security threats analyzed in
   [NHDP-sec-threats].  It specifies the use of such signatures ICVs for validating
   the identity of the originator of a HELLO message, the
   validity for validating of
   the content (i.e. (i.e., the links being advertised) of a HELLO message,
   and for validating the message integrity.  The protection so offered
   against the threats in [NHDP-sec-threats] is evaluated.

   This document specifies uses the TLVs for carrying cryptographic signatures defined in [packetbb-sec] within NHDP
   HELLO messages using [RFC5444], messages, and specifies extensions (as enabled by Section 16 in
   [RFC6130]) to the HELLO message processing in [RFC6130]. processing.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "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].

   Additionally, this document introduces the following terminology:

   NHDP Router:  A MANET router, running NHDP as specified in [RFC6130].

3.  Applicability Statement


   [RFC6130] enables extensions to recognize additional reasons for
   rejecting a message as malformed, and mentions security as an
   explicit example.


   This document, therefore, elaborates on how this in details can be
      done, document:

   o  Specifies an extension to [RFC6130] by providing a framework for signing and validating
      associating ICVs to messages in
      NHDP. and for using such invalid ICVs as
      one such "additional reason" for rejecting a message as malformed.

   o  Note that there is no "no one-size-fits-all", therefore this
      document uses  Uses the containers for carrying signatures ICVs and timestamps, as well as
      the registries for cryptographic code-points as code-points, specified in
      [packetbb-sec].  The specification should therefore be generally

   o  Is applicable where cryptographic signatures ICVs 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
      keys, shared secrets, parameters for signature algorithms, etc.

   o  Note also that this document assumes  Assumes that a router which is able to sign messages correctly (e.g. having generate correct ICVs
      (e.g., has valid cryptographic keys), is considered trusted.  This document does not handle compromised
      routers with valid keys (e.g. a router that is compromised by a
      computer virus).

   o  This document assumes  Assumes that the TLV type extension of the SIGNATURE ICV Message TLV, as
      defined in [packetbb-sec] is 1, i.e. i.e., that a
      signature an ICV is composed of a
      cryptographic function over a hash value of the message.


   o  This document is generally applicable when [RFC6130] is used, and
      uses the [RFC5444] extension specified message as defined
      in Section 12 of [packetbb-sec].

   This document does NOT:

   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

   The framework presented in this document provides two

   o  Signing a  Generation of an ICV for an outgoing HELLO message, and message.

   o  Checking whether a signed  Verification of an ICV in order to determine if an incoming HELLO
      message is valid. SHOULD be rejected as malformed.

   When a router running an NHDP is about to transmit Router generates a HELLO message on an interface, this

   o  Specifies how to calculate a digital signature of an ICV for the message, and message.

   o  Specifies how to add include that signature to a message for transmission, ICV by way of a SIGNATURE TLV.

   The framework allows to add several signatures ICVs with different hash and
   cryptographic functions.

   [RFC6130] allows to reject incoming HELLO messages prior to
   processing by NHDP for reasons such as invalid signatures. NHDP.  This extension specifies that for each SIGNATURE ICV TLV
   in the Message TLV Block of that an incoming message, the value of that TLV (i.e. message MUST be
   rejected if the
   contained signature) is ICV can not be verified.

5.  Transmitting a  HELLO Message in NHDP Content

   HELLO messages are MUST be generated as specified in [RFC6130].  In
   addition, in order to conform to this specification, each HELLO
   message MUST set the contain:

   o  A <msg-orig-addr> as well as the <msg-
   seq-num> field as element (as specified in [RFC5444].  Before transmission of a
   message, it is signed as described [RFC5444]).

   o  A <msg-seq-num> element (as specified in [RFC5444]).

   o  One, or more, ICV TLVs (as specified in [packetbb-sec]), generated
      according to Section 6.

6.  Signing a Message

   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

   If protection against replay attacks is desired, then a message:

   o  The originator address of the message MUST be included.

   o  The sequence number of the HELLO message
   MUST be included.

   Optionally: also contain:

   o  A TIMESTAMP TLV (as defined specified in [packetbb-sec]) MAY be added to [packetbb-sec]).

6.  HELLO Message Generation

   After the HELLO message if no such TLV is already included in the generation and before HELLO message TLV
      block of that message.  The value of
   transmission, as permitted by [RFC6130], the TIMESTAMP TLV is the
      current POSIX timestamp (32-bit) of the router, and the type
      extension is 1 (one).

   For additional elements
   specified in Section 5 MUST (unless already present) be added to an
   outgoing HELLO message.

   The following processing steps MUST be taken for each signature cryptographic
   algorithm that is used to sign the for generating ICVs for a HELLO message:

   1.  All existing TLVs (if any) of type SIGNATURE ICV are temporarily removed
       from the message.  Any temporarily removed TLVs MUST be stored,
       for being reinserted into the message and stored in temporary variables. step 5.

   2.  The message size is recalculated accordingly, i.e. to the size of the message
       without the SIGNATURE temporarily removed ICV TLVs.


   3.  The signature ICV value is calculated over the whole message (as resulting
       after step 1) 2) according to the chosen signature

   3. hash and cryptographic
       function and according to Section 12.1 of [packetbb-sec].

   4.  A TLV of type SIGNATURE ICV and with type extension 1 is added in the
       message TLV block.  The TLV value is set to the signature
       calculated in step 2 as well as block, with the chosen hash and cryptographic

   4. content according to Section 12.1 of

   5.  All other SIGNATURE ICV TLVs that have been temporary removed, are


   6.  The message size is recalculated. recalculated, including the new ICV TLV as
       well as any restored temporarily removed ICV TLVs.

7.  Processing a  HELLO Message

   NHDP Processing

   [RFC6130] specifies that that:

      "On receiving a HELLO message, a router MUST first check if the
      message is invalid for processing by this router"

   and gives

   [RFC6130] proceeds to give a number of conditions that that, each, will
   lead to a rejection of the HELLO message if any of these conditions is true.  The extension to
   NHDP, specified in this document, message.  This document adds the
   following conditions to that list which, if true, MUST cause NHDP to
   consider the HELLO message as invalid for
   rejecting a message: processing:

   o  The HELLO message does not include the a <msg-orig-addr> or the <msg-seq-
      num> field. element.

   o  The HELLO message does not include a <msg-seq-num> element.

   o  The Message TLV block of the HELLO message contains more than one
      TIMESTAMP TLV. TLV with the same "Type Extension".

   o  Any signature ICV in the Message TLV block of the HELLO message is invalid as specified in invalid,
      according to Section 9. 8.

   o  The timestamp value of the TIMESTAMP TLV of the message is invalid as
      specified in Section 8. 9.

8.  Validating a Timestamp

   This section specifies how to validate a ICVs

   The included ICVs in an incoming HELLO message timestamp. are processed as

   1.  If the message includes a TIMESTAMP  For each ICV Message TLV, and TLV in the value of HELLO message, the TIMESTAMP ICV TLV differs from the current POSIX time of more
       than MAX_TIMESTAMP_DIFF, the message MUST be discarded.

9.  Validating a Signature

   This section specifies how to validate a message signature.

   1.  For all SIGNATURE Message TLVs:

       A.  If the TLV type extension is not 1, or if is
       temporarily removed if:

       *  The ICV TLV "Type Extension" is not equal to 1; OR

       *  The ICV TLV "Type Extension" is equal to 1, AND the hash
          function and the cryptographic function defined indicated in that ICV
          TLV are known unknown to the router: goto step 2.

       B.  Otherwise goto step 1 NHDP Router.

   2.  If no signature algorithm has been recognized in ICV TLVs remain after step 1, validation fails and the
       message MUST be considered invalid for processing and MUST be

   3.  Otherwise, the message with the remaining ICV TLVs (henceforth:
       "Known ICV TLVs") is processed as follows:

       1.  All SIGNATURE Known ICV TLVs are temporarily removed from the message,
           and the message size is recalculated.

   4.  The signature is recalculated

       2.  Each of the temporarily removed Known ICV TLVs from the step
           above is, then, validated as follows:

           +  Calculate the message-hash-value over the HELLO message,
              using the same hash function and
       cryptographic function as indicated by <hash-function> in
              the TLV, ICV TLV.

           +  Calculate the message-ICV-Value over the resulting
              message-hash-value, using the cryptographic function, and compared with
              the signature key ID, indicated by <cryptographic-function> and
              <key-id> in the ICV TLV.

           +  If message-ICV-Value differs from the SIGNATURE TLV that has been removed value of <ICV-data>
       step 3.

   5.  If the verification fails, ICV, then the ICV validation has failed:

              -  The HELLO message MUST be considered invalid for
                 processing and MUST be discarded.

   6.  Otherwise:

   4.  Then:

       A.  All SIGNATURE temporarily removed ICV TLVs are restored. restored (i.e., all ICV
           TLVs temporarily removed in both step 1 and step 3).

       B.  The message size is restored.


   5.  The message can now be processed according to [RFC6130].

10.  Parameters and Constants

   This document specifies

9.  Validating a Timestamp

   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 following parameters and constants: HELLO message MUST
   be discarded.

   In order to undertake this validation, an NHDP Router which requires
   protection against replay attacks MUST:

   o  Be configured with a list of TIMESTAMP "Type Extensions", which it

   o  For each of these TIMESTAMP "Type Extensions", define
      MAX_TIMESTAMP_DIFF - The as the maximum age a allowed difference between the
      "expected timestamp value" and the "timestamp value" encoded in
      the TIMESTAMP TLV of an incoming HELLO message that is (e.g., to
      accommodate for propagation delays across a network).

   An incoming HELLO message MUST be
      validated may have.  If the current POSIX time considered invalid if:

   o  The Message TLV Block of the router
      validating the HELLO message minus does not contain a
      TIMESTAMP TLV with a "Type Extension" matching (one of) the
      timestamp indicated in 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 message is greater expected value by
      more than MAX_TIMESTAMP_DIFF,
      the message will be discarded.

   The following constraints apply to these parameters:


11.  Preconditions MAX_TIMESTAMP_DIFF.

10.  Provisioning of NHDP Routers

   Before a router an NHDP Router is able to sign generate ICVs 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


11.  Summary of NHDP Interaction

   When using the NHDP security mechanism as extension, specified in this document is used, document,
   the following MUST be observed:

   o  NHDP must generate  HELLO messages as usual.

   o  NHDP MUST allow this security mechanism access be generated according to the [RFC6130].

   o  Outgoing HELLO
      message messages, generated by [RFC6130] MUST be processed
      according to Section 6 after its their generation and prior to transmission, their
      transmission by [RFC6130], in order that a SIGNATURE TLV (an) ICV TLV(s) can be
      generated and inserted, as allowed by Section 16 in [RFC6130].

   o  Any other NHDP extension to [RFC6130] which adds information to a HELLO
      and which wishes this added information to be included when
      calculating the cryptographic signature MUST do so prior to the HELLO message being handed off for signature generation.
      ICV generation according to this specification.

   o  An incoming HELLO message MUST be processed according to this
      specification Section 7
      prior to processing by [RFC6130] as allowed in Section 16 in

   o  Any other NHDP extension, which has added information to a HELLO
      message and which wishes that the HELLO message is rejected if a
      cryptographic signature an
      ICV is not valid, MUST likewise process the HELLO message only
      after its processing according to this specification.


12.  Security Threats Alleviation Analysis

   This section analyzes briefly summarizes which of the security threats that are threats, from
   among those detailed in [NHDP-sec-threats] [NHDP-sec-threats], that are alleviated by
   the framework presented in this document.


12.1.  Jamming

   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.

13.2. attacks.

12.2.  Identity Spoofing

   As only routers NHDP Routers possessing valid cryptographic keys are able to
   correctly sig
   add ICV TLVs HELLO messages, in a way which permits that these be
   validated successfully, 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.


12.3.  Link Spoofing

   Link spoofing is counteracted by the framework specified in this
   document, with the same argument as in Section 13.2. 12.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

13.4. generate valid ICVs
   for inclusion in a HELLO message.

12.4.  Replay Attack

   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), keys for generating valid ICV TLVs), it cannot replay
   messages after this time interval.  Within this time interval,
   however, it is still possible to replay attacks.


13.  IANA Considerations

   This document has no actions for IANA.


14.  Security Considerations

   This document specifies a protocol extension to NHDP which allows to
   alleviate some of the security threats of NHDP analyzed in

   If no synchronized clocks are available in the MANET, replay attacks
   cannot be counteracted by the framework provided by this framework.

   This document.

   The framework provided by this document does not avoid or detect
   security attacks by routers possessing the cryptographic keys that is
   are used to sign generate ICVs for messages.

   This specification document depends on the quality of the used signature cipher algorithm and provides
   hash function, and is as such subject the same security
   considerations as
   the hash function and the cipher algorithm. applies to these.

   This specification document relies on an out-of-band protocol to distribute or mechanism for
   distributing keys and cryptographic parameters.  The security
   considerations of that such protocol or mechanism also apply.

   This specification 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

              Herberg, U. and T. U., Clausen, T., and J. Yi, "Security Threats for
              NHDP", work in
              progress draft-herberg-manet-nhdp-sec-threats-00.txt,
              November 2009. draft-herberg-manet-nhdp-sec-threats-01.txt,
              March 2012.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5444]  Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
              "Generalized MANET Packet/Message Format", RFC 5444,
              February 2009.

   [RFC6130]  Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
              Network (MANET) Neighborhood Discovery Protocol (NHDP)",
              RFC 6130, March 2011.

              Herberg, U. and T. Clausen, "MANET Cryptographical
              Signature "Integrity Check Value and
              Timestamp TLV Definition", Definitions for MANETs", work in
              progress draft-ietf-manet-packetbb-sec-05.txt, July 2011. draft-ietf-manet-packetbb-sec-09.txt, March 2012.

Authors' Addresses

   Ulrich Herberg
   Fujitsu Laboratories of America
   1240 E. Arques Ave. M/S 345
   Sunnyvale, CA, 94085,


   Thomas Heide Clausen
   LIX, Ecole Polytechnique
   91128 Palaiseau Cedex,

   Phone: +33 6 6058 9349