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

  Using Integrity Check Values and Timestamps For Router Admittance in
                                  NHDP
                      draft-ietf-manet-nhdp-sec-01
                      draft-ietf-manet-nhdp-sec-02

Abstract

   This document specifies a security extension to the MANET Neighbor
   Neighborhood Discovery Protocol (NHDP).  The extension introduces the
   use of Integrity Check Values (ICVs) and Timestamps in HELLO messages
   in order to provide a router admittance mechanism, and therefore to
   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 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 September 13, November 30, 2012.

Copyright Notice

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

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3  4
   3.  Applicability Statement  . . . . . . . . . . . . . . . . . . .  3  4
   4.  Protocol Overview and Functioning  . . . . . . . . . . . . . .  4  5
   5.  HELLO Message Content  . . . . . . . . . . . . . . . . . . . .  5
   6.  HELLO Message Generation . . . . . . . . . . . . . . . . . . .  5  6
   7.  HELLO Message Processing . . . . . . . . . . . . . . . . . . .  6
   8.  Validating
     7.1.  Invalidating a Message Based on ICVs . . . . . . . . . . .  7
     7.2.  Invalidating a Message Based on Timestamps . . . . . . . .  8
   8.  Provisioning of NHDP Routers . . . .  6
   9.  Validating a Timestamp . . . . . . . . . . . . . .  9
   9.  Summary of NHDP Interaction  . . . . . .  7
   10. Provisioning of NHDP Routers . . . . . . . . . . .  9
   10. IANA Considerations  . . . . . .  8
   11. Summary of NHDP Interaction . . . . . . . . . . . . . . .  9
   11. Security Considerations  . .  8
   12. Security Threats Alleviation Analysis . . . . . . . . . . . .  9
     12.1.  Jamming . . . . .  9
     11.1. Alleviated Attacks . . . . . . . . . . . . . . . . . . . .  9
     12.2. 10
       11.1.1.  Identity Spoofing . . . . . . . . . . . . . . . . . . . .  9
     12.3. 10
       11.1.2.  Link Spoofing . . . . . . . . . . . . . . . . . . . . . .  9
     12.4. 10
       11.1.3.  Replay Attack . . . . . . . . . . . . . . . . . . . . 10
     11.2. Limitations  . .  9
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  9
   14. Security Considerations 10
   12. Acknowledgments  . . . . . . . . . . . . . . . . . . . 10
   15. Acknowledgments . . . . 11
   13. References . . . . . . . . . . . . . . . . . . . 10
   16. . . . . . . . 11
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 11
     13.2. Informative References . . 10 . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11

