YANG Schema Comparison
draft-ietf-netmod-yang-schema-comparison-02

"Host Mobility with the Host Identity Protocol"
      [I-D.ietf-hip-rfc5206-bis]: how to support host mobility in HIP

  o  "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions"
      [I-D.ietf-hip-rfc5205-bis]: how to extend DNS to contain Host
      Identity information

  o  "Host Identity Protocol (HIP) Rendezvous Extension"
      [I-D.ietf-hip-rfc5204-bis]: using a rendezvous mechanism to
      contact mobile HIP hosts

  Since the HIP base exchange was first developed, there have been a
  few advances in cryptography and attacks against cryptographic
  systems.  As a result, all cryptographic protocols need to be agile.
  That is, it should be a part of the protocol to be able to switch
  from one cryptographic primitive to another.  It is important to
  support a reasonable set of mainstream algorithms to cater for
  different use cases and allow moving away from algorithms that are
  later discovered to be vulnerable.  This update to the base exchange
  includes this needed cryptographic agility while addressing the
  downgrade attacks that such flexibility introduces.  In particular,
  Elliptic Curve support by Elliptic Curve DSA (ECDSA) and Elliptic
  Curve Diffie-Hellman (ECDH) and alternative hash functions have been
  added.

1.1.  A New Namespace and Identifiers

  The Host Identity Protocol introduces a new namespace, the Host
  Identity namespace.  Some ramifications of this new namespace are
  explained in the HIP architecture description
  [I-D.ietf-hip-rfc4423-bis].

  There are two main representations of the Host Identity, the full
  Host Identity (HI) and the Host Identity Tag (HIT).  The HI is a
  public key and directly represents the Identity of a host.  Since
  there are different public key algorithms that can be used with
  different key lengths, the HI, as such, is unsuitable for use as a
  packet identifier, or as an index into the various state-related
  implementation structures needed to support HIP.  Consequently, a
  hash of the HI, the Host Identity Tag (HIT), is used as the
  operational representation.  The HIT is 128 bits long and is used in
  the HIP headers and to index the corresponding state in the end
  hosts.  The HIT has an important security property in that it is
  self-certifying (see Section 3).

Moskowitz, et al.        Expires March 26, 2015                [Page 6]
Internet-Draft                    HIPv2                  September 2014

1.2.  The HIP Base Exchange (BEX)

  The HIP base exchange is a two-party cryptographic protocol used to
  establish communications context between hosts.  The base exchange is
  a SIGMA-compliant [KRA03] four-packet exchange.  The first party is
  called the Initiator and the second party the Responder.  The
  protocol exchanges Diffie-Hellman [DIF76] keys in the 2nd and 3rd
  packets, and authenticates the parties in the 3rd and 4th packets.
  The four-packet design helps to make HIP DoS resilient.  It allows
  the Responder to stay stateless until the IP address and the
  cryptographic puzzle is verified.  The Responder starts the puzzle
  exchange in the 2nd packet, with the Initiator completing it in the
  3rd packet before the Responder stores any state from the exchange.

  The exchange can use the Diffie-Hellman output to encrypt the Host
  Identity of the Initiator in the 3rd packet (although Aura, et al.,
  [AUR03] notes that such operation may interfere with packet-
  inspecting middleboxes), or the Host Identity may instead be sent
  unencrypted.  The Responder's Host Identity is not protected.  It
  should be noted, however, that both the Initiator's and the
  Responder's HITs are transported as such (in cleartext) in the
  packets, allowing an eavesdropper with a priori knowledge about the
  parties to identify them by their HITs.  Hence, encrypting the HI of
  any party does not provide privacy against such attacker.

  Data packets start to flow after the 4th packet.  The 3rd and 4th HIP
  packets may carry a data payload in the future.  However, the details
  of this may be defined later.

  An existing HIP association can be updated using the update mechanism
  defined in this document, and when the association is no longer
  needed, it can be closed using the defined closing mechanism.

  Finally, HIP is designed as an end-to-end authentication and key
  establishment protocol, to be used with Encapsulated Security Payload
  (ESP) [I-D.ietf-hip-rfc5202-bis] and other end-to-end security
  protocols.  The base protocol does not cover all the fine-grained
  policy control found in Internet Key Exchange (IKE) [RFC5996] that
  allows IKE to support complex gateway policies.  Thus, HIP is not a
  complete replacement for IKE.

1.3.  Memo Structure

  The rest of this memo is structured as follows.  Section 2 defines
  the central keywords, notation, and terms used throughout the rest of
  the document.  Section 3 defines the structure of the Host Identity
  and its various representations.  Section 4 gives an overview of the
  HIP base exchange protocol.  Sections 5 and 6 define the detailed

Moskowitz, et al.        Expires March 26, 2015                [Page 7]
Internet-Draft                    HIPv2                  September 2014

  packet formats and rules for packet processing.  Finally, Sections 7,
  8, and 9 discuss policy, security, and IANA considerations,
  respectively.

2.  Terms and Definitions

2.1.  Requirements Terminology

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  document are to be interpreted as described in RFC 2119 [RFC2119].

