[MSEC] Version 02 of the "TESLA for ALC and NORM" I-D is available

[Vincent Roca <[e-mail]>]

Hello,

This is to inform you that we recently updated our "TESLA for ALC and NORM" I-D.
http://tools.ietf.org/html/draft-ietf-msec-tesla-for-alc-norm-02.txt


This is a MAJOR update. A summary (with motivations) for these changes
follows. For the details, see:
http://tools.ietf.org/wg/msec/draft-ietf-msec-tesla-for-alc-norm/draft-ietf-msec-tesla-for-alc-norm-02-from-01.diff.html


Summary:

** Concerning in-band bootstrap:
         - total reorganization of the bootstrap format. In particular,
         better separation between parameters sent in-band and the other
         parameters (e.g. we removed NTP and certificate stuff).
         - better understanding of when this in-band bootstrap is useful
         (typically for testing purposes, or in static environments, when keys are
         pre-distributed, or when higher level signaling protocols (e.g. MIKEY)
         are not/cannot be deployed, (e.g. when there's no back channel).
         See section 2.3. "Bootstrapping TESLA" for more details.

   While I think that keeping this in-band bootstrap feature can be useful
   for some use-cases, we tried to minimize its importance.


** Specification of NORM packet types for TESLA control packets (bootstrap and
   direct time synch) thanks to the help of Brian Adamson.
   (these types were not specified in previous versions)


** Added "authentication tag without key disclosure".
   This tag enables to significantly reduce the transmission overhead when
   several packets are sent per time interval. Some of them will contain the
   standard authentication tag (that reveals K_{i-d}) while others do not
   (which saves 20 bytes per packet with HMAC-SHA-1).

   This tag is also needed during the first "d" intervals of a session (0..d-1),
   since no key can be disclosed yet (yet the text explaining this is still
   missing in version -02...).


** Added "compact" versions of the various authentication tags.
   These versions replace the 32 bit "i" field by a compact 8 bit "i_LSB"
   (Least Significant Byte) counter. Additionally, when the MAC is not aligned on
   32 bit boundaries, for instance with HMAC-SHA-1, the two padding bytes are
   replaced by the 16 bit "i_NSB" field ("Next Significant Bytes"). Each packet
   carries therefore 3 bytes of the i counter, and remove the original 32-bit "i"
   field.

   We explain how to guess the "i" field when only "i_LSB" (and perhaps
   "i_NSB") is(are) available in section 5.2 "Authentication of Received Packets".

   For instance (HMAC-SHA-1):

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   HET (=1)    |     HEL (=9)  |  ASID |   5   |     i_LSB     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +                                                               +
  |                                                               |
  +                     Disclosed Key K_{i-d}                     +
  |                          (20 bytes)                           |
  +                                                               +
  |                                                               |
  +                                                               +
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +                         MAC(K'_i, M)                          +
  |                          (10 bytes)                           |
  +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                               |             i_NSB             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

and without key disclosure:

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   HET (=1)    |   HEL (=4)    |  ASID |   6   |     i_LSB     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +                         MAC(K'_i, M)                          +
  |                          (10 bytes)                           |
  +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                               |             i_NSB             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


** Changed the EXT_AUTH authentication header.
   There's now an ASID (auth scheme ID) field, common to all EXT_AUTH
   headers, meant to identify the authentication scheme used in a
   given packet.
   See also: https://datatracker.ietf.org/drafts/draft-roca-rmt-simple-auth-for-alc-norm/

   The idea is that several different shemes might be used in a session:
   - depending on the packet sender (TESLA for downward traffic, a
   simple group MAC scheme for the upward traffic),
   - depending on the traffic features (e.g. during an intense data
   exchange period, TESLA could be used, and later on, in the same
   session, a digital signature EXT_AUTH could be used for sporadic
   traffic, in the same session);
   - a group MAC EXT_AUTH could be used as a pre-check in addition to
   a digital signature EXT_AUTH, by including both EXT_AUTH header
   extensions in the same packet.

   The session description provides the actual mapping between the
   ASID value and the authentication scheme (4 bits are clearly
   too much, but header processing is simple).


** Added a brand new "Security" section


** Updated the section 7. "IANA Considerations" with up-to-date
cryptographic functions.

** Changed/clarified many parts of the I-D.


Comments are welcome.
Anyway, I'll introduce new version next week, during the monday's
RMT meeting.

Cheers,


   Vincent and al.

_______________________________________________
MSEC mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/msec