1.  Introduction

   This document specifies the use of Integrity Check Values (ICVs) for
   router admittance in the MANET Neighborhood Discovery Protocol (NHDP) [RFC6130] for
   countering a selection of the security threats analyzed in
   [NHDP-sec-threats].
   [RFC6130].  It specifies the use of such ICVs for validating the
   identity of the originator of a HELLO message, for validating of the
   content (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 uses the TLVs defined in [packetbb-sec] [RFC6622] within NHDP HELLO
   messages, and specifies extensions (as enabled by Section 16 in
   [RFC6130]) to the HELLO message processing.

   Schematically, the mechanism specified in this document inserts
   itself between [RFC6130] processing/generation of HELLO messages and
   [RFC5444] encoding/decoding as illustrated in Figure 1.

                  Incoming  |                          |  Outgoing
             HELLO Message  |                         /|\ HELLO Message
                            |                          |
                            |                          |
                           \|/                         |
                            |                          |
                         +--------------------------------+
                         |                                |
                         |   RFC5444 Parser / Generator   |
                         |                                |
                         +--------------------------------+
                             |                          |
              Hello Message \|/                        /|\ RFC6622 ICVs
                     Parsed  |                          |  added
   D                     +--------------------------------+
   R  /_________________ |                                |
   O  \ICV not           |       This Specification       |
   P   Verified          |                                |
                         +--------------------------------+
                            |                          |
             ICV verified  \|/                        /|\ HELLO Message
                            |                          |  Generated
                         +--------------------------------+
                         |                                |
                         |            RFC6130             |
                         |      Processing/Generation     |
                         +--------------------------------+

             Figure 1: Relationship with RFC5444 and RFC6130.

2.  Terminology

   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]
   [RFC6130], and [NHDP-sec-threats]. [RFC6622].

   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, "badly formed and therefore invalid for
   processing", and mentions security as an explicit example.

   This document:

   o  Specifies an extension to [RFC6130] by providing a framework for
      associating ICVs to messages and for using such invalid ICVs as
      one such "additional reason" for rejecting a message as malformed. "badly
      formed and therefore invalid for processing".

   o  Uses the containers for carrying ICVs and timestamps, as well as
      the registries for cryptographic code-points, specified in
      [packetbb-sec].
      [RFC6622].

   o  Is applicable where ICVs are an appropriate security solution.
      Note that the choice of the cryptographic algorithm function are to be made
      for each given deployment, and that the choice of such is out of
      scope for this document.

   o  Assumes that a router which is able to generate correct ICVs
      (e.g., has valid cryptographic keys), is considered trusted.

   o  Assumes that the TLV type extension of the ICV Message TLV, as
      defined in [packetbb-sec] [RFC6622] 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]. [RFC6622].

   This document does NOT:

   o  Specify how to distribute cryptographic keys, shared secrets,
      parameters for cryptographic algorithms, functions, 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
   functionalities:

   o  Generation of an ICV for an outgoing HELLO message.

   o  Verification of an ICV in order to determine if an incoming HELLO
      message SHOULD MUST be rejected as malformed. "badly formed and therefore invalid
      for processing" [RFC6130].

   When an NHDP Router generates a HELLO message on an interface, this
   extension:

   o  Specifies how to calculate an ICV for the message.

   o  Specifies how to include that ICV by way of a TLV.

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

   [RFC6130] allows to reject for rejecting incoming HELLO messages prior to
   processing by NHDP.  This extension specifies that for each ICV TLV
   in the Message TLV Block of an incoming message, the message MUST be
   rejected if the ICV can not be verified.

5.  HELLO Message Content

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

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

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

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

   If protection against replay attacks is desired, then a HELLO message
   MUST also contain:

   o  A TIMESTAMP TLV (as specified in [packetbb-sec]). [RFC6622]).

6.  HELLO Message Generation

   After the HELLO message generation ([RFC6130] Section 11.1) and before
   HELLO message
   transmission, transmission ([RFC6130] Section 11.2), as permitted by [RFC6130],
   [RFC6130] Section 12.1, the 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 cryptographic
   algorithm that is used for generating ICVs for a HELLO message:

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

   2.  The message size is recalculated to the size of the message
       without the temporarily removed ICV TLVs.

   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]. [RFC6622].

   4.  A TLV of type ICV and with type extension 1 is added in the
       message
       Message TLV block, with the content according to Section 12.1 of
       [packetbb-sec].
       [RFC6622].

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

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

7.  HELLO Message Processing

   [RFC6130] specifies that:

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

   [RFC6130] proceeds to give a number of conditions that, each, will
   lead to a rejection of the HELLO message. message as "badly formed and
   therefore invalid for processing".  This document adds the following
   conditions to that list which, if true, MUST cause NHDP to consider
   the HELLO message as invalid for processing:

   o  The HELLO message does not include a <msg-orig-addr> 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 with the same "Type Extension". type extension.

   o  Any ICV  Validation of ICVs in the Message TLV block of the HELLO message is invalid,
      fails, according to Section 8. 7.1.

   o  The value  If protection against replay attacks is desired, validation of the
      TIMESTAMP TLV of the message is invalid as
      specified in fails, according to Section 9.

8.  Validating ICVs

   The included 7.2.

7.1.  Invalidating a Message Based on ICVs in an incoming HELLO message are processed as
   follows:

   1.  For each ICV Message TLV in the HELLO message, the ICV TLV is
       temporarily removed if:

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

       *  The ICV Message TLV "Type Extension" type extension is equal to 1, AND the hash
          function and the cryptographic function indicated in that ICV
          Messsage TLV are unknown to the NHDP Router.

   2.  If no ICV Message TLVs remain after step 1, then validation fails and the
       fails:

       *  The HELLO message MUST be considered "badly formed and
          therefore invalid for processing processing", and MUST be discarded.

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

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

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

           +  Calculate the message-hash-value over the HELLO message,
              using the hash function indicated by <hash-function> in
              the Known ICV Message TLV.

           +  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 Known ICV Message TLV.

           +  If message-ICV-Value differs from the value of <ICV-data>
              in the ICV, then the Known ICV Message TLV, then validation has failed: fails:

              -  The HELLO message MUST be considered "badly formed and
                 therefore invalid for
                 processing processing", and MUST be
                 discarded.

   4.  Then:  Otherwise, the message is considered (with respect to this
       specification) "valid for processing", and:

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

       B.  The message size is restored.

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