2.2.  Notation

  [x]  indicates that x is optional.

  {x}  indicates that x is encrypted.

  X(y)  indicates that y is a parameter of X.

  <x>i  indicates that x exists i times.

  -->  signifies "Initiator to Responder" communication (requests).

  <--  signifies "Responder to Initiator" communication (replies).

  |  signifies concatenation of information (e.g., X | Y is the
      concatenation of X with Y).

  Ltrunc (H(x), K)  denotes the lowest order #K bits of the result of
      the hash function H on the input x.

2.3.  Definitions

  HIP base exchange (BEX):  the handshake for establishing a new HIP
      association.

  Host Identity (HI):  The public key of the signature algorithm that
      represents the identity of the host.  In HIP, a host proves its
      identity by creating a signature with the private key belonging to
      its HI (c.f.  Section 3).

  Host Identity Tag (HIT):  A shorthand for the HI in IPv6 format.  It
      is generated by hashing the HI (c.f.  Section 3.1).

  HIT Suite:  A HIT Suite groups all cryptographic algorithms that are
      required to generate and use an HI and its HIT.  In particular,

Moskowitz, et al.        Expires March 26, 2015                [Page 8]
Internet-Draft                    HIPv2                  September 2014

      these algorithms are: 1) the public key signature algorithm and 2)
      the hash function, 3) the truncation (c.f.  Appendix E).

  HIP association:  The shared state between two peers after
      completion of the BEX.

  HIP packet:  A control packet carrying a HIP packet header relating
      to the establishment, maintenance, or termination of the HIP
      association.

  Initiator:  The host that initiates the BEX.  This role is typically
      forgotten once the BEX is completed.

  Responder:  The host that responds to the Initiator in the BEX.
      This role is typically forgotten once the BEX is completed.

  Responder's HIT Hash Algorithm (RHASH):  The Hash algorithm used for
      various hash calculations in this document.  The algorithm is the
      same as is used to generate the Responder's HIT.  The RHASH is the
      hash function defined by the HIT Suite of the Responder's HIT
      (c.f.  Appendix E).

  Length of the Responder's HIT Hash Algorithm (RHASH_len):  The
      natural output length of RHASH in bits.

  Signed data:  Data that is signed is protected by a digital
      signature that was created by the sender of the data by using the
      private key of its HI.

  KDF:  The Key Derivation Function (KDF) is used for deriving the
      symmetric keys from the Diffie-Hellman key exchange.

  KEYMAT:  The keying material derived from the Diffie-Hellman key
      exchange by using the KDF.  Symmetric keys for encryption and
      integrity protection of HIP packets and encrypted user data
      packets are drawn from this keying material.

3.  Host Identity (HI) and its Structure

  In this section, the properties of the Host Identity and Host
  Identity Tag are discussed, and the exact format for them is defined.
  In HIP, the public key of an asymmetric key pair is used as the Host
  Identity (HI).  Correspondingly, the host itself is defined as the
  entity that holds the private key of the key pair.  See the HIP
  architecture specification [I-D.ietf-hip-rfc4423-bis] for more
  details on the difference between an identity and the corresponding
  identifier.

Moskowitz, et al.        Expires March 26, 2015                [Page 9]
Internet-Draft                    HIPv2                  September 2014

  HIP implementations MUST support the Rivest Shamir Adelman [RSA]
  public key algorithm and the Elliptic Curve Digital Signature
  Algorithm (ECDSA) for generating the HI as defined in Section 5.2.9.
  Additional algorithms MAY be supported.

  A hashed encoding of the HI, the Host Identity Tag (HIT), is used in
  protocols to represent the Host Identity.  The HIT is 128 bits long
  and has the following three key properties: i) it is the same length
  as an IPv6 address and can be used in fixed address-sized fields in
  APIs and protocols, ii) it is self-certifying (i.e., given a HIT, it
  is computationally hard to find a Host Identity key that matches the
  HIT), and iii) the probability of a HIT collision between two hosts
  is very low, hence, it is infeasible for an attacker to find a
  collision with a HIT that is in use.  For details on the security
  properties of the HIT see [I-D.ietf-hip-rfc4423-bis].

  The structure of the HIT is defined in [RFC7343].  The HIT is an
  Overlay Routable Cryptographic Hash Identifier (ORCHID) and consists
  of three parts: first, an IANA assigned prefix to distinguish it from
  other IPv6 addresses.  Second, a four-bit encoding of the algorithms
  that were used for generating the HI and the hashed representation of
  HI.  Third, a 96-bit hashed representation of the Host Identity.  The
  encoding of the ORCHID generation algorithm and the exact algorithm
  for generating the hashed representation is specified in Appendix E.

  Carrying HIs and HITs in the header of user data packets would
  increase the overhead of packets.  Thus, it is not expected that they
  are carried in every packet, but other methods are used to map the
  data packets to the corresponding HIs.  In some cases, this makes it
  possible to use HIP without any additional headers in the user data
  packets.  For example, if ESP is used to protect data traffic, the
  Security Parameter Index (SPI) carried in the ESP header can be used
  to map the encrypted data packet to the correct HIP association.

3.1.  Host Identity Tag (HIT)

  The Host Identity Tag is a 128-bit value -- a hashed encoding of the
  Host Identifier.  There are two advantages of using a hashed encoding
  over the actual variable-sized Host Identity public key in protocols.
  First, the fixed length of the HIT keeps packet sizes manageable and
  eases protocol coding.  Second, it presents a consistent format for
  the protocol, independent of the underlying identity technology in
  use.

  RFC 7343 [RFC7343] specifies 128-bit hash-based identifiers, called
  Overlay Routable Cryptographic Hash Identifiers, ORCHIDs.  Their
  prefix, allocated from the IPv6 address block, is defined in
  [RFC7343].  The Host Identity Tag is one type of an ORCHID.

Moskowitz, et al.        Expires March 26, 2015                [Page 10]
Internet-Draft                    HIPv2                  September 2014

  This document extends the original, experimental HIP specification
  [RFC5201] with measures to support crypto agility.  One of these
  measures is to allow different hash functions for creating a HIT.
  HIT Suites group the sets of algorithms that are required to generate
  and use a particular HIT.  The Suites are encoded in HIT Suite IDs.
  These HIT Suite IDs are transmitted in the ORCHID Generation
  Algorithm (OGA) field in the ORCHID.  With the HIT Suite ID in the
  OGA field, a host can tell from another host's HIT, whether it
  supports the necessary hash and signature algorithms to establish a
  HIP association with that host.

3.2.  Generating a HIT from an HI

  The HIT MUST be generated according to the ORCHID generation method
  described in [RFC7343] using a context ID value of 0xF0EF F02F BFF4
  3D0F E793 0C3C 6E61 74EA (this tag value has been generated randomly
  by the editor of this specification), and an input that encodes the
  Host Identity field (see Section 5.2.9) present in a HIP payload
  packet.  The set of hash function, signature algorithm, and the
  algorithm used for generating the HIT from the HI depends on the HIT
  Suite (see Appendix E) and is indicated by the four bits of the
  ORCHID Generation Algorithm (OGA) field in the ORCHID.  Currently,
  truncated SHA-1, truncated SHA-384, and truncated SHA-256
  [FIPS.180-2.2002] are defined as hashes for generating a HIT.

  For identities that are either RSA, Digital Signature Algorithm (DSA)
  [FIPS186-3], or Elliptic Curve DSA (ECDSA) public keys, the ORCHID
  input consists of the public key encoding as specified for the Host
  Identity field of the HOST_ID parameter (see Section 5.2.9).  This
  document defines four algorithm profiles: RSA, DSA, ECDSA, and
  ECDSA_LOW.  The ECDSA_LOW profile is meant for devices with low
  computational capabilities.  Hence, one of the following applies:

      The RSA public key is encoded as defined in [RFC3110] Section 2,
      taking the exponent length (e_len), exponent (e), and modulus (n)
      fields concatenated.  The length (n_len) of the modulus (n) can be
      determined from the total HI Length and the preceding HI fields
      including the exponent (e).  Thus, the data that serves as input
      for the HIT generation has the same length as the HI.  The fields
      MUST be encoded in network byte order, as defined in [RFC3110].

      The DSA public key is encoded as defined in [RFC2536] Section 2,
      taking the fields T, Q, P, G, and Y, concatenated as input.  Thus,
      the data to be hashed is 1 + 20 + 3 * 64 + 3 * 8 * T octets long,
      where T is the size parameter as defined in [RFC2536].  The size
      parameter T, affecting the field lengths, MUST be selected as the
      minimum value that is long enough to accommodate P, G, and Y.  The

Moskowitz, et al.        Expires March 26, 2015                [Page 11]
Internet-Draft                    HIPv2                  September 2014

      fields MUST be encoded in network byte order, as defined in
      [RFC2536].

      The ECDSA public keys are encoded as defined in [RFC6090]
      Section 4.2 and 6.

  In Appendix B, the public key encoding process is illustrated using
  pseudo-code.

4.  Protocol Overview

  This section is a simplified overview of the HIP protocol operation,
  and does not contain all the details of the packet formats or the
  packet processing steps.  Sections 5 and 6 describe in more detail
  the packet formats and packet processing steps, respectively, and are
  normative in case of any conflicts with this section.

  The protocol number 139 has been assigned by IANA to the Host
  Identity Protocol.

  The HIP payload (Section 5.1) header could be carried in every IP
  datagram.  However, since HIP headers are relatively large (40
  bytes), it is desirable to 'compress' the HIP header so that the HIP
  header only occurs in control packets used to establish or change HIP
  association state.  The actual method for header 'compression' and
  for matching data packets with existing HIP associations (if any) is
  defined in separate documents, describing transport formats and
  methods.  All HIP implementations MUST implement, at minimum, the ESP
  transport format for HIP [I-D.ietf-hip-rfc5202-bis].