9.  Validating

7.2.  Invalidating 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 HELLO message MUST
   be discarded.

   In order to undertake this validation, an Message Based on Timestamps

   An NHDP Router which requires protection against replay attacks MUST:

   o  Be configured with a list of TIMESTAMP "Type Extensions", type extensions, which it
      supports.

   o  For each of these TIMESTAMP "Type Extensions", 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).

   An incoming

   A HELLO message MUST be considered "badly formed and therefore
   invalid if: for processing", and MUST be discarded if either of the two
   following conditions are true:

   o  The Message TLV Block of the HELLO message does not contain a
      TIMESTAMP TLV with a "Type Extension" type extension matching (one 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 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.

8.  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 function 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.

11.

9.  Summary of NHDP Interaction

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

   o  HELLO messages MUST be generated according to [RFC6130].

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

   o  Any other extension to [RFC6130] which adds information to a HELLO
      message MUST do so prior to the HELLO message being handed off for
      ICV generation according to this specification.

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

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

12.

10.  IANA Considerations

   This document has no actions for IANA.

11.  Security Threats Alleviation Analysis Considerations

   This document specifies a protocol extension to NHDP which allows for
   alleviating some of the security threats of NHDP analyzed in
   [NHDP-sec-threats].

11.1.  Alleviated Attacks

   This section briefly summarizes which of the security threats, from
   among those detailed in [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.

12.2.

11.1.1.  Identity Spoofing

   As only NHDP Routers possessing valid cryptographic keys are able to
   add ICV TLVs HELLO messages, in a way which permits that these be
   validated successfully, identity spoofing is counteracted.

12.3.

11.1.2.  Link Spoofing

   Link spoofing is counteracted by the framework specified in this
   document, with the same argument as in Section 12.2. 11.1.1.  A router
   without access to valid cryptographic keys cannot generate valid ICVs
   for inclusion in a HELLO message.

12.4.

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

13.  IANA Considerations

   This document has no actions for IANA.

14.  Security Considerations

   This document specifies

11.2.  Limitations

   Since jamming is a protocol extension to NHDP which allows to
   alleviate some of physical layer issue, it cannot be alleviated by
   protocols on the security threats of NHDP analyzed in
   [NHDP-sec-threats]. routing layer.  This framework does not counteract
   jamming attacks.

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

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

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

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

   This document does also not provide a key revocation mechanism.

15.

12.  Acknowledgments

   The authors would like to thank Jiazi Yi (Ecole Polytechnique) for
   his review and comments to this document.

16.

13.  References

13.1.  Normative References

   [NHDP-sec-threats]
              Herberg, U., Clausen, T., and J. Yi, "Security Threats for
              NHDP", work in
              progress 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.

   [packetbb-sec]

   [RFC6622]  Herberg, U. and T. Clausen, "Integrity Check Value and
              Timestamp TLV Definitions for MANETs", Mobile Ad Hoc Networks
              (MANETs)", RFC 6622, May 2012.

13.2.  Informative References

   [NHDP-sec-threats]
              Herberg, U., Clausen, T., and J. Yi, "Security Threats for
              NHDP", work in
              progress draft-ietf-manet-packetbb-sec-09.txt, March draft-ietf-manet-nhdp-sec-threats-00.txt,
              April 2012.

Authors' Addresses

   Ulrich Herberg
   Fujitsu Laboratories of America
   1240 E. Arques Ave.
   Sunnyvale, CA, 94085,
   USA

   Email: ulrich@herberg.name
   URI:   http://www.herberg.name/

   Thomas Heide Clausen
   LIX, Ecole Polytechnique
   91128 Palaiseau Cedex,
   France

   Phone: +33 6 6058 9349
   Email: T.Clausen@computer.org
   URI:   http://www.thomasclausen.org/