4.1.  Creating a HIP Association

  By definition, the system initiating a HIP base exchange is the
  Initiator, and the peer is the Responder.  This distinction is
  typically forgotten once the base exchange completes, and either
  party can become the Initiator in future communications.

  The HIP base exchange serves to manage the establishment of state
  between an Initiator and a Responder.  The first packet, I1,
  initiates the exchange, and the last three packets, R1, I2, and R2,
  constitute an authenticated Diffie-Hellman [DIF76] key exchange for
  session-key generation.  In the first two packets, the hosts agree on
  a set of cryptographic identifiers and algorithms that are then used
  in and after the exchange.  During the Diffie-Hellman key exchange, a
  piece of keying material is generated.  The HIP association keys are
  drawn from this keying material by using a Key Derivation Function
  (KDF).  If other cryptographic keys are needed, e.g., to be used with

Moskowitz, et al.        Expires March 26, 2015                [Page 12]
Internet-Draft                    HIPv2                  September 2014

  ESP, they are expected to be drawn from the same keying material by
  using the KDF.

  The Initiator first sends a trigger packet, I1, to the Responder.
  The packet contains the HIT of the Initiator and possibly the HIT of
  the Responder, if it is known.  Moreover, the I1 packet initializes
  the negotiation of the Diffie-Hellman group that is used for
  generating the keying material.  Therefore, the I1 packet contains a
  list of Diffie Hellman Group IDs supported by the Initiator.  Note
  that in some cases it may be possible to replace this trigger packet
  by some other form of a trigger, in which case the protocol starts
  with the Responder sending the R1 packet.  In such cases, another
  mechanism to convey the Initiator's supported DH Groups (e.g., by
  using a default group) must be specified.

  The second packet, R1, starts the actual authenticated Diffie-Hellman
  exchange.  It contains a puzzle -- a cryptographic challenge that the
  Initiator must solve before continuing the exchange.  The level of
  difficulty of the puzzle can be adjusted based on level of trust with
  the Initiator, current load, or other factors.  In addition, the R1
  contains the Responder's Diffie-Hellman parameter and lists of
  cryptographic algorithms supported by the Responder.  Based on these
  lists, the Initiator can continue, abort, or restart the base
  exchange with a different selection of cryptographic algorithms.
  Also, the R1 packet contains a signature that covers selected parts
  of the message.  Some fields are left outside the signature to
  support pre-created R1s.

  In the I2 packet, the Initiator MUST display the solution to the
  received puzzle.  Without a correct solution, the I2 message is
  discarded.  The I2 packet also contains a Diffie-Hellman parameter
  that carries needed information for the Responder.  The I2 packet is
  signed by the Initiator.

  The R2 packet acknowledges the receipt of the I2 packet and completes
  the base exchange.  The packet is signed by the Responder.

  The base exchange is illustrated below in Figure 1.  The term "key"
  refers to the Host Identity public key, and "sig" represents a
  signature using such a key.  The packets contain other parameters not
  shown in this figure.

Moskowitz, et al.        Expires March 26, 2015                [Page 13]
Internet-Draft                    HIPv2                  September 2014

      Initiator                              Responder

                  I1: DH list
                -------------------------->
                                            select precomputed R1
                  R1: puzzle, DH, key, sig
                <-------------------------
  check sig                                remain stateless
  solve puzzle
                I2: solution, DH, {key}, sig
                -------------------------->
  compute DH                                check puzzle
                                            check sig
                          R2: sig
                <--------------------------
  check sig                                compute DH

                                Figure 1

4.1.1.  HIP Puzzle Mechanism

  The purpose of the HIP puzzle mechanism is to protect the Responder
  from a number of denial-of-service threats.  It allows the Responder
  to delay state creation until receiving the I2 packet.  Furthermore,
  the puzzle allows the Responder to use a fairly cheap calculation to
  check that the Initiator is "sincere" in the sense that it has
  churned enough CPU cycles in solving the puzzle.

  The puzzle allows a Responder implementation to completely delay
  association-specific state creation until a valid I2 packet is
  received.  An I2 packet without valid puzzle solution can be rejected
  immediately once the Responder has checked the solution by computing
  only one hash function before state is created and CPU-intensive
  public-key signature verification and Diffie-Hellman key generation
  are performed.  By varying the difficulty of the puzzle, the
  Responder can frustrate CPU or memory targeted DoS attacks.

  The Responder can remain stateless and drop most spoofed I2 packets
  because puzzle calculation is based on the Initiator's Host Identity
  Tag. The idea is that the Responder has a (perhaps varying) number of
  pre-calculated R1 packets, and it selects one of these based on the
  information carried in the I1 packet.  When the Responder then later
  receives the I2 packet, it can verify that the puzzle has been solved
  using the Initiator's HIT.  This makes it impractical for the
  attacker to first exchange one I1/R1 packet, and then generate a
  large number of spoofed I2 packets that seemingly come from different
  HITs.  This method does not protect the Responder from an attacker

Moskowitz, et al.        Expires March 26, 2015                [Page 14]
Internet-Draft                    HIPv2                  September 2014

  that uses fixed HITs, though.  Against such an attacker, a viable
  approach may be to create a piece of local state, and remember that
  the puzzle check has previously failed.  See Appendix A for one
  possible implementation.  Responder implementations SHOULD include
  sufficient randomness in the puzzle values so that algorithmic
  complexity attacks become impossible [CRO03].

  The Responder can set the puzzle difficulty for the Initiator, based
  on its level of trust of the Initiator.  Because the puzzle is not
  included in the signature calculation, the Responder can use pre-
  calculated R1 packets and include the puzzle just before sending the
  R1 to the Initiator.  The Responder SHOULD use heuristics to
  determine when it is under a denial-of-service attack, and set the
  puzzle difficulty value #K appropriately as explained later.

4.1.2.  Puzzle Exchange

  The Responder starts the puzzle exchange when it receives an I1
  packet.  The Responder supplies a random number #I, and requires the
  Initiator to find a number J.  To select a proper #J, the Initiator
  must create the concatenation of #I, the HITs of the parties, and #J,
  and calculate a hash over this concatenation using the RHASH
  algorithm.  The lowest order #K bits of the result MUST be zeros.
  The value #K sets the difficulty of the puzzle.

  To generate a proper number #J, the Initiator will have to generate a
  number of Js until one produces the hash target of zeros.  The
  Initiator SHOULD give up after exceeding the puzzle Lifetime in the
  PUZZLE parameter (as described in Section 5.2.4).  The Responder
  needs to re-create the concatenation of #I, the HITs, and the
  provided #J, and compute the hash once to prove that the Initiator
  completed its assigned task.

  To prevent precomputation attacks, the Responder MUST select the
  number #I in such a way that the Initiator cannot guess it.
  Furthermore, the construction MUST allow the Responder to verify that
  the value #I was indeed selected by it and not by the Initiator.  See
  Appendix A for an example on how to implement this.

  Using the Opaque data field in the PUZZLE (see Section 5.2.4), in an
  ECHO_REQUEST_SIGNED (see Section 5.2.20) or in an
  ECHO_REQUEST_UNSIGNED parameter (see Section 5.2.21), the Responder
  can include some data in R1 that the Initiator MUST copy unmodified
  in the corresponding I2 packet.  The Responder can use the opaque
  data to transfer a piece of local state information to the Initiator
  and back, for example to recognize that the I2 is a response to a
  previously sent R1.  The Responder can generate the Opaque data in
  various ways; e.g., using encryption or hashing with some secret, the

Moskowitz, et al.        Expires March 26, 2015                [Page 15]
Internet-Draft                    HIPv2                  September 2014

  sent #I, and possibly using other related data.  With the same
  secret, the received #I (from the I2 packet), and the other related
  data (if any), the Responder can verify that it has itself sent the
  #I to the Initiator.  The Responder MUST periodically change such a
  secret.

  It is RECOMMENDED that the Responder generates new secrets for the
  puzzle and new R1s once every few minutes.  Furthermore, it is
  RECOMMENDED that the Responder is able to verify valid puzzle
  solution at least Lifetime seconds after the puzzle secret has been
  deprecated.  This time value guarantees that the puzzle is valid for
  at least Lifetime and at most 2 * Lifetime seconds.  This limits the
  usability that an old, solved puzzle has to an attacker.  Moreover,
  it avoids problems with the validity of puzzles if the lifetime is
  relatively short compared to the network delay and the time for
  solving the puzzle.

  The puzzle value #I and the solution #J are inputs for deriving the
  keying material from the Diffie-Hellman key exchange (see
  Section 6.5).  Therefore, a Responder SHOULD NOT use the same puzzle
  #I with the same DH keys for the same Initiator twice to ensure that
  the derived keying material differs.  Such uniqueness can be
  achieved, for example, by using a counter as an additional input for
  generating #I.  This counter can be increased for each processed I1
  packet.  The state of the counter can be transmitted in the Opaque
  data field in the PUZZLE (see Section 5.2.4), in an
  ECHO_REQUEST_SIGNED (see Section 5.2.20) or in an
  ECHO_REQUEST_UNSIGNED parameter (see Section 5.2.21) without the need
  to establish state.

  NOTE: The protocol developers explicitly considered whether R1 should
  include a timestamp in order to protect the Initiator from replay
  attacks.  The decision was to NOT include a timestamp to avoid
  problems with global time synchronization.

  NOTE: The protocol developers explicitly considered whether a memory
  bound function should be used for the puzzle instead of a CPU-bound
  function.  The decision was not to use memory-bound functions.

4.1.3.  Authenticated Diffie-Hellman Protocol with DH Group Negotiation

  The packets R1, I2, and R2 implement a standard authenticated Diffie-
  Hellman exchange.  The Responder sends one of its public Diffie-
  Hellman keys and its public authentication key, i.e., its Host
  Identity, in R1.  The signature in the R1 packet allows the Initiator
  to verify that the R1 has been once generated by the Responder.
  However, since the R1 is precomputed and therefore does not cover

Moskowitz, et al.        Expires March 26, 2015                [Page 16]
Internet-Draft                    HIPv2                  September 2014

  association-specific information in the I1 packet, it does not
  protect from replay attacks.

  Before the actual authenticated Diffie-Hellman exchange, the
  Initiator expresses its preference regarding its choice of the DH
  groups in the I1 packet.  The preference is expressed as a sorted
  list of DH Group IDs.  The I1 packet is not protected by a signature.
  Therefore, this list is sent in an unauthenticated way to avoid
  costly computations for processing the I1 packet at the Responder
  side.  Based on the preferences of the Initiator, the Responder sends
  an R1 packet containing its most suitable public DH value.  The
  Responder also attaches a list of its own preferences to the R1 to
  convey the basis for the DH group selection to the Initiator.  This
  list is carried in the signed part of the R1 packet.  If the choice
  of the DH group value in the R1 does not match the preferences of the
  Initiator and the Responder, the Initiator can detect that the list
  of DH Group IDs in the I1 was manipulated (see below for details).

  If none of the DH Group IDs in the I1 packet is supported by the
  Responder, the Responder selects the DH Group most suitable for it
  regardless of the Initiator's preference.  It then sends the R1
  containing this DH Group and its list of supported DH Group IDs to
  the Initiator.

  When the Initiator receives an R1, it receives one of the Responder's
  public Diffie-Hellman values and the list of DH Group IDs supported
  by the Responder.  This list is covered by the signature in the R1
  packet to avoid forgery.  The Initiator compares the Group ID of the
  public DH value in the R1 packet to the list of supported DH Group
  IDs in the R1 packets and to its own preferences expressed in the
  list of supported DH Group IDs.  The Initiator continues the BEX only
  if the Group ID of the public DH value of the Responder is the most
  preferred of the IDs supported by both the Initiator and Responder.
  Otherwise, the communication is subject of a downgrade attack and the
  Initiator MUST either restart the base exchange with a new I1 packet
  or abort the base exchange.  If the Responder's choice of the DH
  Group is not supported by the Initiator, the Initiator MAY abort the
  handshake or send a new I1 packet with a different list of supported
  DH Groups.  However, the Initiator MUST verify the signature of the
  R1 packet before restarting or aborting the handshake.  It MUST
  silently ignore the R1 packet if the signature is not valid.

  If the preferences regarding the DH Group ID match, the Initiator
  computes the Diffie-Hellman session key (Kij).  The Initiator creates
  a HIP association using keying material from the session key (see
  Section 6.5), and may use the HIP association to encrypt its public
  authentication key, i.e., the Host Identity.  The resulting I2 packet
  contains the Initiator's Diffie-Hellman key and its (optionally

Moskowitz, et al.        Expires March 26, 2015                [Page 17]
Internet-Draft                    HIPv2                  September 2014

  encrypted) public authentication key.  The signature of the I2
  message covers all parameters of the signed parameter ranges (see
  Section 5.2) in the packet without exceptions as in the R1.

  The Responder extracts the Initiator's Diffie-Hellman public key from
  the I2 packet, computes the Diffie-Hellman session key, creates a
  corresponding HIP association, and decrypts the Initiator's public
  authentication key.  It can then verify the signature using the
  authentication key.

  The final message, R2, completes the BEX and protects the Initiator
  against replay attacks because the Responder uses the shared key from
  the Diffie-Hellman exchange to create an HMAC as well as uses the
  private key of its Host Identity to sign the packet contents.

4.1.4.  HIP Replay Protection

  The HIP protocol includes the following mechanisms to protect against
  malicious packet replays.  Responders are protected against replays
  of I1 packets by virtue of the stateless response to I1 packets with
  pre-signed R1 messages.  Initiators are protected against R1 replays
  by a monotonically increasing "R1 generation counter" included in the
  R1.  Responders are protected against replays of forged I2 packets by
  the puzzle mechanism (see Section 4.1.1 above), and optional use of
  opaque data.  Hosts are protected against replays of R2 packets and
  UPDATEs by use of a less expensive HMAC verification preceding the
  HIP signature verification.

  The R1 generation counter is a monotonically increasing 64-bit
  counter that may be initialized to any value.  The scope of the
  counter MAY be system-wide but there SHOULD be a separate counter for
  each Host Identity, if there is more than one local host identity.
  The value of this counter SHOULD be preserved across system reboots
  and invocations of the HIP base exchange.  This counter indicates the
  current generation of puzzles.  Implementations MUST accept puzzles
  from the current generation and MAY accept puzzles from earlier
  generations.  A system's local counter MUST be incremented at least
  as often as every time old R1s cease to be valid.  The local counter
  SHOULD never be decremented, otherwise the host exposes its peers to
  the replay of previously generated, higher numbered R1s.

  A host may receive more than one R1, either due to sending multiple
  I1 packets (see Section 6.6.1) or due to a replay of an old R1.  When
  sending multiple I1 packets to the same host, an Initiator SHOULD
  wait for a small amount of time (a reasonable time may be 2 *
  expected RTT) after the first R1 reception to allow possibly multiple
  R1s to arrive, and it SHOULD respond to an R1 among the set with the
  largest R1 generation counter.  If an Initiator is processing an R1

Moskowitz, et al.        Expires March 26, 2015                [Page 18]
Internet-Draft                    HIPv2                  September 2014

  or has already sent an I2 packet (still waiting for the R2 packet)
  and it receives another R1 with a larger R1 generation counter, it
  MAY elect to restart R1 processing with the fresher R1, as if it were
  the first R1 to arrive.

  The R1 generation counter may roll over or may become reset.  It is
  important for an Initiator to be robust to the loss of state about
  the R1 generation counter of a peer, or to a reset of the peer's
  counter.  It is recommended that, when choosing between multiple R1s,
  the Initiator prefer to use the R1 that corresponds to the current R1
  generation counter, but that if it is unable to make progress with
  that R1, the Initiator may try the other R1s beginning with the R1
  packet with the highest counter.

4.1.5.  Refusing a HIP base exchange

  A HIP-aware host may choose not to accept a HIP base exchange.  If
  the host's policy is to only be an Initiator, and policy allows the
  establishment of a HIP association with the original Initiator, it
  should begin its own HIP base exchange.  A host MAY choose to have
  such a policy since only the privacy of the Initiator's HI is
  protected in the exchange.  It should be noted that such behavior can
  introduce the risk of a race condition if each host's policy is to
  only be an Initiator, at which point the HIP base exchange will fail.

  If the host's policy does not permit it to enter into a HIP exchange
  with the Initiator, it should send an ICMP 'Destination Unreachable,
  Administratively Prohibited' message.  A more complex HIP packet is
  not used here as it actually opens up more potential DoS attacks than
  a simple ICMP message.  A HIP NOTIFY message is not used because no
  HIP association exists between the two hosts at that time.

4.1.6.  Aborting a HIP base exchange

  Two HIP hosts may encounter situations in which they cannot complete
  a HIP base exchange because of insufficient support for cryptographic
  algorithms, in particular the HIT Suites and DH Groups.  After
  receiving the R1 packet, the Initiator can determine whether the
  Responder supports the required cryptographic operations to
  successfully establish a HIP association.  The Initiator can abort
  the BEX silently after receiving an R1 packet that indicates an
  unsupported set of algorithms.  The specific conditions are described
  below.

  The R1 packet contains a signed list of HIT Suite IDs as supported by
  the Responder.  Therefore, the Initiator can determine whether its
  source HIT is supported by the Responder.  If the HIT Suite ID of the
  Initiator's HIT is not contained in the list of HIT Suites in the R1,

Moskowitz, et al.        Expires March 26, 2015                [Page 19]
Internet-Draft                    HIPv2                  September 2014

  the Initiator MAY abort the handshake silently or MAY restart the
  handshake with a new I1 packet that contains a source HIT supported
  by the Responder.

  During the Handshake, the Initiator and the Responder agree on a
  single DH Group.  The Responder selects the DH Group and its DH
  public value in the R1 based on the list of DH Suite IDs in the I1
  packet.  If the responder supports none of the DH Groups requested by
  the Initiator, the Responder selects an arbitrary DH and replies with
  an R1 containing its list of supported DH Group IDs.  In such case,
  the Initiator receives an R1 packet containing the DH public value
  for an unrequested DH Group and also the Responder's DH Group list in
  the signed part of the R1 packet.  At this point, the Initiator MAY
  abort the handshake or MAY restart the handshake by sending a new I1
  packet containing a selection of DH Group IDs that is supported by
  the Responder.

4.1.7.  HIP Downgrade Protection

  In a downgrade attack, an attacker attempts to unnoticeably
  manipulate the packets of an Initiator and/or a Responder to
  influence the result of the cryptographic negotiations in the BEX to
  its favor.  As a result, the victims select weaker cryptographic
  algorithms than they would otherwise have selected without the
  attacker's interference.  Downgrade attacks can only be successful if
  they remain un-detected by the victims and the victims falsely assume
  a secure communication channel.

  In HIP, almost all packet parameters related to cryptographic
  negotiations are covered by signatures.  These parameters cannot be
  directly manipulated in a downgrade attack without invalidating the
  signature.  However, signed packets can be subject to replay attacks.
  In such a replay attack, the attacker could use an old BEX packet
  with an outdated and weak selection of cryptographic algorithms and
  replay it instead of a more recent packet with a collection of
  stronger cryptographic algorithms.  Signed packets that could be
  subject to this replay attack are the R1 and I2 packet.  However,
  replayed R1 and I2 packets cannot be used to successfully establish a
  HIP BEX because these packets also contain the public DH values of
  the Initiator and the Responder.  Old DH values from replayed packets
  lead to invalid keying material and mismatching shared secrets
  because the attacker is unable to derive valid keying material from
  the DH public keys in the R1 and cannot generate a valid HMAC and
  signature for a replayed I2.

  In contrast to the first version of HIP [RFC5201],the version 2 of
  HIP defined in this document begins the negotiation of the DH Groups
  already in the first BEX packet, the I1.  The I1 packet is, by

Moskowitz, et al.        Expires March 26, 2015                [Page 20]
Internet-Draft                    HIPv2                  September 2014

  intention, not protected by a signature to avoid CPU-intensive
  cryptographic operations for processing floods of I1 packets targeted
  at the Responder.  Hence, the list of DH Group IDs in the I1 packet
  is vulnerable to forgery and manipulation.  To thwart an unnoticed
  manipulation of the I1 packet, the Responder chooses the DH Group
  deterministically and includes its own list of DH Group IDs in the
  signed part of the R1 packet.  The Initiator can detect an attempted
  downgrade attack by comparing the list of DH Group IDs in the R1
  packet to its own preferences in the I1 packet.  If the choice of the
  DH Group in the R1 packet does not equal to the best match of the two
  lists (the highest priority DH ID of the Responder that is present in
  the Initiator's DH list), the Initiator can conclude that its list in
  the I1 packet was altered by an attacker.  In this case, the
  Initiator can restart or abort the BEX.  As mentioned before, the
  detection of the downgrade attack is sufficient to prevent it.

4.1.8.  HIP Opportunistic Mode

  It is possible to initiate a HIP BEX even if the Responder's HI (and
  HIT) is unknown.  In this case, the initial I1 packet contains all
  zeros as the destination HIT.  This kind of connection setup is
  called opportunistic mode.

  The Responder may have multiple HITs due to multiple supported HIT
  Suites.  Since the Responder's HIT Suite in the opportunistic mode is
  not determined by the destination HIT of the I1 packet, the Responder
  can freely select a HIT of any HIT Suite.  The complete set of HIT
  Suites supported by the Initiator is not known to the Responder.
  Therefore, the Responder SHOULD select its HIT from the same HIT
  Suite as the Initiator's HIT (indicated by the HIT suite information
  in the OGA field of the Initiator's HIT) because this HIT Suite is
  obviously supported by the Initiator.  If the Responder selects a
  different HIT that is not supported by the Initiator, the Initiator
  MAY restart the BEX with an I1 packet with a source HIT that is
  contained in the list of the Responder's HIT Suites in the R1 packet.

  Note that the Initiator cannot verify the signature of the R1 packet
  if the Responder's HIT Suite is not supported.  Therefore, the
  Initiator MUST treat R1 packets with unsupported Responder HITs as
  potentially forged and MUST NOT use any parameters from the
  unverified R1 besides the HIT Suite List.  Moreover, an Initiator
  that uses an unverified HIT Suite List from an R1 packet to determine
  a possible source HIT MUST verify that the HIT_SUITE_LIST in the
  first unverified R1 packet matches the HIT_SUITE_LIST in the second
  R1 packet for which the Initiator supports the signature algorithm.
  The Initiator MUST restart the BEX with a new I1 packet for which the
  algorithm was mentioned in the verifiable R1 if the two lists do not
  match.  This procedure is necessary to mitigate downgrade attacks.

Moskowitz, et al.        Expires March 26, 2015                [Page 21]
Internet-Draft                    HIPv2                  September 2014

  There are both security and API issues involved with the
  opportunistic mode.  These issues are described in the reminder of
  this section.

  Given that the Responder's HI is not known by the Initiator, there
  must be suitable API calls that allow the Initiator to request,
  directly or indirectly, that the underlying system initiates the HIP
  base exchange solely based on locators.  The Responder's HI will be
  tentatively available in the R1 packet, and in an authenticated form
  once the R2 packet has been received and verified.  Hence, the
  Responder's HIT could be communicated to the application via new API
  mechanisms.  However, with a backwards-compatible API the application
  sees only the locators used for the initial contact.  Depending on
  the desired semantics of the API, this can raise the following
  issues:

  o  The actual locators may later change if an UPDATE message is used,
      even if from the API perspective the association still appears to
      be between two specific locators.  However, the locator update is
      still secure and the association is still between the same nodes.

  o  Different associations between the same two locators may result in
      connections to different nodes, if the implementation no longer
      remembers which identifier the peer had in an earlier association.
      This is possible when the peer's locator has changed for
      legitimate reasons or when an attacker pretends to be a node that
      has the peer's locator.  Therefore, when using opportunistic mode,
      HIP implementations MUST NOT place any expectation that the peer's
      HI returned in the R1 message matches any HI previously seen from
      that address.

      If the HIP implementation and application do not have the same
      understanding of what constitutes an association, this may even
      happen within the same association.  For instance, an
      implementation may not know when HIP state can be purged for UDP-
      based applications.

  In addition, the following security considerations apply.  The
  generation counter mechanism will be less efficient in protecting
  against replays of the R1 packet, given that the Responder can choose
  a replay that uses an arbitrary HI, not just the one given in the I1
  packet.

  More importantly, the opportunistic exchange is vulnerable to man-in-
  the-middle attacks, because the Initiator does not have any public
  key information about the peer.  To assess the impacts of this
  vulnerability, we compare it to vulnerabilities in current, non-HIP-
  capable communications.

Moskowitz, et al.        Expires March 26, 2015                [Page 22]
Internet-Draft                    HIPv2                  September 2014

  Uploaded new revision