Subject: Re: [secdir] SecDir review of draft-ietf-msec-tesla-for-alc-norm-07

From: Vincent Roca <[email-masked]>
Date: Wed, 09 Sep 2009 15:44:31 +0200

Dear Yaron,

Thanks a lot for your detailed review and comments. Please, find below
our answers and explanations on how we addressed them.

> General
>
> Overall this is a good document, but I suspect that it has too many options
> and leaves too many things open as to be truly interoperable. So
> Experimental is the right designation. From a security point of view, things
> seem to be well covered, but see my two comments below.

We agree there are too many options.  This is one of our concerns
and beyond interoperability, complexity is also a source of security
concerns.

To address this, at least partially, we have removed the four
compact authentication tags, i.e. the compact formats where the
32-bit "i" interval index is not provided and is "replaced" by 1
or 3 of the least significant bytes with the i_LSB/i_NSB fields
(section 3.4.7. "Format of the Compact Authentication Tags").

Doing so significantly simplifies the proposal:
- there are only 4 different authentication tags instead of 8,
- the "i" computation logic through the i_LSB/i_NSB fields in
  section 4.3 is removed,
- the whole section 4.3.1. "Wrong Guess of the i Parameter" is
  removed too.
It does not fundamentally change the protocol, and the main drawback
is a mandatory 32-bit overhead (the "i" field) in each authentication
tag. That's an acceptable price to pay IOHO. The second drawback is
a renumbering of the "Type" field (section 5.1) but we believe it's
still acceptable given the "work in progress" status of the document.

Historically, when we proposed the compact versions, HMAC-SHA1 was
the default and we felt it was interesting to replace the 3 reserved/
padding bytes by 3 bytes of "i". Now that HMAC-SHA255 is the default
(and HMAC-SHA1 non recommended), i_NSB can no longer be used, only
i_LSB (1 byte). So it's in any case less attractive.

> Security Issues
>
> 4.2.2.2: it is far from clear that if I trust you to send me packets (a
> movie, say), I also trust you to configure my NTP client (list of servers
> and trust anchors for them). So I wonder if using one of the offered NTP
> servers should really be MUST. Or are we really expecting a separate
> application level NTP layer, on top of that maintained by the OS?

You're right, the wording is not appropriate. We clarified this section
by adding the following paragraph, at the end of 4.2.2.2:
---
Note that this scenario assumes that each client trusts the sender and accepts to
align its NTP configuration to that of the sender, using one of the NTP server(s)
suggested. If this assumption does not hold, the client MUST NOT use the NTP indirect
time synchronization method (Section 2.3.2.).
---

Section 2.3.2 specifies that some of the indirect synchronization methods
require that the clients trust the sender sufficiently:
---
It should be noted that the NTP/SNTP schemes assume that each client trusts
the sender and accepts to align its NTP/SNTP configuration to that of the
sender. If this assumption does not hold, the sender SHOULD offer an
alternative solution.
---

However, we think that "using one of the offered NTP server"
is a MUST for TESLA to remain secure. If the two NTP hierarchies
are totally disjoint, I don't see how secure time synchronization
could be achieved.

> 6. The Security Considerations have no discussion at all of the security of
> the back channel. I understand that such a channel does exist, at least for
> NORM. This channel remains unprotected (or its protection remains
> unspecified, see Sec. 1.1). Can it be used to DOS the sender? Other
> receivers? Are additional attacks possible?

You're right. We added a new section to discuss the security of the
back channel (section 6.3). We also added an informative reference to
a companion document, draft-ietf-rmt-simple-auth-for-alc-norm-01,
that expicits the use of such simple schemes as RSA/ECC digital signature
and/or group MAC in the context of ALC/NORM, using the same EXT_AUTH
header extension mechanisms.
http://tools.ietf.org/html/draft-ietf-rmt-simple-auth-for-alc-norm-01
(this document will soon enter RMT WGLC).
Section 1.1. "Scope of this Document" has also been improved in order
to better introduce these possibilities.

> Other Comments
>
> 2.2: leaving the bootstrapping step implementation-dependent means that the
> protocol is non-interoperable.

This is right. We added a sentence to say that it is RECOMMENDED that TESLA
implementations support bootstrap messages. However, we don't want to make
its support mandatory since there are use-cases where out-of-band is prefered
(see RFC4442).

> 3.1.2.2: this section implies (last paragraph) that the use of periodic
> bootstrap information is only applicable for the case where direct time
> synchronization is used. Is this required by the TESLA protocol?

Good catch, thanks. This is indeed an error and anyway it contradicts
section 3.2.1. New text is as follows:

   The only solution for this
   receiver to catch up consists in receiving an additional bootstrap
   information message.  This can happen by waiting for the next
   periodic transmission (if sent in-band) or through an external
   mechanism (Section 3.2.1).

> 3.4.3: the description of the “Disclosed Key” field says it must be 0 in the
> first d intervals, which contradicts the last paragraph of the section,
> where it is forbidden to use this tag in those intervals.

We read the whole document several times, and this error slipped through.
Of course, the "set to 0" requirement comes from the time there was no
auth tag without key disclosure. Thanks.

> 3.4.7 (and elsewhere): I wonder about the design choice of making the length
> of the NSB (and hence, the explicit part of the interval index) depend on
> the size of the truncated MAC. The considerations for selecting one are
> primarily security-related, while for the other they are primarily about
> bandwidth and reliability. Why make them dependent?

We removed i_LSB/i_NSB altogether in the new version, for the sake of
simplicity (see our answer to the "General comment"). This comment does
not apply now.

> 4.1: the text “verify the Group MAC if present” is misleading (an attacker
> might remove it from the packet). It should be “if the G bit is set in the
> Bootstrap message”.

This is right, the wording is misleading. Corrected. New text is as follows:
---
   o  first of all, if the Group MAC is present and if the session uses
      this feature (e.g., if the G bit is set in the bootstrap
      information message), then verify the Group MAC.  A packet that
      does not contain a Group MAC tag whereas the session uses this
      feature MUST be immediately dropped.  On the opposite, if a packet
      contains a Group MAC tag whereas the session does not use this
      feature, this tag MUST be ignored;
---
Similarly we updated step 3 of section 4.3.

> 4.3, step 5: when doing congestion control, isn’t there value in keeping
> key-disclosure packets, even when other packets are dropped? The effect of
> key-disclosure packets being dropped may be dozens of other packets that are
> lost.

There is a misunderstanding here. By "the receiver performs
congestion control", one must understand that the sequence number
information contained in this packet is used by the congestion control
building block to detect possible packet losses. This happen even if
the packet is not authenticated at this step.
If the packet discloses a key, this key will be eventually used once
the packet is authenticated.
The text is clarified to better reflect this (and the DoS attack example
corrected).
---
   5.  When applicable, the receiver performs any congestion control
       related action (i.e., the ALC or NORM headers are used by the
       associated congestion control building block, if any), even if
       the packet has not yet been authenticated [RMT-BB-LCT].  If this
       feature leads to a potential DoS attack (the attacker can send a
       faked packet with a wrong sequence number to simulate packet
       losses), it does not compromise the security features offered by
       TESLA and enables a rapid reaction in front of actual congestion
       problems.
---

> 4.3: I find this text self-contradictory: “In this specification, a receiver
> using TESLA MUST immediately drop unsafe packets.  But the receiver MAY also
> decide, at any time, to continue an ALC or NORM session in unsafe mode,
> ignoring TESLA extensions.” I would have felt somewhat better about it if
> the text said something like “there SHOULD be explicit user action to move
> to unsafe (insecure) mode”.

Corrected as suggested, especially as it was the idea.

Thanks a lot for your valuable comments, and sorry for this
late answer.

    Vincent and Aurelien.

nb: I'll submit the new I-D later today.

---

From: Vincent Roca <[email-masked]>
Date: Wed, 16 Sep 2009 11:18:09 +0200

Dear all,

My colleague, Aurélien, read carefully our new TESLA -08 I-D these
days and found a serious error (plus several minor corrections).

The error concerns section 3.1.2.1. "Principles", where we say:
	"[...] where f_k is the result of the k-th application of the
	PRF function f."
This is of course not the case since k is (in case of HMAC PRF) the
key! So we completely reformulated this section.

We also corrected a few minor things. For instance the keyword "Standard"
was used incorrectly (it's goal up to version 07 was to distinguish the
full authentication tags from the "Compact" ones, but the Compacts tags
have been removed in 08).

So we have prepared version 09 (attached), but did not submit it
using the IETF I-D tool since we don't know if it is appropriate at
this stage of the IESG process. We are awaiting your instructions.

Sorry for this late I-D update.
Cheers,

   Vincent and Aurélien

MSEC                                                             V. Roca
Internet-Draft                                             A. Francillon
Intended status: Experimental                                 S. Faurite
Expires: March 20, 2010                                            INRIA
                                                      September 16, 2009

               Use of TESLA in the ALC and NORM Protocols
                 draft-ietf-msec-tesla-for-alc-norm-09

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on March 20, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Roca, et al.             Expires March 20, 2010                 [Page 1]

Internet-Draft            TESLA in ALC and NORM           September 2009

   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 (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Roca, et al.             Expires March 20, 2010                 [Page 2]

Internet-Draft            TESLA in ALC and NORM           September 2009

Abstract

   This document details the TESLA packet source authentication and
   packet integrity verification protocol and its integration within the
   ALC and NORM content delivery protocols.  This document only
   considers the authentication/integrity verification of the packets
   generated by the session's sender.  The authentication and integrity
   verification of the packets sent by receivers, if any, is out of the
   scope of this document.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.1.  Scope of this Document . . . . . . . . . . . . . . . . . .  6
     1.2.  Conventions Used in this Document  . . . . . . . . . . . .  7
     1.3.  Terminology and Notations  . . . . . . . . . . . . . . . .  7
       1.3.1.  Notations and Definitions Related to Cryptographic
               Functions  . . . . . . . . . . . . . . . . . . . . . .  7
       1.3.2.  Notations and Definitions Related to Time  . . . . . .  8
   2.  Using TESLA with ALC and NORM: General Operations  . . . . . . 10
     2.1.  ALC and NORM Specificities that Impact TESLA . . . . . . . 10
     2.2.  Bootstrapping TESLA  . . . . . . . . . . . . . . . . . . . 11
       2.2.1.  Bootstrapping TESLA with an Out-Of-Band Mechanism  . . 11
       2.2.2.  Bootstrapping TESLA with an In-Band Mechanism  . . . . 11
     2.3.  Setting Up a Secure Time Synchronization . . . . . . . . . 12
       2.3.1.  Direct Time Synchronization  . . . . . . . . . . . . . 12
       2.3.2.  Indirect Time Synchronization  . . . . . . . . . . . . 13
     2.4.  Determining the Delay Bounds . . . . . . . . . . . . . . . 14
       2.4.1.  Delay Bound Calculation in Direct Time
               Synchronization Mode . . . . . . . . . . . . . . . . . 14
       2.4.2.  Delay Bound Calculation in Indirect time
               Synchronization Mode . . . . . . . . . . . . . . . . . 15
     2.5.  Cryptographic parameter values . . . . . . . . . . . . . . 16
   3.  Sender Operations  . . . . . . . . . . . . . . . . . . . . . . 17
     3.1.  TESLA Parameters . . . . . . . . . . . . . . . . . . . . . 17
       3.1.1.  Time Intervals . . . . . . . . . . . . . . . . . . . . 17
       3.1.2.  Key Chains . . . . . . . . . . . . . . . . . . . . . . 17
       3.1.3.  Time Interval Schedule . . . . . . . . . . . . . . . . 20
       3.1.4.  Timing Parameters  . . . . . . . . . . . . . . . . . . 21
     3.2.  TESLA Signaling Messages . . . . . . . . . . . . . . . . . 21
       3.2.1.  Bootstrap Information  . . . . . . . . . . . . . . . . 21
       3.2.2.  Direct Time Synchronization Response . . . . . . . . . 22
     3.3.  TESLA Authentication Information . . . . . . . . . . . . . 23
       3.3.1.  Authentication Tags  . . . . . . . . . . . . . . . . . 23
       3.3.2.  Digital Signatures . . . . . . . . . . . . . . . . . . 23
       3.3.3.  Group MAC Tags . . . . . . . . . . . . . . . . . . . . 24
     3.4.  Format of TESLA Messages and Authentication Tags . . . . . 26

Roca, et al.             Expires March 20, 2010                 [Page 3]

Internet-Draft            TESLA in ALC and NORM           September 2009

       3.4.1.  Format of a Bootstrap Information Message  . . . . . . 26
       3.4.2.  Format of a Direct Time Synchronization Response . . . 32
       3.4.3.  Format of a Standard Authentication Tag  . . . . . . . 33
       3.4.4.  Format of an Authentication Tag Without Key
               Disclosure . . . . . . . . . . . . . . . . . . . . . . 34
       3.4.5.  Format of an Authentication Tag with a ``New Key
               Chain'' Commitment . . . . . . . . . . . . . . . . . . 35
       3.4.6.  Format of an Authentication Tag with a ``Last Key
               of Old Chain'' Disclosure  . . . . . . . . . . . . . . 36
   4.  Receiver Operations  . . . . . . . . . . . . . . . . . . . . . 38
     4.1.  Verification of the Authentication Information . . . . . . 38
       4.1.1.  Processing the Group MAC Tag . . . . . . . . . . . . . 38
       4.1.2.  Processing the Digital Signature . . . . . . . . . . . 38
       4.1.3.  Processing the Authentication Tag  . . . . . . . . . . 39
     4.2.  Initialization of a Receiver . . . . . . . . . . . . . . . 39
       4.2.1.  Processing the Bootstrap Information Message . . . . . 39
       4.2.2.  Performing Time Synchronization  . . . . . . . . . . . 40
     4.3.  Authentication of Received Packets . . . . . . . . . . . . 42
       4.3.1.  Discarding Unnecessary Packets Earlier . . . . . . . . 44
     4.4.  Flushing the Non Authenticated Packets of a Previous
           Key Chain  . . . . . . . . . . . . . . . . . . . . . . . . 45
   5.  Integration in the ALC and NORM Protocols  . . . . . . . . . . 46
     5.1.  Authentication Header Extension Format . . . . . . . . . . 46
     5.2.  Use of Authentication Header Extensions  . . . . . . . . . 47
       5.2.1.  EXT_AUTH Header Extension of Type Bootstrap
               Information  . . . . . . . . . . . . . . . . . . . . . 47
       5.2.2.  EXT_AUTH Header Extension of Type Authentication
               Tag  . . . . . . . . . . . . . . . . . . . . . . . . . 50
       5.2.3.  EXT_AUTH Header Extension of Type Direct Time
               Synchronization Request  . . . . . . . . . . . . . . . 51
       5.2.4.  EXT_AUTH Header Extension of Type Direct Time
               Synchronization Response . . . . . . . . . . . . . . . 51
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 53
     6.1.  Dealing With DoS Attacks . . . . . . . . . . . . . . . . . 53
     6.2.  Dealing With Replay Attacks  . . . . . . . . . . . . . . . 54
       6.2.1.  Impacts of Replay Attacks on TESLA . . . . . . . . . . 54
       6.2.2.  Impacts of Replay Attacks on NORM  . . . . . . . . . . 55
       6.2.3.  Impacts of Replay Attacks on ALC . . . . . . . . . . . 55
     6.3.  Security of the Back Channel . . . . . . . . . . . . . . . 56
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 57
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 59
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 60
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 60
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 60
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62

Roca, et al.             Expires March 20, 2010                 [Page 4]

Internet-Draft            TESLA in ALC and NORM           September 2009

1.  Introduction

   Many applications using multicast and broadcast communications
   require that each receiver be able to authenticate the source of any
   packet it receives as well as the integrity of these packets.  This
   is the case with ALC [RMT-PI-ALC] and NORM [RMT-PI-NORM], two Content
   Delivery Protocols (CDP) designed to transfer reliably objects (e.g.,
   files) between a session's sender and several receivers.  The NORM
   protocol is based on bidirectional transmissions.  Each receiver
   acknowledges data received or, in case of packet erasures, asks for
   retransmissions.  On the opposite, the ALC protocol is based on
   purely unidirectional transmissions.  Reliability is achieved by
   means of the cyclic transmission of the content within a carousel
   and/or by the use of proactive Forward Error Correction codes (FEC).
   Both protocols have in common the fact that they operate at
   application level, on top of an erasure channel (e.g., the Internet)
   where packets can be lost (erased) during the transmission.

   The goal of this document is to counter attacks where an attacker
   impersonates the ALC or NORM session's sender and injects forged
   packets to the receivers, thereby corrupting the objects
   reconstructed by the receivers.

   Preventing this attack is much more complex in case of group
   communications than it is with unicast communications.  Indeed, with
   unicast communications a simple solution exists: the sender and the
   receiver share a secret key to compute a Message Authentication Code
   (MAC) of all messages exchanged.  This is no longer feasible in case
   of multicast and broadcast communications since sharing a group key
   between the sender and all receivers implies that any group member
   can impersonate the sender and send forged messages to other
   receivers.

   The usual solution to provide the source authentication and message
   integrity services in case of multicast and broadcast communications
   consists in relying on asymmetric cryptography and using digital
   signatures.  Yet this solution is limited by high computational costs
   and high transmission overheads.  The Timed Efficient Stream Loss-
   tolerant Authentication protocol (TESLA) is an alternative solution
   that provides the two required services, while being compatible with
   high rate transmissions over lossy channels.

   This document explains how to integrate the TESLA source
   authentication and packet integrity protocol to the ALC and NORM CDP.
   Any application built on top of ALC and NORM will directly benefit
   from the services offered by TESLA at the transport layer.  In
   particular, this is the case of FLUTE.

Roca, et al.             Expires March 20, 2010                 [Page 5]

Internet-Draft            TESLA in ALC and NORM           September 2009

   For more information on the TESLA protocol and its principles, please
   refer to [RFC4082][Perrig04].  For more information on ALC and NORM,
   please refer to [RMT-PI-ALC], [RMT-BB-LCT] and [RMT-PI-NORM]
   respectively.  For more information on FLUTE, please refer to
   [RMT-FLUTE].

1.1.  Scope of this Document

   This specification only considers the authentication and integrity
   verification of the packets generated by the session's sender.  This
   specification does not consider the packets that may be sent by
   receivers, for instance NORM's feedback packets.  [RMT-SIMPLE-AUTH]
   describes several techniques that can be used to that purpose.  Since
   this is usually a low-rate flow (unlike the downstream flow), using
   computing intensive techniques like digital signatures, possibly
   combined with a Group MAC scheme, is often acceptable.  Finally, the
   Section 5 explains how to use several authentication schemes in a
   given session thanks to the ASID (Authentication Scheme IDentifier)
   field.

   This specification relies on several external mechanisms, for
   instance:

   o  to communicate securely the public key or a certificate for the
      session's sender (Section 2.2.2);

   o  to communicate securely and confidentially the group key, K_g,
      used by the Group MAC feature, when applicable (Section 3.3.3).
      In some situations, this group key will have to be periodically
      refreshed;

   o  to perform secure time synchronization in indirect mode
      (Section 2.3.2) or in direct mode (Section 2.3.1) to carry the
      request/response messages with ALC which is purely unidirectional;

   These mechanisms are required in order to bootstrap TESLA at a sender
   and at a receiver and must be deployed in parallel to TESLA.
   Besides, the randomness of the Primary Key of the key chain
   (Section 3.1.2) is vital to the security of TESLA.  Therefore the
   sender needs an appropriate mechanism to generate this random key.

   Several technical details of TESLA, like the most appropriate way to
   alternate between the transmission of a key disclosure and a
   commitment to a new key chain, or the transmission of a key
   disclosure and the last key of the previous key chain, or the
   disclosure of a key and the compact flavor that does not disclose any
   key, are specific to the target use-case (Section 3.1.2).  For
   instance, it depends on the number of packets sent per time interval,

Roca, et al.             Expires March 20, 2010                 [Page 6]

Internet-Draft            TESLA in ALC and NORM           September 2009

   on the desired robustness and the acceptable transmission overhead,
   which can only be optimized after taking into account the use-case
   specificities.

1.2.  Conventions Used in this Document

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

1.3.  Terminology and Notations

   The following notations and definitions are used throughout this
   document.

1.3.1.  Notations and Definitions Related to Cryptographic Functions

   Notations and definitions related to cryptographic functions
   [RFC4082][RFC4383]:

   o  PRF is the Pseudo Random Function;

   o  MAC is the Message Authentication Code;

   o  HMAC is the keyed-Hash Message Authentication Code;

   o  F is the one-way function used to create the key chain
      (Section 3.1.2.1);

   o  F' is the one-way function used to derive the HMAC keys
      (Section 3.1.2.1);

   o  n_p is the length, in bits, of the F function's output.  This is
      therefore the length of the keys in the key chain;

   o  n_f is the length, in bits, of the F' function's output.  This is
      therefore the length of the HMAC keys;

   o  n_m is the length, in bits, of the truncated output of the MAC
      [RFC2104].  Only the n_m most significant bits of the MAC output
      are kept;

   o  N is the length of a key chain.  There are N+1 keys in a key
      chain: K_0, K_1, ..  K_N. When several chains are used, all the
      chains MUST have the same length and keys are numbered
      consecutively, following the time interval numbering;

Roca, et al.             Expires March 20, 2010                 [Page 7]

Internet-Draft            TESLA in ALC and NORM           September 2009

   o  n_c is the number of keys in a key chain.  Therefore: n_c = N+1;

   o  n_tx_lastkey is the number of additional intervals during which
      the last key of the old key chain SHOULD be sent, after switching
      to a new key chain and after waiting for the disclosure delay d.
      These extra transmissions take place after the interval during
      which the last key is normally disclosed.  The n_tx_lastkey value
      is either 0 (no extra disclosure) or larger.  This parameter is
      sender specific and is not communicated to the receiver;

   o  n_tx_newkcc is the number of intervals during which the commitment
      to a new key chain SHOULD be sent, before switching to the new key
      chain.  The n_tx_newkcc value is either 0 (no commitment sent
      within authentication tags) or larger.  This parameter is sender
      specific and is not communicated to the receiver;

   o  K_g is a shared group key, communicated to all group members,
      confidentially, during the TESLA bootstrapping (Section 2.2);

   o  n_w is the length, in bits, of the truncated output of the MAC of
      the optional group authentication scheme: only the n_w most
      significant bits of the MAC output are kept. n_w is typically
      small, multiple of 32 bits (e.g., 32 bits);

1.3.2.  Notations and Definitions Related to Time

   Notations and definitions related to time:

   o  i is the time interval index.  Interval numbering starts at 0 and
      increases consecutively.  Since the interval index is stored as a
      32 bit unsigned integer, wrapping to 0 might take place in long
      sessions.

   o  t_s is the sender local time value at some absolute time (in NTP
      timestamp format);

   o  t_r is the receiver local time value at the same absolute time (in
      NTP timestamp format);

   o  T_0 is the start time corresponding to the beginning of the
      session, i.e., the beginning of time interval 0 (in NTP timestamp
      format);

   o  T_int is the interval duration (in milliseconds);

   o  d is the key disclosure delay (in number of intervals);

Roca, et al.             Expires March 20, 2010                 [Page 8]

Internet-Draft            TESLA in ALC and NORM           September 2009

   o  D_t is the upper bound of the lag of the receiver's clock with
      respect to the clock of the sender;

   o  S_sr is an estimated bound of the clock drift between the sender
      and a receiver throughout the duration of the session;

   o  D^O_t is the upper bound of the lag of the sender's clock with
      respect to the time reference in indirect time synchronization
      mode;

   o  D^R_t is the upper bound of the lag of the receiver's clock with
      respect to the time reference in indirect time synchronization
      mode;

   o  D_err is an upper bound of the time error between all the time
      references, in indirect time synchronization mode;

   o  NTP timestamp format consists in a 64-bit unsigned fixed-point
      number, in seconds relative to 0h on 1 January 1900.  The integer
      part is in the first 32 bits and the fraction part in the last 32
      bits [RFC1305];

Roca, et al.             Expires March 20, 2010                 [Page 9]

Internet-Draft            TESLA in ALC and NORM           September 2009

2.  Using TESLA with ALC and NORM: General Operations

2.1.  ALC and NORM Specificities that Impact TESLA

   The ALC and NORM protocols have features and requirements that
   largely impact the way TESLA can be used.

   In case of ALC:

   o  ALC is massively scalable: nothing in the protocol specification
      limits the number of receivers that join a session.  Therefore an
      ALC session potentially includes a huge number (e.g., millions or
      more) of receivers;

   o  ALC can work on top of purely unidirectional transport channels:
      this is one of the assets of ALC, and examples of unidirectional
      channels include satellite (even if a back channel might exist in
      some use cases) and broadcasting networks like DVB-H/SH;

   o  ALC defines an on-demand content delivery model [RMT-PI-ALC] where
      receivers can arrive at any time, at their own discretion,
      download the content and leave the session.  Other models (e.g.,
      push or streaming) are also defined;

   o  ALC sessions are potentially very long: a session can last several
      days or months during which the content is continuously
      transmitted within a carousel.  The content can be either static
      (e.g., a software update) or dynamic (e.g., a web site).

   Depending on the use case, some of the above features may not apply.
   For instance ALC can also be used over a bidirectional channel or
   with a limited number of receivers.

   In case of NORM:

   o  NORM has been designed for medium size sessions: indeed, NORM
      relies on feedback messages and the sender may collapse if the
      feedback message rate is too high;

   o  NORM requires a bidirectional transport channel: the back channel
      is not necessarily a high data rate channel since the control
      traffic sent over it by a single receiver is an order of magnitude
      lower than the downstream traffic.  Networks with an asymmetric
      connectivity (e.g., a high rate satellite downlink and a low-rate
      RTC based return channel) are appropriate;

Roca, et al.             Expires March 20, 2010                [Page 10]

Internet-Draft            TESLA in ALC and NORM           September 2009

2.2.  Bootstrapping TESLA

   In order to initialize the TESLA component at a receiver, the sender
   MUST communicate some key information in a secure way, so that the
   receiver can check the source of the information and its integrity.
   Two general methods are possible:

   o  by using an out-of-band mechanism, or

   o  by using an in-band mechanism.

   The current specification does not recommend any mechanism to
   bootstrap TESLA.  Choosing between an in-band and out-of-band scheme
   is left to the implementer, depending on the target use-case.
   However, it is RECOMMENDED that TESLA implementations support the use
   of the in-band mechanism for interoperability purposes.

2.2.1.  Bootstrapping TESLA with an Out-Of-Band Mechanism

   For instance [RFC4442] describes the use of the MIKEY (Multimedia
   Internet Keying) protocol to bootstrap TESLA.  As a side effect,
   MIKEY also provides a loose time synchronization feature, that TESLA
   can benefit.  Other solutions, for instance based on an extended
   session description, are possible, on condition these solutions
   provide the required security level.

2.2.2.  Bootstrapping TESLA with an In-Band Mechanism

   This specification describes an in-band mechanism.  In some use-
   cases, it might be desired that bootstrap take place without
   requiring the use of an additional external mechanism.  For instance
   each device may feature a clock with a known time-drift that is
   negligible in front of the time accuracy required by TESLA, and each
   device may embed the public key of the sender.  It is also possible
   that the use-case does not feature a bidirectional channel which
   prevents the use of out-of-band protocols like MIKEY.  For these two
   examples, the exchange of a bootstrap information message (described
   in Section 3.4.1) and the knowledge of a few additional parameters
   (listed below) are sufficient to bootstrap TESLA at a receiver.

   Some parameters cannot be communicated in-band.  In particular:

   o  the sender or group controller MUST either communicate the public
      key of the sender or a certificate (which also means that a PKI
      has been setup) to all receivers, so that each receiver be able to
      verify the signature of the bootstrap message and direct time
      synchronization response messages (when applicable).

Roca, et al.             Expires March 20, 2010                [Page 11]

Internet-Draft            TESLA in ALC and NORM           September 2009

   o  when time synchronization is performed with NTP/SNTP, the sender
      or group controller MUST communicate the list of valid NTP/SNTP
      servers to all the session members (sender included), so that they
      all be able to synchronize themselves on the same NTP/SNTP
      servers.

   o  when the Group MAC feature is used, the sender or group controller
      MUST communicate the K_g group key to all the session members
      (sender included).  This group key may be periodically refreshed.

   The way these parameters are communicated is out of the scope of this
   document.

2.3.  Setting Up a Secure Time Synchronization

   The security offered by TESLA heavily relies on time.  Therefore the
   session's sender and each receiver need to be time synchronized in a
   secure way.  To that purpose, two general methods exist:

   o  direct time synchronization, and

   o  indirect time synchronization.

   It is also possible that a given session include receivers that use
   the direct time synchronization mode while others use the indirect
   time synchronization mode.

2.3.1.  Direct Time Synchronization

   When direct time synchronization is used, each receiver asks the
   sender for a time synchronization.  To that purpose, a receiver sends
   a "Direct Time Synchronization Request" (Section 4.2.2.1).  The
   sender then directly answers to each request with a "Direct Time
   Synchronization Response" (Section 3.4.2), signing this reply.  Upon
   receiving this response, a receiver first verifies the signature, and
   then calculates an upper bound of the lag of his clock with respect
   to the clock of the sender, D_t.  The details on how to calculate D_t
   are given in Section 2.4.1.

   This synchronization method is both simple and secure.  Yet there are
   two potential issues:

   o  a bidirectional channel must exist between the sender and each
      receiver, and

   o  the sender may collapse if the incoming request rate is too high.

   Relying on direct time synchronization is not expected to be an issue

Roca, et al.             Expires March 20, 2010                [Page 12]

Internet-Draft            TESLA in ALC and NORM           September 2009

   with NORM since (1) bidirectional communications already take place,
   and (2) NORM scalability is anyway limited.  Yet it can be required
   that a mechanism, that is out of the scope of this document, be used
   to spread the transmission of "Direct time synchronization request"
   messages over the time if there is a risk that the sender may
   collapse.

   But direct time synchronization is potentially incompatible with ALC
   since (1) there might not be a back channel and (2) there are
   potentially a huge number of receivers and therefore a risk that the
   sender collapses.

2.3.2.  Indirect Time Synchronization

   When indirect time synchronization is used, the sender and each
   receiver must synchronize securely via an external time reference.
   Several possibilities exist:

   o  sender and receivers can synchronize through a NTPv3 (Network Time
      Protocol version 3) [RFC1305] hierarchy of servers.  The
      authentication mechanism of NTPv3 MUST be used in order to
      authenticate each NTP message individually.  It prevents for
      instance an attacker to impersonate a NTP server;

   o  they can synchronize through a NTPv4 (Network Time Protocol
      version 4) [NTP-NTPv4] hierarchy of servers.  The Autokey security
      protocol of NTPv4 MUST be used in order to authenticate each NTP
      message individually;

   o  they can synchronize through a SNTPv4 (Simple Network Time
      Protocol version 4) [RFC4330] hierarchy of servers.  The
      authentication features of SNTPv4 must then be used.  Note that
      TESLA only needs a loose (but secure) time synchronization, which
      is in line with the time synchronization service offered by SNTP;

   o  they can synchronize through a GPS or Galileo (or similar) device
      that also provides a high precision time reference.  Spoofing
      attacks on the GPS system have recently been reported.  Depending
      on the use case, the security achieved will be or not acceptable;

   o  they can synchronize thanks to a dedicated hardware, embedded on
      each sender and receiver, that provides a clock with a time-drift
      that is negligible in front of the TESLA time accuracy
      requirements.  This feature enables a device to synchronize its
      embedded clock with the official time reference from time to time
      (in an extreme case once, at manufacturing time), and then to
      remain autonomous for a duration that depends on the known maximum
      clock drift.

Roca, et al.             Expires March 20, 2010                [Page 13]

Internet-Draft            TESLA in ALC and NORM           September 2009

   A bidirectional channel is required by the NTP/SNTP schemes.  On the
   opposite, with the GPS/Galileo and high precision clock schemes, no
   such assumption is made.  In situations where ALC is used on purely
   unidirectional transport channels (Section 2.1), using the NTP/SNTP
   schemes is not possible.  Another aspect is the scalability
   requirement of ALC, and to a lesser extent of NORM.  From this point
   of view, the above mechanisms usually do not raise any problem,
   unlike the direct time synchronization schemes.  Therefore, using
   indirect time synchronization can be a good choice.  It should be
   noted that the NTP/SNTP schemes assume that each client trusts the
   sender and accepts to align its NTP/SNTP configuration to that of the
   sender.  If this assumption does not hold, the sender SHOULD offer an
   alternative solution.

   The details on how to calculate an upper bound of the lag of a
   receiver's clock with respect to the clock of the sender, D_t, are
   given in Section 2.4.2.

2.4.  Determining the Delay Bounds

   Let us assume that a secure time synchronization has been set up.
   This section explains how to define the various timing parameters
   that are used during the authentication of received packets.

2.4.1.  Delay Bound Calculation in Direct Time Synchronization Mode

   In direct time synchronization mode, synchronization between a
   receiver and the sender follows the following protocol [RFC4082]:

   o  The receiver sends a "Direct Time Synchronization Request" message
      to the sender, that includes t_r, the receiver local time at the
      moment of sending (Section 4.2.2.1).

   o  Upon receipt of this message, the sender records its local time,
      t_s, and sends to the receiver a "Direct Time Synchronization
      Response" that includes t_r (taken from the request) and t_s
      (Section 3.4.2), signing this reply.

   o  Upon receiving this response, the receiver first verifies that he
      actually sent a request with t_r and then checks the signature.
      Then he calculates D_t = t_s - t_r + S_sr, where S_sr is an
      estimated bound of the clock drift between the sender and the
      receiver throughout the duration of the session.  This document
      does not specify how S_sr is estimated.

   After this initial synchronization, at any point throughout the
   session, the receiver knows that: T_s < T_r + D_t, where T_s is the
   current time at the sender and T_r is the current time at the

Roca, et al.             Expires March 20, 2010                [Page 14]

Internet-Draft            TESLA in ALC and NORM           September 2009

   receiver.

2.4.2.  Delay Bound Calculation in Indirect time Synchronization Mode

   In indirect time synchronization, the sender and the receivers must
   synchronize indirectly with one or several time references.

2.4.2.1.  Single time reference

   Let us assume that there is a single time reference.

   1.  The sender calculates D^O_t, the upper bound of the lag of the
       sender's clock with respect to the time reference.  This D^O_t
       value is then be communicated to the receivers (Section 3.2.1).

   2.  Similarly, a receiver R calculates D^R_t, the upper bound of the
       lag of the receiver's clock with respect to the time reference.

   3.  Then, for receiver R, the overall upper bound of the lag of the
       receiver's clock with respect to the clock of the sender, D_t, is
       the sum: D_t = D^O_t + D^R_t.

   The D^O_t and D^R_t calculation depends on the time synchronization
   mechanism used (Section 2.3.2).  In some cases, the synchronization
   scheme specifications provide these values.  In other cases, these
   parameters can be calculated by means of a scheme similar to the one
   specified in Section 2.4.1, for instance when synchronization is
   achieved via a group controller [RFC4082].

2.4.2.2.  Multiple time references

   Let us now assume that there are several time references (e.g.,
   several NTP/SNTP servers).  The sender and receivers use the direct
   time synchronization scheme to synchronize with the various time
   references.  It results in D^O_t and D^R_t.  Let D_err be an upper
   bound of the time error between all the time references.  Then, the
   overall value of D_t within receiver R is set to the sum: D_t = D^O_t
   + D^R_t + D_err.

   In some cases, the D_t value is part of the time synchronization
   scheme specifications.  For instance NTPv3 [RFC1305] defines
   algorithms that are "capable of accuracies in the order of a
   millisecond, even after extended periods when synchronization to
   primary reference sources has been lost".  In practice, depending on
   the NTP server stratum, the accuracy might be a little bit worse.  In
   that case, D_t = security_factor * (1ms + 1ms), where the
   security_factor is meant to compensate several sources of inaccuracy
   in NTP.  The choice of the security_factor value is left to the

Roca, et al.             Expires March 20, 2010                [Page 15]

Internet-Draft            TESLA in ALC and NORM           September 2009

   implementer, depending on the target use-case.

2.5.  Cryptographic parameter values

   The F (resp. F') function output length is given by the n_p (resp.
   n_f) parameter.  The n_p and n_f values depend on the PRF function
   chosen, as specified below:

             +------------------------+---------------------+
             |        PRF name        |     n_p and n_f     |
             +------------------------+---------------------+
             |       HMAC-SHA-1       | 160 bits (20 bytes) |
             |                        |                     |
             |      HMAC-SHA-224      | 224 bits (28 bytes) |
             |                        |                     |
             | HMAC-SHA-256 (default) | 256 bits (32 bytes) |
             |                        |                     |
             |      HMAC-SHA-384      | 384 bits (48 bytes) |
             |                        |                     |
             |      HMAC-SHA-512      | 512 bits (64 bytes) |
             +------------------------+---------------------+

   The computing of regular MAC (resp. Group MAC) makes use of the n_m
   (resp. n_w) parameter, i.e., the length of the truncated output of
   the function.  The n_m and n_w values depend on the MAC function
   chosen, as specified below:

   +------------------------+---------------------+-------------------+
   |        MAC name        |  n_m (regular MAC)  |  n_w (Group MAC)  |
   +------------------------+---------------------+-------------------+
   |       HMAC-SHA-1       |  80 bits (10 bytes) | 32 bits (4 bytes) |
   |                        |                     |                   |
   |      HMAC-SHA-224      | 112 bits (14 bytes) | 32 bits (4 bytes) |
   |                        |                     |                   |
   | HMAC-SHA-256 (default) | 128 bits (16 bytes) | 32 bits (4 bytes) |
   |                        |                     |                   |
   |      HMAC-SHA-384      | 192 bits (24 bytes) | 32 bits (4 bytes) |
   |                        |                     |                   |
   |      HMAC-SHA-512      | 256 bits (32 bytes) | 32 bits (4 bytes) |
   +------------------------+---------------------+-------------------+

Roca, et al.             Expires March 20, 2010                [Page 16]

Internet-Draft            TESLA in ALC and NORM           September 2009

3.  Sender Operations

   This section describes the TESLA operations at a sender.

3.1.  TESLA Parameters

3.1.1.  Time Intervals

   The sender divides the time into uniform intervals of duration T_int.
   Time interval numbering starts at 0 and is incremented consecutively.
   The interval index MUST be stored in an unsigned 32 bit integer so
   that wrapping to 0 takes place only after 2^^32 intervals.  For
   instance, if T_int is equal to 0.5 seconds, then wrapping takes place
   after approximately 68 years.

3.1.2.  Key Chains

3.1.2.1.  Principles

   The sender computes a one-way key chain of n_c = N+1 keys, and
   assigns one key from the chain to each interval, consecutively but in
   reverse order.  Key numbering starts at 0 and is incremented
   consecutively, following the time interval numbering: K_0, K_1 ..
   K_N.

   In order to compute this chain, the sender must first select a
   Primary Key, K_N, and a PRF function, f (Section 7, TESLA-PRF).  The
   randomness of the Primary Key, K_N, is vital to the security and no
   one should be able to guess it.

   The function F is a one-way function that is defined as: F(k) =
   f_k(0), where f_k(0) is the result of the application of the PRF f to
   k and 0.  When f is a HMAC (Section 7), k is used as the key, and 0
   as the message, using the algorithm described in [RFC2104].
   Similarly, the function F' is a one-way function that is defined as:
   F'(k) = f_k(1), where f_k(1) is the result of the application of the
   same PRF f to k and 1.

   The sender then computes all the keys of the chain, recursively,
   starting with K_N, using: K_{i-1} = F(K_i).  Therefore: K_i = F^{N-
   i}(K_N), where F^i(x) is the execution of function F with the
   argument x, i times.  The receiver can then compute any value in the
   key chain from K_N, even if it does not have intermediate values
   [RFC4082].  The key for MAC calculation can then be derived from the
   corresponding K_i key by K'_i = F'(K_i).

   The key chain has a finite length, N, which corresponds to a maximum
   time duration of (N + 1) * T_int.  The content delivery session has a

Roca, et al.             Expires March 20, 2010                [Page 17]

Internet-Draft            TESLA in ALC and NORM           September 2009

   duration T_delivery, which may either be known in advance, or not.  A
   first solution consists in having a single key chain of an
   appropriate length, so that the content delivery session finishes
   before the end of the key chain, i.e., T_delivery <= (N + 1) * T_int.
   But the longer the key chain, the higher the memory and computation
   required to cope with it.  Another solution consists in switching to
   a new key chain, of the same length, when necessary [Perrig04].

3.1.2.2.  Using Multiple Key Chains

   When several key chains are needed, all of them MUST be of the same
   length.  Switching from the current key chain to the next one
   requires that a commitment to the new key chain be communicated in a
   secure way to the receiver.  This can be done by using either an out-
   of-band mechanism, or an in-band mechanism.  This document only
   specifies the in-band mechanism.

   < -------- old key chain --------- >||< -------- new key chain --...
   +-----+-----+ .. +-----+-----+-----+||+-----+-----+-----+-----+-----+
      0     1    ..   N-2   N-1    N   ||  N+1   N+2   N+3   N+4   N+5
                                       ||
   Key disclosures:                    ||
     N/A   N/A   ..  K_N-4 K_N-3 K_N-2 || K_N-1  K_N  K_N+1 K_N+2 K_N+3
                    |                  ||            |                 |
                    |< -------------- >||            |< ------------- >|
   Additional key        F(K_N+1)      ||                   K_N
   disclosures        (commitment to   ||              (last key of the
   (in parallel):      the new chain)  ||                 old chain)

       Figure 1: Switching to the second key chain with the in-band
       mechanism, assuming that d=2, n_tx_newkcc=3, n_tx_lastkey=3.

   Figure 1 illustrates the switch to the new key chain, using the in-
   band mechanism.  Let us say that the old key chain stops at K_N and
   the new key chain starts at K_{N+1} (i.e., F(K_{N+1}) and K_N are two
   different keys).  Then the sender includes the commitment F(K_{N+1})
   to the new key chain into packets authenticated with the old key
   chain (see Section 3.4.5).  This commitment SHOULD be sent during
   n_tx_newkcc time intervals before the end of the old key chain.
   Since several packets are usually sent during an interval, the sender
   SHOULD alternate between sending a disclosed key of the old key chain
   and the commitment to the new key chain.  The details of how to
   alternate between the disclosure and commitment are out of the scope
   of this document.

   The receiver will keep the commitment until the key K_{N+1} is
   disclosed, at interval N+1+d.  Then the receiver will be able to test

Roca, et al.             Expires March 20, 2010                [Page 18]

Internet-Draft            TESLA in ALC and NORM           September 2009

   the validity of that key by computing F(K_{N+1}) and comparing it to
   the commitment.

   When the key chain is changed, it becomes impossible to recover a
   previous key from the old key chain.  This is a problem if the
   receiver lost the packets disclosing the last key of the old key
   chain.  A solution consists in re-sending the last key, K_N, of the
   old key chain (see Section 3.4.6).  This SHOULD be done during
   n_tx_lastkey additional time intervals after the end of the time
   interval where K_N is disclosed.  Since several packets are usually
   sent during an interval, the sender SHOULD alternate between sending
   a disclosed key of the new key chain, and the last key of the old key
   chain.  The details of how to alternate between the two disclosures
   are out of the scope of this document.

   In some cases a receiver having experienced a very long disconnection
   might have lost the commitment of the new chain.  Therefore this
   receiver will not be able to authenticate any packet related to the
   new chain and all the following ones.  The only solution for this
   receiver to catch up consists in receiving an additional bootstrap
   information message.  This can happen by waiting for the next
   periodic transmission (if sent in-band) or through an external
   mechanism (Section 3.2.1).

3.1.2.3.  Values of the n_tx_lastkey and n_tx_newkcc Parameters

   When several key chains and the in-band commitment mechanism are
   used, a sender MUST initialize the n_tx_lastkey and n_tx_newkcc
   parameters in such a way that no overlapping occur.  In other words,
   once a sender starts transmitting commitments for a new key chain, he
   MUST NOT send a disclosure for the last key of the old key chain any
   more.  Therefore, the following property MUST be verified:

      d + n_tx_lastkey + n_tx_newkcc <= N + 1

   It is RECOMMENDED, for robustness purposes, that, once n_tx_lastkey
   has been chosen, then:

      n_tx_newkcc = N + 1 - n_tx_lastkey - d

   In other words, the sender starts transmitting a commitment to the
   following key chain immediately after having sent all the disclosures
   of the last key of the previous key chain.  Doing so increases the
   probability that a receiver gets a commitment for the following key
   chain.

   In any case, these two parameters are sender specific and need not be
   transmitted to the receivers.  Of course, as explained above, the

Roca, et al.             Expires March 20, 2010                [Page 19]

Internet-Draft            TESLA in ALC and NORM           September 2009

   sender alternates between the disclosure of a key of the current key
   chain and the commitment to the new key chain (or the last key of the
   old key chain).

3.1.2.4.  The Particular Case of the Session Start

   Since a key cannot be disclosed before the disclosure delay, d, no
   key will be disclosed during the first d time intervals (intervals 0
   and 1 in Figure 1) of the session.  To that purpose, the sender uses
   the Authentication Tag Without Key Disclosure Section 3.4.4.  The
   following key chains, if any, are not concerned since they will
   disclose the last d keys of the previous chain.

3.1.2.5.  Managing Silent Periods

   An ALC or NORM sender may stop transmitting packets for some time.
   For instance it can be the end of the session and all packets have
   already been sent, or the use-case may consist in a succession of
   busy periods (when fresh objects are available) followed by silent
   periods.  In any case, this is an issue since the authentication of
   the packets sent during the last d intervals requires that the
   associated keys be disclosed, which will take place during d
   additional time intervals.

   To solve this problem, it is recommended that the sender transmit
   empty packets (i.e., without payload) containing the TESLA EXT_AUTH
   header extension along with a Standard Authentication Tag during at
   least d time intervals after the end of the regular ALC or NORM
   packet transmissions.  The number of such packets and the duration
   during which they are sent must be sufficient for all receivers to
   receive, with a high probability, at least one packet disclosing the
   last useful key (i.e., the key used for the last non-empty packet
   sent).

3.1.3.  Time Interval Schedule

   The sender must determine the following parameters:

   o  T_0, the start time corresponding to the beginning of the session,
      i.e., the beginning of time interval 0 (in NTP timestamp format);

   o  T_int, the interval duration (in milliseconds), usually ranging
      from 100 milliseconds to 1 second;

   o  d, the key disclosure delay (in number of intervals).  It is the
      time to wait before disclosing a key;

Roca, et al.             Expires March 20, 2010                [Page 20]

Internet-Draft            TESLA in ALC and NORM           September 2009

   o  N, the length of a key chain;

   The correct choice of T_int, d, and N is crucial for the efficiency
   of the scheme.  For instance, a T_int * d product that is too long
   will cause excessive delay in the authentication process.  A T_int *
   d product that is too short prevents many receivers from verifying
   packets.  A N * T_int product that is too small will cause the sender
   to switch too often to new key chains.  A N that is too long with
   respect to the expected session duration (if known) will require the
   sender to compute too many useless keys.  [RFC4082] sections 3.2 and
   3.6 give general guidelines for initializing these parameters.

   The T_0, T_int, d and N parameters MUST NOT be changed during the
   lifetime of the session.  This restriction is meant to prevent
   introducing vulnerabilities.  For instance if a sender was authorized
   to change the key disclosure schedule, a receiver that did not
   receive the change notification would still believe in the old key
   disclosure schedule, thereby creating vulnerabilities [RFC4082].

3.1.4.  Timing Parameters

   In indirect time synchronization mode, the sender must determine the
   following parameter:

   o  D^O_t, the upper bound of the lag of the sender's clock with
      respect to the time reference.

   The D^O_t parameter MUST NOT be changed during the lifetime of the
   session.

3.2.  TESLA Signaling Messages

   At a sender, TESLA produces two types of signaling information:

   o  The bootstrap information: it can be either sent out-of-band or
      in-band.  In the latter case, a digitally signed packet contains
      all the information required to bootstrap TESLA at a receiver;

   o  The direct time synchronization response, which enables a receiver
      to finish a direct time synchronization;

3.2.1.  Bootstrap Information

   In order to initialize the TESLA component at a receiver, the sender
   must communicate some key information in a secure way.  This
   information can be sent in-band or out-of-band, as discussed in
   Section 2.2.  In this section we only consider the in-band scheme.

Roca, et al.             Expires March 20, 2010                [Page 21]

Internet-Draft            TESLA in ALC and NORM           September 2009

   The TESLA bootstrap information message MUST be digitally signed
   (Section 3.3.2).  The goal is to enable a receiver to check the
   packet source and packet integrity.  Then, the bootstrap information
   can be:

   o  unicast to a receiver during a direct time synchronization
      request/response exchange;

   o  broadcast to all receivers.  This is typically the case in
      indirect time synchronization mode.  It can also be used in direct
      time synchronization mode, for instance when a large number of
      clients arrive at the same time, in which case it is more
      efficient to answer globally.

   Let us consider situations where the bootstrap information is
   broadcast.  This message should be broadcast at the beginning of the
   session, before data packets are actually sent.  This is particularly
   important with ALC or NORM sessions in "push" mode, when all clients
   join the session in advance.  For improved reliability, bootstrap
   information might be sent a certain number of times.

   A periodic broadcast of the bootstrap information message could also
   be useful when:

   o  the ALC session uses an "on-demand" mode, clients arriving at
      their own discretion;

   o  some clients experience an intermittent connectivity.  This is
      particularly important when several key chains are used in an ALC
      or NORM session, since there is a risk that a receiver loses all
      the commitments to the new key chain.

   A balance must be found between the signaling overhead and the
   maximum initial waiting time at the receiver before starting the
   delayed authentication process.  A period of a few seconds for the
   transmission of this bootstrap information is often a reasonable
   value.

3.2.2.  Direct Time Synchronization Response

   In Direct Time Synchronization, upon receipt of a synchronization
   request, the sender records its local time, t_s, and sends a response
   message that contains both t_r and t_s (Section 2.4.1).  This message
   is unicast to the receiver.  This Direct Time Synchronization
   Response message MUST be digitally signed in order to enable a
   receiver to check the packet source and packet integrity
   (Section 3.3.2).  The receiver MUST also be able to associate this
   response and his request, which is the reason why t_r is included in

Roca, et al.             Expires March 20, 2010                [Page 22]

Internet-Draft            TESLA in ALC and NORM           September 2009

   the response message.

3.3.  TESLA Authentication Information

   At a sender, TESLA produces three types of security tags:

   o  an authentication tag, in case of data packets, and which contains
      the MAC of the packet;

   o  a digital signature, in case of one of the two TESLA signaling
      packets, namely a Bootstrap Information Message or a Direct Time
      Synchronization Response; and

   o  an optional group authentication tag, that can be added to all the
      packets to mitigate attacks coming from outside of the group.

   Because of interdependencies, their computation MUST follow a strict
   order:

   o  first of all, compute the authentication tag (with data packet) or
      the digital signature (with signaling packet);

   o  finally compute the Group Mac;

3.3.1.  Authentication Tags

   All the data packets sent MUST have an authentication tag containing:

   o  the interval index, i, which is also the index of the key used for
      computing the MAC of this packet;

   o  the MAC of the message: MAC(K'_i, M), where K'_i=F'(K_i);

   o  either a disclosed key (that belongs to the current key chain or
      the previous key chain), or a commitment to a new key chain, or no
      key at all;

   The computation of MAC(K'_i, M) MUST include the ALC or NORM header
   (with the various header extensions) and the payload (when
   applicable).  The UDP/IP headers MUST NOT be included.  During this
   computation, the MAC(K'_i, M) field of the authentication tag MUST be
   set to 0.

3.3.2.  Digital Signatures

   The Bootstrap Information message (with the in-band bootstrap scheme)
   and Direct Time Synchronization Response message (with the indirect
   time synchronization scheme) both need to be signed by the sender.

Roca, et al.             Expires March 20, 2010                [Page 23]

Internet-Draft            TESLA in ALC and NORM           September 2009

   These two messages contain a "Signature" field to hold the digital
   signature.  The bootstrap information message also contains the
   "Signature Encoding Algorithm", the "Signature Cryptographic
   Function", and the "Signature Length" fields that enable a receiver
   to process the "Signature" field.  Note that there is no such
   "Signature Encoding Algorithm", "Signature Cryptographic Function"
   and "Signature Length" fields in case of a Direct Time
   Synchronization Response message since it is assumed that these
   parameters are already known (i.e., the receiver either received a
   bootstrap information message before, or these values have been
   communicated out-of-band).

   Several "Signature Encoding Algorithms" can be used, including
   RSASSA-PKCS1-v1_5, the default, and RSASSA-PSS (Section 7).  With
   these encodings, SHA-256 is the default "Signature Cryptographic
   Function".

   The computation of the signature MUST include the ALC or NORM header
   (with the various header extensions) and the payload when applicable.
   The UDP/IP headers MUST NOT be included.  During this computation,
   the "Signature" field MUST be set to 0 as well as the optional Group
   MAC, when present, since this Group MAC is calculated later on.

   More specifically, from [RFC4359]: digital signature generation is
   performed as described in [RFC3447], Section 8.2.1 for RSASSA-PKCS1-
   v1_5 and Section 8.1.1 for RSASSA-PSS.  The authenticated portion of
   the packet is used as the message M, which is passed to the signature
   generation function.  The signer's RSA private key is passed as K. In
   summary (when SHA-256 is used), the signature generation process
   computes a SHA-256 hash of the authenticated packet bytes, signs the
   SHA-256 hash using the private key, and encodes the result with the
   specified RSA encoding type.  This process results in a value S,
   which is the digital signature to be included in the packet.

   With RSASSA-PKCS1-v1_5 and RSASSA-PSS signatures, the size of the
   signature is equal to the "RSA modulus", unless the "RSA modulus" is
   not a multiple of 8 bits.  In that case, the signature MUST be
   prepended with between 1 and 7 bits set to zero such that the
   signature is a multiple of 8 bits [RFC4359].  The key size, which in
   practice is also equal to the "RSA modulus", has major security
   implications.  [RFC4359] explains how to choose this value depending
   on the maximum expected lifetime of the session.  This choice is out
   of the scope of this document.

3.3.3.  Group MAC Tags

   An optional Group MAC can be used to mitigate DoS attacks coming from
   attackers that are not group members [RFC4082].  This feature assumes

Roca, et al.             Expires March 20, 2010                [Page 24]

Internet-Draft            TESLA in ALC and NORM           September 2009

   that a group key, K_g, is shared by the sender and all receivers.
   When the attacker is not a group member, the benefits of adding a
   group MAC to every packet sent are threefold:

   o  a receiver can immediately drop faked packets, without having to
      wait for the disclosure delay, d;

   o  a sender can immediately drop faked direct time synchronization
      requests, and avoid to check the digital signature, a computation
      intensive task;

   o  a receiver can immediately drop faked direct time synchronization
      response and bootstrap messages, without having to verify the
      digital signature, a computation intensive task;

   The computation of the group MAC, MAC(K_g, M), MUST include the ALC
   or NORM header (with the various header extensions) and the payload
   when applicable.  The UDP/IP headers MUST NOT be included.  During
   this computation, the Group MAC field MUST be set to 0.  However the
   digital signature (e.g., of a bootstrap message) and the MAC fields
   (e.g., of an authentication tag), when present, MUST have been
   calculated since they are included in the Group MAC calculation
   itself.  Then the sender truncates the MAC output to keep the n_w
   most significant bits and stores the result in the Group MAC field.

   This scheme features a few limits:

   o  it is of no help if a group member (who knows K_g) impersonates
      the sender and sends forged messages to other receivers;

   o  it requires an additional MAC computing for each packet, both at
      the sender and receiver sides;

   o  it increases the size of the TESLA authentication headers.  In
      order to limit this problem, the length of the truncated output of
      the MAC, n_w, SHOULD be kept small (e.g., 32 bits) (see [RFC3711]
      section 9.5).  As a side effect, the authentication service is
      significantly weakened: the probability that any forged packet be
      successfully authenticated becomes one in 2^32.  Since the group
      MAC check is only a pre-check that must be followed by the
      standard TESLA authentication check, this is not considered to be
      an issue.

   For a given use-case, the benefits brought by the group MAC must be
   balanced against these limitations.

   Note that the Group MAC function can be different from the TESLA MAC
   function (e.g., it can use a weaker but faster MAC function).  Note

Roca, et al.             Expires March 20, 2010                [Page 25]

Internet-Draft            TESLA in ALC and NORM           September 2009

   also that the mechanism by which the group key, K_g, is communicated
   to all group members, and perhaps periodically updated, is out of the
   scope of this document.

3.4.  Format of TESLA Messages and Authentication Tags

   This section specifies the format of the various kinds of TESLA
   messages and authentication tags sent by the session's sender.
   Because these TESLA messages are carried as EXT_AUTH header
   extensions of the ALC or NORM packets (Section 5), the following
   formats do not start on 32 bit word boundaries.

3.4.1.  Format of a Bootstrap Information Message

   When bootstrap information is sent in-band, the following message is
   used:

Roca, et al.             Expires March 20, 2010                [Page 26]

Internet-Draft            TESLA in ALC and NORM           September 2009

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                                  +-+-+-+-+-+-+-+-+  ---
                                                  | V |resvd|S|G|A|  ^
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
  |       d       |    PRF Type   | MAC Func Type |Gr MAC Fun Type|  | f
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | i
  |   SigEncAlgo  | SigCryptoFunc |       Signature Length        |  | x
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | e
  |            Reserved           |             T_int             |  | d
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
  |                                                               |  | l
  +                  T_0 (NTP timestamp format)                   +  | e
  |                                                               |  | n
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | g
  |                      N (Key Chain Length)                     |  | t
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | h
  |                    Current Interval Index i                   |  v
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ---
  |                                                               |
  ~                 Current Key Chain Commitment  +-+-+-+-+-+-+-+-+
  |                                               |   Padding     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +                                                               +
  ~                           Signature                           ~
  +                                               +-+-+-+-+-+-+-+-+
  |                                               |    Padding    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |P|                                                             |
  +-+       D^O_t Extension (optional, present if A==1)           +
  |    (NTP timestamp diff, positive if P==1, negative if P==0)   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ~                      Group MAC (optional)                     ~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 2: Bootstrap information format.

   The format of the bootstrap information is depicted in Figure 2.  The
   fields are:

   "V" (Version) field (2 bits):

      The "V" field contains the version number of the protocol.  For
      this specification, the value of 0 MUST be used.

   "Reserved" field (3 bits):

Roca, et al.             Expires March 20, 2010                [Page 27]

Internet-Draft            TESLA in ALC and NORM           September 2009

      This is a reserved field that MUST be set to zero in this
      specification.

   "S" (Single Key Chain) flag (1 bits):

      The "S" flag indicates whether this TESLA session is restricted to
      a single key chain (S==1) or relies on one or multiple key chains
      (S==0).

   "G" (Group MAC Present) flag (1 bits):

      The "G" flag indicates whether the Group MAC feature is used
      (G==1) or not (G==0).  When it is used, a "Group MAC" field is
      added to all the packets containing a TESLA EXT_AUTH Header
      Extension (including this bootstrap message).

   "A" flag (1 bit):

      The "A" flag indicates whether the P flag and D^O_t fields are
      present (A==1) or not (A==0).  In indirect time synchronization
      mode, A MUST be equal to 1 since these fields are needed.

   "d" field (8 bits):

      d is an unsigned integer that defines the key disclosure delay (in
      number of intervals). d MUST be greater or equal to 2.

   "PRF Type" field (8 bits):

      The "PRF Type" is the reference number of the f function used to
      derive the F (for key chain) and F' (for MAC keys) functions
      (Section 7).

   "MAC Function Type" field (8 bits):

      The "MAC Function Type" is the reference number of the function
      used to compute the MAC of the packets (Section 7).

   "Group MAC Function Type" field (8 bits):

      When G==1, this field contains the reference number of the
      cryptographic MAC function used to compute the group MAC
      (Section 7).  When G==0, this field MUST be set to zero.

   "Signature Encoding Algorithm" field (8 bits):

Roca, et al.             Expires March 20, 2010                [Page 28]

Internet-Draft            TESLA in ALC and NORM           September 2009

      The "Signature Encoding Algorithm" is the reference number
      (Section 7) of the digital signature used to authenticate this
      bootstrap information and included in the "Signature" field.

   "Signature Cryptographic Function" field (8 bits):

      The "Signature Cryptographic Function" is the reference number
      (Section 7) of the cryptographic function used within the digital
      signature.

   "Signature Length" field (16 bits):

      The "Signature Length" is an unsigned integer that indicates the
      signature field size in bytes in the "Signature Extension" field.
      This is also the signature key length, since both parameters are
      equal.

   "Reserved" fields (16 bits):

      This is a reserved field that MUST be set to zero in this
      specification.

   "T_int" field (16 bits):

      T_int is an unsigned 16 bit integer that defines the interval
      duration (in milliseconds).

   "T_0" field (64 bits):

      "T_0" is a timestamp in NTP timestamp format that indicates the
      beginning of the session, i.e., the beginning of time interval 0.

   "N" field (32 bits):

      "N" is an unsigned integer that indicates the key chain length.
      There are N + 1 keys per chain.

   "i" (Interval Index of K_i) field (32 bits):

      "i" is an unsigned integer that indicates the current interval
      index when this bootstrap information message is sent.

   "Current Key Chain Commitment" field (variable size, padded if
   necessary for 32 bit word alignment):

      "Key Chain Commitment" is the commitment to the current key chain,
      i.e., the key chain corresponding to interval i.  For instance,
      with the first key chain, this commitment is equal to F(K_0), with

Roca, et al.             Expires March 20, 2010                [Page 29]

Internet-Draft            TESLA in ALC and NORM           September 2009

      the second key chain, this commitment is equal to F(K_{N+1}),
      etc.).  If need be, this field is padded (with 0) up to a multiple
      of 32 bits.

   "Signature" field (variable size, padded if necessary for 32 bit word
   alignment):

      The "Signature" field is mandatory.  It contains a digital
      signature of this message, as specified by the encoding algorithm,
      cryptographic function and key length parameters.  If the
      signature length is not multiple of 32 bits, this field is padded
      with 0.

   "P" flag (optional, 1 bit if present):

      The "P" flag is optional and only present if the A flag is equal
      to 1..  It is only used in indirect time synchronization mode.
      This flag indicates whether the D^O_t NTP timestamp difference is
      positive (P==1) or negative (P==0).

   "D^O_t" field (optional, 63 bits if present):

      The "D^O_t" field is optional and only present if the A flag is
      equal to 1.  It is only used in indirect time synchronization
      mode.  It is the upper bound of the lag of the sender's clock with
      respect to the time reference.  When several time references are
      specified (e.g., several NTP servers), then D^O_t is the maximum
      upper bound of the lag with each time reference.  D^O_t is
      composed of two unsigned integers, as with NTP timestamps: the
      first 31 bits give the time difference in seconds and the
      remaining 32 bits give the sub-second time difference.

   "Group MAC" field (optional, variable length, multiple of 32 bits):

      This field contains the group MAC, calculated with the group key,
      K_g, shared by all group members.  The field length, in bits, is
      given by n_w which is known once the group MAC function type is
      known (Section 7).

   Note that the first byte and the following seven 32-bit words are
   mandatory fixed length fields.  The Current Key Chain Commitment and
   Signature fields are mandatory but variable length fields.  The
   remaining D^O_t and Group MAC fields are optional.

   In order to prevent attacks, some parameters MUST NOT be changed
   during the lifetime of the session (Section 3.1.3, Section 3.1.4).
   The following table summarizes the parameters status:

Roca, et al.             Expires March 20, 2010                [Page 30]

Internet-Draft            TESLA in ALC and NORM           September 2009

   +--------------------------+----------------------------------------+
   |         Parameter        |                 Status                 |
   +--------------------------+----------------------------------------+
   |             V            |     set to 0 in this specification     |
   |                          |                                        |
   |             S            |      static (during whole session)     |
   |                          |                                        |
   |             G            |      static (during whole session)     |
   |                          |                                        |
   |             A            |      static (during whole session)     |
   |                          |                                        |
   |            T_O           |      static (during whole session)     |
   |                          |                                        |
   |           T_int          |      static (during whole session)     |
   |                          |                                        |
   |             d            |      static (during whole session)     |
   |                          |                                        |
   |             N            |      static (during whole session)     |
   |                          |                                        |
   |    D^O_t (if present)    |      static (during whole session)     |
   |                          |                                        |
   |         PRF Type         |      static (during whole session)     |
   |                          |                                        |
   |     MAC Function Type    |      static (during whole session)     |
   |                          |                                        |
   |    Signature Encoding    |      static (during whole session)     |
   |         Algorithm        |                                        |
   |                          |                                        |
   |    Signature Crypto.     |      static (during whole session)     |
   |         Function         |                                        |
   |                          |                                        |
   |     Signature Length     |      static (during whole session)     |
   |                          |                                        |
   |   Group MAC Func.  Type  |      static (during whole session)     |
   |                          |                                        |
   |             i            | dynamic (related to current key chain) |
   |                          |                                        |
   |            K_i           | dynamic (related to current key chain) |
   |                          |                                        |
   |         signature        |        dynamic, packet dependent       |
   |                          |                                        |
   |  Group MAC (if present)  |        dynamic, packet dependent       |
   +--------------------------+----------------------------------------+

Roca, et al.             Expires March 20, 2010                [Page 31]

Internet-Draft            TESLA in ALC and NORM           September 2009

3.4.2.  Format of a Direct Time Synchronization Response

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                                    +-+-+-+-+-+-+-+-+
                                                    |    Reserved   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                     t_s (NTP timestamp)                       +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                     t_r (NTP timestamp)                       +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    ~                           Signature                           ~
    +                                               +-+-+-+-+-+-+-+-+
    |                                               |    Padding    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                     Group MAC (optional)                      ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 3: Format of a Direct Time Synchronization Response

   The response to a direct time synchronization request contains the
   following information:

   "Reserved" fields (8 bits):

      This is a reserved field that MUST be set to zero in this
      specification.

   "t_s" (NTP timestamp, 64 bits):

      t_s is a timestamp in NTP timestamp format that corresponds to the
      sender local time value when receiving the direct time
      synchronization request message.

   "t_r" (NTP timestamp, 64 bits):

      t_r is a timestamp in NTP timestamp format that contains the
      receiver local time value received in the direct time
      synchronization request message.

   "Signature" field (variable size, padded if necessary for 32 bit word

Roca, et al.             Expires March 20, 2010                [Page 32]

Internet-Draft            TESLA in ALC and NORM           September 2009

   alignment):

      The "Signature" field is mandatory.  It contains a digital
      signature of this message, as specified by the encoding algorithm,
      cryptographic function and key length parameters communicated in
      the bootstrap information message (if applicable) or out-of-band.
      If the signature length is not multiple of 32 bits, this field is
      padded with 0.

   "Group MAC" field (optional, variable length, multiple of 32 bits):

      This field contains the Group MAC, calculated with the group key,
      K_g, shared by all group members.  The field length, in bits, is
      given by n_w, which is known once the group MAC function type is
      known (Section 7).

3.4.3.  Format of a Standard Authentication Tag

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                                    +-+-+-+-+-+-+-+-+
                                                    |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                i (Interval Index of K'_i)                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                    Disclosed Key K_{i-d}                      ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                       MAC(K'_i, M)            +-+-+-+-+-+-+-+-+
    |                                               |   Padding     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                     Group MAC (optional)                      ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 4: Format of the  Standard Authentication Tag

   Figure 4 shows the format of the Standard Authentication Tag:

   "Reserved" field (8 bits):

      The "Reserved" field is not used in the current specification and
      MUST be set to zero by the sender.

   "i" (Interval Index) field (32 bits):

Roca, et al.             Expires March 20, 2010                [Page 33]

Internet-Draft            TESLA in ALC and NORM           September 2009

      i is the interval index associated to the key (K'_i) used to
      compute the MAC of this packet.

   "Disclosed Key" (variable size, non padded):

      The "Disclosed Key" is the key used for interval i-d: K_{i-d}.
      There is no padding between the "Disclosed Key" and "MAC(K'_i, M)"
      fields, and the latter MAY not start on a 32 bit boundary,
      depending on the n_p parameter.

   "MAC(K'_i, M)" (variable size, padded if necessary for 32 bit word
   alignment):

      MAC(K'_i, M) is the truncated message authentication code of the
      current packet.  Only the n_m most significant bits of the MAC
      output are kept [RFC2104].

   "Group MAC" field (optional, variable length, multiple of 32 bits):

      This field contains the Group MAC, calculated with a group key,
      K_g, shared by all group members.  The field length is given by
      n_w, in bits.

   Note that because a key cannot be disclosed before the disclosure
   delay, d, the sender MUST NOT use this tag during the first d
   intervals of the session: {0 .. d-1} (inclusive).  Instead the sender
   MUST use an Authentication Tag Without Key Disclosure.

3.4.4.  Format of an Authentication Tag Without Key Disclosure

   The authentication tag without key disclosure is meant to be used in
   situations where a high number of packets are sent in a given time
   interval.  In such a case, it can be advantageous to disclose the
   K_{i-d} key only in a subset of the packets sent, using a Standard
   Authentication Tag, and use the shortened version that does not
   disclose the K_{i-d} key in the remaining packets.  It is left to the
   implementer to decide how many packets should disclose the K_{i-d}
   key.  This Authentication Tag Without Key Disclosure MUST also be
   used during the first d intervals: {0 .. d-1} (inclusive).

Roca, et al.             Expires March 20, 2010                [Page 34]

Internet-Draft            TESLA in ALC and NORM           September 2009

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                                    +-+-+-+-+-+-+-+-+
                                                    |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                i (Interval Index of K'_i)                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                       MAC(K'_i, M)            +-+-+-+-+-+-+-+-+
    |                                               |   Padding     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                     Group MAC (optional)                      ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 5: Format of the Authentication Tag Without Key Disclosure

3.4.5.  Format of an Authentication Tag with a ``New Key Chain''
        Commitment

   During the last n_tx_newkcc intervals of the current key chain, the
   sender SHOULD send commitments to the next key chain.  This is done
   by replacing the disclosed key of the authentication tag with the new
   key chain commitment, F(K_{N+1}) (or F(K_{2N+2}) in case of a switch
   between the second and third key chains, etc.).  Figure 6 shows the
   corresponding format.

   Note that since there is no padding between the "F(K_{N+1})" and
   "MAC(K'_i, M)" fields, this latter MAY not start on a 32 bit
   boundary, depending on the n_p parameter.

Roca, et al.             Expires March 20, 2010                [Page 35]

Internet-Draft            TESLA in ALC and NORM           September 2009

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                                    +-+-+-+-+-+-+-+-+
                                                    |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                i (Interval Index of K'_i)                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~              New Key Commitment F(K_{N+1})                    ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                       MAC(K'_i, M)            +-+-+-+-+-+-+-+-+
    |                                               |   Padding     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                     Group MAC (optional)                      ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 6: Format of the Authentication Tag with a New Key Chain
                                Commitment

3.4.6.  Format of an Authentication Tag with a ``Last Key of Old Chain''
        Disclosure

   During the first n_tx_lastkey intervals of the new key chain after
   the disclosing interval, d, the sender SHOULD disclose the last key
   of the old key chain.  This is done by replacing the disclosed key of
   the authentication tag with the last key of the old chain, K_N (or
   K_{2N+1} in case of a switch between the second and third key chains,
   etc.).  Figure 7 shows the corresponding format.

   Note that since there is no padding between the "K_N" and "MAC(K'_i,
   M)" fields, this latter MAY not start on a 32 bit boundary, depending
   on the n_p parameter.

Roca, et al.             Expires March 20, 2010                [Page 36]

Internet-Draft            TESLA in ALC and NORM           September 2009

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                                    +-+-+-+-+-+-+-+-+
                                                    |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                i (Interval Index of K'_i)                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                  Last Key of Old Chain, K_N                   ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                       MAC(K'_i, M)            +-+-+-+-+-+-+-+-+
    |                                               |   Padding     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                     Group MAC (optional)                      ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 7: Format of the authentication tag with an old chain last key
                                disclosure

Roca, et al.             Expires March 20, 2010                [Page 37]

Internet-Draft            TESLA in ALC and NORM           September 2009

4.  Receiver Operations

   This section describes the TESLA operations at a receiver.

4.1.  Verification of the Authentication Information

   This section details the computation steps required to verify each of
   the three possible authentication information of an incoming packet.
   The verification MUST follow a strict order:

   o  then verify the digital signature (with TESLA signaling packets)
      or enter the TESLA authentication process (with data packets)

4.1.1.  Processing the Group MAC Tag

   Upon receiving a packet containing a Group MAC Tag, the receiver
   recomputes the Group MAC and compares it to the value carried in the
   packet.  If the check fails, the packet MUST be immediately dropped.

   More specifically, recomputing the Group MAC requires to save the
   value of the Group MAC field, to set this field to 0, and to do the
   same computation as a sender does (see Section 3.3.3).

4.1.2.  Processing the Digital Signature

   Upon receiving a packet containing a digital signature, the receiver
   verifies the signature as follows.

   The computation of the signature MUST include the ALC or NORM header
   (with the various header extensions) and the payload when applicable.
   The UDP/IP headers MUST NOT be included.  During this computation,
   the "Signature" field MUST be set to 0 as well as the optional Group
   MAC, when present.

   From [RFC4359]: Digital signature verification is performed as
   described in [RFC3447], Section 8.2.2 (RSASSA-PKCS1-v1_5) and
   [RFC3447], Section 8.1.2 (RSASSA-PSS).  Upon receipt, the digital
   signature is passed to the verification function as S. The
   authenticated portion of the packet is used as the message M, and the
   RSA public key is passed as (n, e).  In summary (when SHA-256 is

Roca, et al.             Expires March 20, 2010                [Page 38]

Internet-Draft            TESLA in ALC and NORM           September 2009

   used), the verification function computes a SHA-256 hash of the
   authenticated packet bytes, decrypts the SHA-256 hash in the packet,
   and validates that the appropriate encoding was applied.  The two
   SHA-256 hashes are compared, and if they are identical the validation
   is successful.

   It is assumed that the receivers have the possibility to retrieve the
   sender's public key required to check this digital signature
   (Section 2.2).  This document does not specify how the public key of
   the sender is communicated reliably and in a secure way to all
   possible receivers.

4.1.3.  Processing the Authentication Tag

   When a receiver wants to authenticate a packet using an
   Authentication Tag and when he has the key for the associated time
   interval (i.e., after the disclosing delay, d), the receiver
   recomputes the MAC and compares it to the value carried in the
   packet.  If the check fails, the packet MUST be immediately dropped.

   More specifically, recomputing the MAC requires to save the value of
   the MAC field, to set this field to 0, and to do the same computation
   as a sender does (see Section 3.3.1).

4.2.  Initialization of a Receiver

   A receiver MUST be initialized before being able to authenticate the
   source of incoming packets.  This can be done by an out-of-band
   mechanism or an in-band mechanism (Section 2.2).  Let us focus on the
   in-band mechanism.  Two actions must be performed:

   o  receive and process a bootstrap information message, and

   o  calculate an upper bound of the sender's local time.  To that
      purpose, the receiver must perform time synchronization.

4.2.1.  Processing the Bootstrap Information Message

   A receiver must first receive a packet containing the bootstrap
   information, digitally signed by the sender.  Once the bootstrap
   information has been authenticated (sec Section 4.1), the receiver
   can initialize its TESLA component.  The receiver MUST then ignore
   the following bootstrap information messages, if any.  There is an
   exception though: when a new key chain is used and if a receiver
   missed all the commitments for this new key chain, then this receiver
   MUST process one of the future Bootstrap information messages (if
   any) in order to be able to authenticate the incoming packets
   associated to this new key chain.

Roca, et al.             Expires March 20, 2010                [Page 39]

Internet-Draft            TESLA in ALC and NORM           September 2009

   Before TESLA has been initialized, a receiver MUST discard incoming
   packets other than the bootstrap information message and direct time
   synchronization response.

4.2.2.  Performing Time Synchronization

   First of all, the receiver must know whether the ALC or NORM session
   relies on direct or indirect time synchronization.  This information
   is communicated by an out-of-band mechanism (for instance when
   describing the various parameters of an ALC or NORM session.  In some
   cases, both mechanisms might be available and the receiver can choose
   the preferred technique.

4.2.2.1.  Direct Time Synchronization

   In case of a direct time synchronization, a receiver MUST synchronize
   with the sender.  To that purpose, the receiver sends a direct time
   synchronization request message.  This message includes the local
   time (in NTP timestamp format) at the receiver when sending the
   message.  This timestamp will be copied in the sender's response for
   the receiver to associate the response to the request.

   The direct time synchronization request message format is the
   following:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                     t_r (NTP timestamp)                       +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                     Group MAC (optional)                      ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 8: Format of a Direct Time Synchronization Request

   The direct time synchronization request (Figure 8) contains the
   following information:

   "t_r" (NTP timestamp, 64 bits):

      t_r is a timestamp in NTP timestamp format that contains the
      receiver local time value when sending this direct time
      synchronization request message;

   "Group MAC" field (optional, variable length, multiple of 32 bits):

Roca, et al.             Expires March 20, 2010                [Page 40]

Internet-Draft            TESLA in ALC and NORM           September 2009

      This field contains the Group MAC, calculated with the group key,
      K_g, shared by all group members.  The field length, in bits, is
      given by n_w, which is known once the Group MAC function type is
      known (Section 7).

   The receiver then awaits a response message (Section 3.4.2).  Upon
   receiving this message, the receiver:

      checks that this response relates to the request, by comparing the
      t_r fields;

      checks the Group MAC if present;

      checks the signature;

      retrieves the t_s value and calculates D_t (Section 2.4.1);

   Note that in an ALC session, the direct time synchronization request
   message is sent to the sender by an out-of-band mechanism that is not
   specified by the current document.

4.2.2.2.  Indirect Time Synchronization

   With the indirect time synchronization method, the sender MAY provide
   out-of-band the URL or IP address of the NTP server(s) he trusts
   along with an OPTIONAL certificate for each NTP server.  When several
   NTP servers are specified, a receiver MUST choose one of them.  This
   document does not specify how the choice is made, but for the sake of
   scalability, the clients SHOULD NOT use the same server if several
   possibilities are offered.  The NTP synchronization between the NTP
   server and the receiver MUST be authenticated, either using the
   certificate provided by the server, or another certificate the client
   may obtain for this NTP server.

   Then the receiver computes the time offset between itself and the NTP
   server chosen.  Note that the receiver does not need to update the
   local time, (which often requires root privileges), computing the
   time offset is sufficient.

   Since the offset between the server and the time reference, D^O_t, is
   indicated in the bootstrap information message (or communicated out-
   of-band), the receiver can now calculate an upper bound of the
   sender's local time (Section 2.4.2).

   Note that this scenario assumes that each client trusts the sender
   and accepts to align its NTP configuration to that of the sender,
   using one of the NTP server(s) suggested.  If this assumption does
   not hold, the client MUST NOT use the NTP indirect time

Roca, et al.             Expires March 20, 2010                [Page 41]

Internet-Draft            TESLA in ALC and NORM           September 2009

   synchronization method (Section 2.3.2).

4.3.  Authentication of Received Packets

   The receiver can now authenticate incoming packets (other than
   bootstrap information and direct time synchronization response
   packets).  To that purpose, he MUST follow different steps (see
   [RFC4082] section 3.5):

   1.  The receiver parses the different packet headers.  If none of the
       four TESLA authentication tags is present, the receiver MUST
       discard the packet.  If the session is in "Single Key Chain" mode
       (e.g., when the "S" flag is set in the bootstrap information
       message), then the receiver MUST discard any packet containing an
       Authentication Tag With a New Key Chain Commitment or an
       Authentication Tag With a Last Key of Old Chain Disclosure.

   2.  Safe packet test: When the receiver receives packet P_j, it first
       records the local time T at which the packet arrived.  The
       receiver then computes an upper bound t_j on the sender's clock
       at the time when the packet arrived: t_j = T + D_t.  The receiver
       then computes the highest interval the sender could possibly be
       in: highest_i = floor((t_j - T_0) / T_int).  He also retrieves
       the "i" interval index from the authentication tag.  The receiver
       can now proceed with the "safe packet" test.  If highest_i < i +
       d, then the sender is not yet in the interval during which it
       discloses the key K_i.  The packet is safe (but not necessarily
       authentic).  If the test fails, the packet is unsafe, and the
       receiver MUST discard the packet.

   3.  Group MAC test: if the optional Group MAC tag is present and if
       the session uses this feature, then verify the Group MAC
       (Section 4.1.1).  If the verification fails, the packet MUST be
       immediately dropped.  A packet that does not contain a Group MAC
       tag whereas the session uses this feature MUST be immediately
       dropped.  On the opposite, if a packet contains a Group MAC tag
       whereas the session does not use this feature, this tag MUST be
       ignored.

   4.  Disclosed Key processing: When the packet discloses a key (i.e.,
       with a Standard Authentication Tag, or with an Authentication Tag
       with a ``Last Key of Old Chain'' Disclosure), the following tests
       are performed:

       *  New key index test: the receiver checks whether a legitimate
          key already exists with the same index (i.e., i-d).  If such a
          legitimate key exists, the receiver compares its value with
          the current disclosed key and if they are identical, skips the

Roca, et al.             Expires March 20, 2010                [Page 42]

Internet-Draft            TESLA in ALC and NORM           September 2009

          "Unverifiable key test" and "Key verification test".  If such
          a legitimate key exists but the values differ, the receiver
          MUST discard the packet.

       *  Unverifiable key test: when the disclosed key index is new, it
          is possible that no earlier disclosed and legitimate key
          exists for this key chain, thereby preventing the verification
          of the disclosed key.  This happens when the disclosed key
          belongs to the old key chain and no commitment to this old key
          chain has ever been received (e.g., because the first
          bootstrap packet received by a latecomer is for the current
          key chain, and therefore includes a commitment to the current
          key chain, not the previous one).  When this happens, the
          receiver MUST ignore the disclosed key (anyway useless) and
          skip the "Key verification test".

       *  Key verification test: If the disclosed key index is new and
          the key can be verified, the receiver checks the legitimacy of
          K_{i-d} by verifying, for some earlier disclosed and
          legitimate key K_v (with v < i-d), that K_v and F^{i-d-
          v}(K_{i-d}) are identical.  In other words, the receiver
          checks the disclosed key by computing the necessary number of
          PRF functions to obtain a previously disclosed and legitimate
          (i.e., verified) key.  If the key verification fails, the
          receiver MUST discard the packet.  If the key verification
          succeeds, this key is said legitimate and is stored by the
          receiver, as well as all the keys between indexes v and i-d.

   6.  The receiver then buffers the packet for a later authentication,
       once the corresponding key will be disclosed (after d time
       intervals) or deduced from another key (if all packets disclosing
       this key are lost).  In some situations, this packet might also
       be discarded later on, if it turns out that the receiver will
       never be able to deduce the associated key.

   7.  Authentication test: Let v be the smallest index of the
       legitimate keys known by the receiver so far.  For all the new
       keys K_w, with v < w <= i-d, that have been either disclosed by

Roca, et al.             Expires March 20, 2010                [Page 43]

Internet-Draft            TESLA in ALC and NORM           September 2009

       this packet (i.e., K_{i-d}) or derived by K_{i-d} (i.e., keys in
       interval {v+1,.. i-d-1}), the receiver verifies the authenticity
       of the safe packets buffered for the corresponding interval w.
       To authenticate one of the buffered packets P_h containing
       message M_h protected with a MAC that used key index w, the
       receiver will compute K'_w = F'(K_w) from which it can compute
       MAC( K'_w, M_h).  If this MAC does not equal the MAC stored in
       the packet, the receiver MUST discard the packet.  If the two MAC
       are equal, the packet is successfully authenticated and the
       receiver continues processing it.

   8.  Authenticated new key chain commitment processing: If the
       authenticated packet contains a new key chain commitment and if
       no verified commitment already exists, then the receiver stores
       the commitment to the new key chain.  Then, if there are non
       authenticated packets for a previous chain (i.e., the key chain
       before the current one), all these packets can be discarded
       (Section 4.4).

   9.  The receiver continues the ALC or NORM processing of all the
       packets authenticated during the authentication test.

   In this specification, a receiver using TESLA MUST immediately drop
   unsafe packets.  But the receiver MAY also decide, at any time, to
   continue an ALC or NORM session in unsafe (insecure) mode, ignoring
   TESLA extensions.  There SHOULD be an explicit user action to that
   purpose.

4.3.1.  Discarding Unnecessary Packets Earlier

   Following strictly the above steps can lead to excessive processing
   overhead in certain situations.  This is the case when a receiver
   receives packets for an unwanted object with the ALC or NORM
   protocols, i.e., an object for which the application (or the end
   user) explicitly mentioned it is not interested in.  This is also the
   case when a receiver receives packets for an already decoded object,
   or when this object has been partitioned in several blocks, for an
   already decoded block.  When such a packet is received, which is
   easily identified by looking at the receiver's status for the
   incoming ALC or NORM packet, the receiver MUST also check that the
   packet is a pure data packet that does not contain any signaling
   information of importance for the session.

   With ALC, a packet containing a "A" flag ("Close Session") or a "B"
   flag ("Close Object") MUST NOT be discarded before having been
   authenticated and processed normally.  Otherwise, the receiver can
   safely discard the incoming packet for instance just after step 1 of
   Section 4.3.  This optimization can dramatically reduce the

Roca, et al.             Expires March 20, 2010                [Page 44]

Internet-Draft            TESLA in ALC and NORM           September 2009

   processing overhead, by avoiding many useless authentication checks.

4.4.  Flushing the Non Authenticated Packets of a Previous Key Chain

   In some cases a receiver having experienced a very long disconnection
   might have lost all the disclosures of the last key(s) of a previous
   key chain.  Let j be the index of this key chain for which there
   remains non authenticated packets.  This receiver can flush all the
   packets of the key chain j if he determines that:

   o  he has just switched to a chain of index j+2 (inclusive) or
      higher;

   o  the sender has sent a commitment to the new key chain of index j+2
      (Section 3.1.2.3).  This situation requires that the receiver has
      received a packet containing such a commitment and that he has
      been able to check its integrity.  In some cases it might require
      to receive a bootstrap information message for the current key
      chain.

   If one of the above two tests succeeds, the sender can discard all
   the awaiting packets since there is no way to authenticate them.

Roca, et al.             Expires March 20, 2010                [Page 45]

Internet-Draft            TESLA in ALC and NORM           September 2009

5.  Integration in the ALC and NORM Protocols

5.1.  Authentication Header Extension Format

   The integration of TESLA in ALC or NORM is similar and relies on the
   header extension mechanism defined in both protocols.  More precisely
   this document details the EXT_AUTH==1 header extension defined in
   [RMT-BB-LCT].

   Several fields are added in addition to the HET (Header Extension
   Type) and HEL (Header Extension Length) fields (Figure 9).

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   HET (=1)    |      HEL      |  ASID |  Type |               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
    |                                                               |
    ~                                                               ~
    |                            Content                            |
    ~                                                               ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 9: Format of the TESLA EXT_AUTH header extension.

   The fields of the TESLA EXT_AUTH header extension are:

   "ASID" (Authentication Scheme IDentifier) field (4 bits):

      The "ASID" identifies the source authentication scheme or protocol
      in use.  The association between the "ASID" value and the actual
      authentication scheme is defined out-of-band, at session startup.

   "Type" field (4 bits):

      The "Type" field identifies the type of TESLA information carried
      in this header extension.  This specification defines the
      following types:

      *  0: Bootstrap Information, sent by the sender periodically or
         after a direct time synchronization request;

      *  1: Standard Authentication Tag for the on-going key chain, sent
         by the sender along with a packet;

Roca, et al.             Expires March 20, 2010                [Page 46]

Internet-Draft            TESLA in ALC and NORM           September 2009

      *  2: Authentication Tag Without Key Disclosure, sent by the
         sender along with a packet;

      *  3: Authentication Tag with a New Key Chain Commitment, sent by
         the sender when approaching the end of a key chain;

      *  4: Authentication Tag with a Last Key of Old Chain Disclosure,
         sent by the sender some time after moving to a new key chain;

      *  5: Direct Time Synchronization Request, sent by a NORM
         receiver.  This type of message is invalid in case of an ALC
         session since ALC is restricted to unidirectional
         transmissions.  Yet an external mechanism may provide the
         direct time synchronization functionality;

      *  6: Direct Time Synchronization Response, sent by a NORM sender.
         This type of message is invalid in case of an ALC session since
         ALC is restricted to unidirectional transmissions.  Yet an
         external mechanism may provide the direct time synchronization
         functionality;

   "Content" field (variable length):

      This is the TESLA information carried in the header extension,
      whose type is given by the "Type" field.

5.2.  Use of Authentication Header Extensions

   Each packet sent by the session's sender MUST contain exactly one
   TESLA EXT_AUTH header extension.

   All receivers MUST recognize EXT_AUTH but MAY not be able to parse
   its content, for instance because they do not support TESLA.  In that
   case these receivers MUST ignore the TESLA EXT_AUTH extensions.  In
   case of NORM, the packets sent by receivers MAY contain a direct
   synchronization request but MUST NOT contain any of the other five
   TESLA EXT_AUTH header extensions.

5.2.1.  EXT_AUTH Header Extension of Type Bootstrap Information

   The "bootstrap information" TESLA EXT_AUTH (Type==0) MUST be sent in
   a stand-alone control packet, rather than in a packet containing
   application data.  The reason for that is the large size of this
   bootstrap information.  By using stand-alone packets, the maximum
   payload size of data packets is only affected by the (mandatory)
   authentication information header extension.

   With ALC, the "bootstrap information" TESLA EXT_AUTH MUST be sent in

Roca, et al.             Expires March 20, 2010                [Page 47]

Internet-Draft            TESLA in ALC and NORM           September 2009

   a control packet, i.e., containing no encoding symbol.

   With NORM, the "bootstrap information" TESLA EXT_AUTH MUST be sent in
   a NORM_CMD(APPLICATION) message.

Roca, et al.             Expires March 20, 2010                [Page 48]

Internet-Draft            TESLA in ALC and NORM           September 2009

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ---
  |   HET (=1)    |    HEL (=46)  |  ASID |   0   | 0 |  0  |0|1|0|  ^
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
  |       d       |       2       |       2       |       2       |  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
  |       1       |       3       |              128              |  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
  |         0 (reserved)          |             T_int             |  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
  |                                                               |  |
  +                  T_0 (NTP timestamp format)                   +  | 5
  |                                                               |  | 2
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
  |                      N (Key Chain Length)                     |  | b
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | y
  |                    Current Interval Index i                   |  | t
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | e
  |                                                               |  | s
  +                                                               +  |
  |                                                               |  |
  +                 Current Key Chain Commitment                  +  |
  |                          (20 bytes)                           |  |
  +                                                               +  |
  |                                                               |  |
  +                                                               +  |
  |                                                               |  v
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ---
  |                                                               |  ^ 1
  +                                                               +  | 2
  |                                                               |  | 8
  .                                                               .  |
  .                           Signature                           .  | b
  .                          (128 bytes)                          .  | y
  |                                                               |  | t
  +                                                               +  | e
  |                                                               |  v s
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ---
  |                           Group MAC                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 10: Example: Format of the bootstrap information message (Type
   0), using SHA-256/1024 bit signatures, the default HMAC-SHA-256 and a
                                Group MAC.

   For instance Figure 10 shows the bootstrap information message when
   using the HMAC-SHA-256 transform for the PRF, MAC, and Group MAC

Roca, et al.             Expires March 20, 2010                [Page 49]

Internet-Draft            TESLA in ALC and NORM           September 2009

   functions, along with SHA-256/128 byte (1024 bit) key digital
   signatures (which also means that the signature field is 128 byte
   long).  The TESLA EXT_AUTH header extension is then 184 byte long
   (i.e., 46 words of 32 bits).

5.2.2.  EXT_AUTH Header Extension of Type Authentication Tag

   The four "authentication tag" TESLA EXT_AUTH (Type 1, 2, 3, and 4)
   MUST be attached to the ALC or NORM packet (data or control packet)
   that they protect.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   HET (=1)    |   HEL (=10)   |  ASID |   1   |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                i (Interval Index of K'_i)                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +                     Disclosed Key K_{i-d}                     +
    |                          (20 bytes)                           |
    +                                                               +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                         MAC(K'_i, M)                          |
    +                          (16 bytes)                           +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 11: Example: Format of the Standard Authentication Tag (Type
                    1), using the default HMAC-SHA-256.

Roca, et al.             Expires March 20, 2010                [Page 50]

Internet-Draft            TESLA in ALC and NORM           September 2009

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   HET (=1)    |   HEL (=5)    |  ASID |   2   |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                i (Interval Index of K'_i)                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                         MAC(K'_i, M)                          |
    +                          (16 bytes)                           +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 12: Example: Format of the Authentication Tag Without Key
           Disclosure (Type 2), using the default HMAC-SHA-256.

   For instance, Figure 11 and Figure 12 show the format of the
   authentication tags, respectively with and without the K_{i-d} key
   disclosure, when using the (default) HMAC-SHA-256 transform for the
   PRF and MAC functions.  In this example, the Group MAC feature is not
   used.

5.2.3.  EXT_AUTH Header Extension of Type Direct Time Synchronization
        Request

   With NORM, the "direct time synchronization request" TESLA EXT_AUTH
   (Type==7) MUST be sent by a receiver in a NORM_CMD(APPLICATION) NORM
   packet.

   With ALC, the "direct time synchronization request" TESLA EXT_AUTH
   cannot be included in an ALC packet, since ALC is restricted to
   unidirectional transmissions, from the session's sender to the
   receivers.  An external mechanism must be used with ALC for carrying
   direct time synchronization requests to the session's sender.

   In case of direct time synchronization, it is RECOMMENDED that the
   receivers spread the transmission of direct time synchronization
   requests over the time (Section 2.3.1).

5.2.4.  EXT_AUTH Header Extension of Type Direct Time Synchronization
        Response

   With NORM, the "direct time synchronization response" TESLA EXT_AUTH
   (Type==8) MUST be sent by the sender in a NORM_CMD(APPLICATION)
   message.

Roca, et al.             Expires March 20, 2010                [Page 51]

Internet-Draft            TESLA in ALC and NORM           September 2009

   With ALC, the "direct time synchronization response" TESLA EXT_AUTH
   can be sent in an ALC control packet (i.e., containing no encoding
   symbol) or through the external mechanism use to carry the direct
   time synchronization request.

Roca, et al.             Expires March 20, 2010                [Page 52]

Internet-Draft            TESLA in ALC and NORM           September 2009

6.  Security Considerations

   [RFC4082] discusses the security of TESLA in general.  These
   considerations apply to the present specification, namely:

   o  great care must be taken to the timing aspects.  In particular the
      D_t parameter is critical and must be correctly initialized;

   o  if the sender realizes that the key disclosure schedule is not
      appropriate, then the current session MUST be closed and a new one
      created.  Indeed Section 3.1.3 requires that these parameters be
      fixed during the whole session.

   o  when the verifier that authenticates the incoming packets and the
      application that uses the data are two different components, there
      is a risk that an attacker located between these components inject
      faked data.  Similarly, when the verifier and the secure timing
      system are two different components, there is a risk that an
      attacker located between these components inject faked timing
      information.  For instance, when the verifier reads the local time
      by means of a dedicated system call (e.g., gettimeofday()), if an
      attacker controls the host, he may catch the system call and
      return a faked time information.

   The current specification discusses additional aspects with more
   details.

6.1.  Dealing With DoS Attacks

   TESLA introduces new opportunities for an attacker to mount DoS
   attacks.  For instance an attacker can try to saturate the processing
   capabilities of the receiver (faked packets are easy to create but
   checking them requires to compute a MAC over the packet or sometimes
   check a digital signature as with the bootstrap and direct time
   synchronization response messages).  An attacker can also try to
   saturate the receiver's memory (since authentication is delayed and
   non-authenticated packets will accumulate), or to make the receiver
   believe that a congestion has happened (since congestion control MUST
   be performed before authenticating incoming packets, Section 4.3).

   In order to mitigate these attacks, it is RECOMMENDED to use the
   Group MAC scheme (Section 3.3.3).  No mitigation is possible if a
   group member acts as an attacker with Group MAC.

   Generally, it is RECOMMENDED that the amount of memory used to store
   incoming packets waiting to be authenticated be limited to a
   reasonable value.

Roca, et al.             Expires March 20, 2010                [Page 53]

Internet-Draft            TESLA in ALC and NORM           September 2009

6.2.  Dealing With Replay Attacks

   Replay attacks, whereby an attacker stores a valid message and
   replays it later on, can have significant impacts, depending on the
   message type.  Two levels of impacts must be distinguished:

   o  within the TESLA protocol, and

   o  within the ALC or NORM protocol.

6.2.1.  Impacts of Replay Attacks on TESLA

   Replay attacks can impact the TESLA component itself.  We review here
   the potential impacts of such an attack depending on the TESLA
   message type:

   o  bootstrap information: since most parameters contained in a
      bootstrap information message are static, replay attacks have no
      consequences.  The fact that the "i" and "K_i" fields can be
      updated in subsequent bootstrap information messages does not
      create a problem either, since all "i" and "K_i" fields sent
      remain valid.  Finally, a receiver that successfully initialized
      its TESLA component MUST ignore the following messages (see
      Section 4.2.1 for an exception to this rule), which voids replay
      attacks, unless he missed all the commitments to a new key chain
      (e.g., after a long disconnection) (Section 3.2.1).

   o  direct time synchronization request: If the Group MAC scheme is
      used, an attacker that is not a member of the group can replay a
      packet and oblige the sender to respond, which requires to
      digitally sign the response, a time-consuming process.  If the
      Group MAC scheme is not used, an attacker can anyway easily forge
      a request.  In both cases, the attack will not compromise the
      TESLA component, but might create a DoS.  If this is a concern, it
      is RECOMMENDED, when the Group MAC scheme is used, that the sender
      verify the "t_r" NTP timestamp contained in the request and
      respond only if this value is strictly larger than the previous
      one received from this receiver.  When the Group MAC scheme is not
      used, this attack can be mitigated by limiting the number of
      requests per second that will be processed.

   o  direct time synchronization response: Upon receiving a response, a
      receiver who has no pending request MUST immediately drop the
      packet.  If this receiver has previously issued a request, he
      first checks the Group MAC (if applicable), then the "t_r" field,
      to be sure it is a response to his request, and finally the
      digital signature.  A replayed packet will be dropped during these
      verifications, without compromising the TESLA component.

Roca, et al.             Expires March 20, 2010                [Page 54]

Internet-Draft            TESLA in ALC and NORM           September 2009

   o  other messages, containing an authentication tag: Replaying a
      packet containing a TESLA authentication tag will never compromise
      the TESLA component itself (but perhaps the underlying ALC or NORM
      component, see below).

   To conclude, TESLA itself is robust in front of replay attacks.

6.2.2.  Impacts of Replay Attacks on NORM

   We review here the potential impacts of a replay attack on the NORM
   component.  Note that we do not consider here the protocols that
   could be used along with NORM, for instance the congestion control
   protocols.

   First, let us consider replay attacks within a given NORM session.
   NORM defines a "sequence" field that can be used to protect against
   replay attacks [RMT-PI-NORM] within a given NORM session.  This
   "sequence" field is a 16-bit value that is set by the message
   originator (sender or receiver) as a monotonically increasing number
   incremented with each NORM message transmitted.  It is RECOMMENDED
   that a receiver check this sequence field and drop messages
   considered as replayed.  Similarly, it is RECOMMENDED that a sender
   check this sequence, for each known receiver, and drop messages
   considered as replayed.  In both cases, checking this sequence field
   SHOULD be done before TESLA processing of the packet: if the sequence
   field has not been corrupted, the replay attack will immediately be
   identified, and otherwise the packet will fail the TESLA
   authentication test.  This analysis shows that NORM itself is robust
   in front of replay attacks within the same session.

   Now let us consider replay attacks across several NORM sessions.
   Since the key chain used in each session MUST differ, a packet
   replayed in a subsequent session will be identified as unauthentic.
   Therefore NORM is robust in front of replay attacks across different
   sessions.

6.2.3.  Impacts of Replay Attacks on ALC

   We review here the potential impacts of a replay attack on the ALC
   component.  Note that we do not consider here the protocols that
   could be used along with ALC, for instance the layered or wave based
   congestion control protocols.

   First, let us consider replay attacks within a given ALC session:

   o  Regular packets containing an authentication tag: a replayed
      message containing an encoding symbol will be detected once
      authenticated, thanks to the object/block/symbol identifiers, and

Roca, et al.             Expires March 20, 2010                [Page 55]

Internet-Draft            TESLA in ALC and NORM           September 2009

      will be silently discarded.  This kind of replay attack is only
      penalizing in terms of memory and processing load, but does not
      compromise the ALC behavior.

   o  Control packets containing an authentication tag: ALC control
      packets, by definition, do not include any encoding symbol and
      therefore do not include any object/block/symbol identifier that
      would enable a receiver to identify duplicates.  However, a sender
      has a very limited number of reasons to send control packets.
      More precisely:

      *  At the end of the session, a "close session" (A flag) packet is
         sent.  Replaying this packet has no impact since the receivers
         already left.

      *  Similarly, replaying a packet containing a "close object" (B
         flag) has no impact since this object is probably already
         marked as closed by the receiver.

   This analysis shows that ALC itself is robust in front of replay
   attacks within the same session.

   Now let us consider replay attacks across several ALC sessions.
   Since the key chain used in each session MUST differ, a packet
   replayed in a subsequent session will be identified as unauthentic.
   Therefore ALC is robust in front of replay attacks across different
   sessions.

6.3.  Security of the Back Channel

   As specified in Section 1.1, this specification does not consider the
   packets that may be sent by receivers, for instance NORM's feedback
   packets.  When a back channel is used, its security is critical to
   the global security, and an appropriate security mechanism MUST be
   used.  [RMT-SIMPLE-AUTH] describes several techniques that can be
   used to that purpose.  However, the authentication and integrity
   verification of the packets sent by receivers on the back channel, if
   any, is out of the scope of this document.

Roca, et al.             Expires March 20, 2010                [Page 56]

Internet-Draft            TESLA in ALC and NORM           September 2009

7.  IANA Considerations

   This document requires a IANA registration for the following
   attributes.  The registries are provided by [RFC4442] under the
   "Timed Efficient Stream Loss-tolerant Authentication (TESLA)
   Parameters" registry [TESLA-REG].  Following the policies outlined in
   [RFC4442], the values in the range up to 240 (including 240) for the
   following attributes are assigned after expert review by the MSEC
   working group or its designated successor.  The values in the range
   from 241 to 255 are reserved for private use.

   Cryptographic Pseudo-Random Function, TESLA-PRF: All implementations
   MUST support HMAC-SHA-256 (default).

                    +------------------------+-------+
                    |        PRF name        | Value |
                    +------------------------+-------+
                    |       HMAC-SHA-1       |   0   |
                    |                        |       |
                    |      HMAC-SHA-224      |   1   |
                    |                        |       |
                    | HMAC-SHA-256 (default) |   2   |
                    |                        |       |
                    |      HMAC-SHA-384      |   3   |
                    |                        |       |
                    |      HMAC-SHA-512      |   4   |
                    +------------------------+-------+

   Cryptographic Message Authentication Code (MAC) Function, TESLA-MAC:
   All implementations MUST support HMAC-SHA-256 (default).  These MAC
   schemes are used both for the computing of regular MAC and the Group
   MAC (if applicable).

                    +------------------------+-------+
                    |        MAC name        | Value |
                    +------------------------+-------+
                    |       HMAC-SHA-1       |   0   |
                    |                        |       |
                    |      HMAC-SHA-224      |   1   |
                    |                        |       |
                    | HMAC-SHA-256 (default) |   2   |
                    |                        |       |
                    |      HMAC-SHA-384      |   3   |
                    |                        |       |
                    |      HMAC-SHA-512      |   4   |
                    +------------------------+-------+

   Furthermore, this document requires IANA to create two new

Roca, et al.             Expires March 20, 2010                [Page 57]

Internet-Draft            TESLA in ALC and NORM           September 2009

   registries.  Here also, the values in the range up to 240 (including
   240) for the following attributes are assigned after expert review by
   the MSEC working group or its designated successor.  The values in
   the range from 241 to 255 are reserved for private use.

   Signature Encoding Algorithm, TESLA-SIG-ALGO: All implementations
   MUST support RSASSA-PKCS1-v1_5 (default).

                  +-----------------------------+-------+
                  |   Signature Algorithm Name  | Value |
                  +-----------------------------+-------+
                  |           INVALID           |   0   |
                  |                             |       |
                  | RSASSA-PKCS1-v1_5 (default) |   1   |
                  |                             |       |
                  |          RSASSA-PSS         |   2   |
                  +-----------------------------+-------+

   Signature Cryptographic Function, TESLA-SIG-CRYPTO-FUNC: All
   implementations MUST support SHA-256 (default).

                  +-----------------------------+-------+
                  | Cryptographic Function Name | Value |
                  +-----------------------------+-------+
                  |           INVALID           |   0   |
                  |                             |       |
                  |            SHA-1            |   1   |
                  |                             |       |
                  |           SHA-224           |   2   |
                  |                             |       |
                  |      SHA-256 (default)      |   3   |
                  |                             |       |
                  |           SHA-384           |   4   |
                  |                             |       |
                  |           SHA-512           |   5   |
                  +-----------------------------+-------+

Roca, et al.             Expires March 20, 2010                [Page 58]

Internet-Draft            TESLA in ALC and NORM           September 2009

8.  Acknowledgments

   The authors are grateful to Yaron Sheffer, Brian Weis, Ramu
   Panayappan, Ran Canetti, David L. Mills, Brian Adamson and Lionel
   Giraud for their valuable comments while preparing this document.
   The authors are also grateful to Brian Weis for the digital signature
   details.

Roca, et al.             Expires March 20, 2010                [Page 59]

Internet-Draft            TESLA in ALC and NORM           September 2009

9.  References

9.1.  Normative References

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

   [RFC4082]  Perrig, A., Song, D., Canetti, R., Tygar, J., and B.
              Briscoe, "Timed Efficient Stream Loss-Tolerant
              Authentication (TESLA): Multicast Source Authentication
              Transform Introduction", RFC 4082, June 2005.

   [RMT-BB-LCT]
              Luby, M., Watson, M., and L. Vicisano, "Layered Coding
              Transport (LCT) Building Block",
               draft-ietf-rmt-bb-lct-revised-11.txt (work in progress),
              August 2009.

   [RMT-PI-ALC]
              Luby, M., Watson, M., and L. Vicisano, "Asynchronous
              Layered Coding (ALC) Protocol Instantiation",
               draft-ietf-rmt-pi-alc-revised-08.txt (work in progress),
              September 2009.

   [RMT-PI-NORM]
              Adamson, B., Bormann, C., Handley, M., and J. Macker,
              "Negative-acknowledgment (NACK)-Oriented Reliable
              Multicast (NORM) Protocol",
               draft-ietf-rmt-pi-norm-revised-13.txt (work in progress),
              June 2009.

   [TESLA-REG]
              "TESLA Parameters IANA Registry",
               http://www.iana.org/assignments/tesla-parameters/.

9.2.  Informative References

   [NTP-NTPv4]
              Burbank, J., Kasch, W., Martin, J., and D. Mills, "The
              Network Time Protocol Version 4 Protocol Specification",
               draft-ietf-ntp-ntpv4-proto-11.txt (work in progress),
              September 2008.

   [Perrig04]
              Perrig, A. and J. Tygar, "Secure Broadcast Communication
              in Wired and Wireless Networks", Kluwer Academic
              Publishers ISBN 0-7923-7650-1, 2004.

Roca, et al.             Expires March 20, 2010                [Page 60]

Internet-Draft            TESLA in ALC and NORM           September 2009

   [RFC1305]  Mills, D., "Network Time Protocol (Version 3)
              Specification, Implementation", RFC 1305, March 1992.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              February 1997.

   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
              Standards (PKCS) #1: RSA Cryptography Specifications
              Version 2.1", RFC 3447, February 2003.

   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, March 2004.

   [RFC4330]  Mills, D., "Simple Network Time Protocol (SNTP) Version 4
              for IPv4, IPv6 and OSI", RFC 4330, January 2006.

   [RFC4359]  Weis, B., "The Use of RSA/SHA-1 Signatures within
              Encapsulating Security Payload (ESP) and Authentication
              Header (AH)", RFC 4359, January 2006.

   [RFC4383]  Baugher, M. and E. Carrara, "The Use of Timed Efficient
              Stream Loss-Tolerant Authentication (TESLA) in the Secure
              Real-time Transport Protocol (SRTP)", RFC 4383,
              February 2006.

   [RFC4442]  Fries, S. and H. Tschofenig, "Bootstrapping Timed
              Efficient Stream Loss-Tolerant Authentication (TESLA)",
              RFC 4442, March 2006.

   [RMT-FLUTE]
              Paila, T., Walsh, R., Luby, M., Lehtonen, R., and V. Roca,
              "FLUTE - File Delivery over Unidirectional Transport",
               draft-ietf-rmt-flute-revised-07.txt (work in progress),
              August 2009.

   [RMT-SIMPLE-AUTH]
              Roca, V., "Simple Authentication Schemes for the ALC and
              NORM Protocols",
               draft-ietf-rmt-simple-auth-for-alc-norm-01.txt (work in
              progress), March 2009.

Roca, et al.             Expires March 20, 2010                [Page 61]

Internet-Draft            TESLA in ALC and NORM           September 2009

Authors' Addresses

   Vincent Roca
   INRIA
   655, av. de l'Europe
   Inovallee; Montbonnot
   ST ISMIER cedex  38334
   France

   Email: [email-masked]
   URI:   http://planete.inrialpes.fr/~roca/

   Aurelien Francillon
   INRIA
   655, av. de l'Europe
   Inovallee; Montbonnot
   ST ISMIER cedex  38334
   France

   Email: [email-masked]
   URI:   http://planete.inrialpes.fr/~francill/

   Sebastien Faurite
   INRIA
   655, av. de l'Europe
   Inovallee; Montbonnot
   ST ISMIER cedex  38334
   France

   Email: [email-masked]

Roca, et al.             Expires March 20, 2010                [Page 62]

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc2119 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>

<!--<rfc category="exp" ipr="full3978" docName="draft-ietf-msec-tesla-for-alc-norm-07.txt">-->
<!--<rfc category="exp" ipr="trust200811" docName="draft-ietf-msec-tesla-for-alc-norm-08.txt">-->
<rfc category="exp" ipr="pre5378Trust200902">

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>

    <front>
        <title abbrev='TESLA in ALC and NORM'>
            Use of TESLA in the ALC and NORM Protocols
        </title>
        <author initials='V.R.' surname="Roca" fullname='Vincent Roca'>
            <organization>INRIA</organization>
            <address>
                <postal>
                    <street>655, av. de l'Europe</street>
                    <street>Inovallee; Montbonnot</street>
                    <city>ST ISMIER cedex</city>
                    <code>38334</code>
                    <country>France</country>
                </postal>
		<!--
                <phone></phone>
		-->
                <email>[email-masked]</email>
                <uri>http://planete.inrialpes.fr/~roca/</uri>
            </address>
        </author>
        <author initials='A.F.' surname="Francillon" fullname='Aurelien Francillon'>
            <organization>INRIA</organization>
            <address>
                <postal>
                    <street>655, av. de l'Europe</street>
                    <street>Inovallee; Montbonnot</street>
                    <city>ST ISMIER cedex</city>
                    <code>38334</code>
                    <country>France</country>
                </postal>
		<!--
                <phone></phone>
		-->
                <email>[email-masked]</email>
                <uri>http://planete.inrialpes.fr/~francill/</uri>
            </address>
        </author>
        <author initials='S.F.' surname="Faurite" fullname='Sebastien Faurite'>
            <organization>INRIA</organization>
            <address>
                <postal>
                    <street>655, av. de l'Europe</street>
                    <street>Inovallee; Montbonnot</street>
                    <city>ST ISMIER cedex</city>
                    <code>38334</code>
                    <country>France</country>
                </postal>
                <email>[email-masked]</email>
		<!--
                <phone></phone>
                <uri></uri>
		-->
            </address>
        </author>
        <date day="16" month="September" year="2009"/>
        <area>Transport</area>
        <workgroup>MSEC</workgroup>
        <keyword>TESLA</keyword>
        <keyword>FLUTE</keyword>
        <keyword>ALC</keyword>
        <keyword>NORM</keyword>
        <abstract>
                <t>
		This document details the TESLA packet source authentication and packet integrity
		verification protocol and its integration within the ALC and NORM content delivery
		protocols.
		This document only considers the authentication/integrity verification of the packets
		generated by the session's sender. The authentication and integrity verification of
		the packets sent by receivers, if any, is out of the scope of this document.
                </t>
        </abstract>
    </front>

    <middle>

<section anchor="intro" title="Introduction">
<!-- ==================================== -->

<t>
Many applications using multicast and broadcast communications
require that each receiver be able to authenticate the source of any
packet it receives as well as the integrity of these packets.
This is the case with ALC <xref target="RMT-PI-ALC"/> and
NORM <xref target="RMT-PI-NORM"/>,
two Content Delivery Protocols (CDP) designed to transfer reliably
objects (e.g., files) between a session's sender and several receivers.
The NORM protocol is based on bidirectional transmissions.
Each receiver acknowledges data received or, in case of packet erasures,
asks for retransmissions.
On the opposite, the ALC protocol is based on purely unidirectional transmissions.
Reliability is achieved by means of the cyclic transmission of the content
within a carousel and/or by the use of proactive Forward Error Correction
codes (FEC).
<!--
Being purely unidirectional, ALC is massively scalable, while NORM is
intrinsically limited in terms of the number of receivers that can
be handled in a session.
-->
Both protocols have in common the fact that they operate at application
level, on top of an erasure channel (e.g., the Internet) where packets
can be lost (erased) during the transmission.
</t>

<t>
The goal of this document is to counter attacks where 
an attacker impersonates the ALC or NORM session's sender and injects
forged packets to the receivers, thereby corrupting the objects reconstructed
by the receivers.
</t>

<t>
Preventing this attack is much more complex in case of group communications
than it is with unicast communications.
Indeed, with unicast communications a simple solution exists: the sender
and the receiver share a secret key to compute a Message Authentication
Code (MAC) of all messages exchanged.
This is no longer feasible in case of multicast and broadcast
communications since sharing a group key between the sender and all
receivers implies that any group member can impersonate the sender and send
forged messages to other receivers.
</t>

<t>
The usual solution to provide the source authentication and message
integrity services in case of multicast and broadcast communications
consists in relying on asymmetric cryptography and using digital signatures.
Yet this solution is limited by high computational costs and high
transmission overheads.
The Timed Efficient Stream Loss-tolerant Authentication protocol (TESLA)
is an alternative solution that provides the two required services,
while being compatible with high rate transmissions over lossy channels.
</t>

<t>
This document explains how to integrate the TESLA source authentication and
packet integrity protocol to the ALC and NORM CDP.
Any application built on top of ALC and NORM will directly benefit from the
services offered by TESLA at the transport layer.
In particular, this is the case of FLUTE.
</t>

<t>
For more information on the TESLA protocol and its principles, please refer to
<xref target="RFC4082"/><xref target="Perrig04"/>.
For more information on ALC and NORM, please refer to
<xref target="RMT-PI-ALC"/>, <xref target="RMT-BB-LCT"/>
and <xref target="RMT-PI-NORM"/> respectively.
For more information on FLUTE, please refer to <xref target="RMT-FLUTE"/>.
</t>

<section title="Scope of this Document" anchor="scope">
<!-- =================================== -->

<t>
This specification only considers the authentication and integrity verification
of the packets generated by the session's sender.
This specification does not consider the packets that may be sent by receivers,
for instance NORM's feedback packets.
<xref target="RMT-SIMPLE-AUTH"/> describes several techniques that can be used 
to that purpose.
Since this is usually a low-rate flow (unlike the downstream flow),
using computing intensive techniques like digital signatures, possibly combined
with a Group MAC scheme, is often acceptable.
Finally, the <xref target="sec:alc_norm_integration"/> explains how to use several
authentication schemes in a given session thanks to the ASID (Authentication
Scheme IDentifier) field.
</t>

<t>
This specification relies on several external mechanisms, for instance:
<list style='symbols'> 
	<t>to communicate securely the public key or a certificate for the session's sender
		(<xref target="sec:intro_to_inband_boostrap"/>);</t>
	<t>to communicate securely and confidentially the group key, K_g, used
		by the Group MAC feature, when applicable
		(<xref target="sec:group_auth_tag"/>). In some situations, this
		group key will have to be periodically refreshed;</t>
	<t>to perform secure time synchronization in indirect mode
		(<xref target="sec:intro_to_indirect_time_sync"/>)
		or in direct mode (<xref target="sec:intro_to_direct_time_sync"/>)
		to carry the request/response messages with ALC which is purely
		unidirectional;</t>
</list> 
These mechanisms are required in order to bootstrap TESLA at a sender and
at a receiver and must be deployed in parallel to TESLA.
Besides, the randomness of the Primary Key of the key chain
(<xref target="sec:key_chains"/>) is vital to the security of TESLA.
Therefore the sender needs an appropriate mechanism to generate this random key.
</t>

<t>
<!-- Aurelien: faire une liste avec bullets -->
Several technical details of TESLA, like the most appropriate way to alternate
between the transmission of a key disclosure and a commitment to a new key chain,
or the transmission of a key disclosure and the last key of the previous key chain,
or the disclosure of a key and the compact flavor that does not disclose any key,
are specific to the target use-case (<xref target="sec:key_chains"/>).
For instance, it depends on the number of packets sent per time interval, on
the desired robustness and the acceptable transmission overhead, which can only
be optimized after taking into account the use-case specificities.
</t>

</section>

<section title="Conventions Used in this Document">
<!-- =================================== -->

<t>
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 <xref target="RFC2119"/>.</t>
</section>

<section title="Terminology and Notations">
<!-- =================================== -->

<t>
The following notations and definitions are used throughout this document.
</t>

<section title="Notations and Definitions Related to Cryptographic Functions">
<!-- =================================== -->

<t>
Notations and definitions related to cryptographic functions
<xref target="RFC4082"/><xref target="RFC4383"/>:
<list style='symbols'> 
	<t>PRF is the Pseudo Random Function;</t>
	<t>MAC is the Message Authentication Code;</t>
	<t>HMAC is the keyed-Hash Message Authentication Code;</t>
	<t>F is the one-way function used to create the key chain
		(<xref target="sec:key_chains_principles"/>);</t>
	<t>F' is the one-way function used to derive the HMAC keys
		(<xref target="sec:key_chains_principles"/>);</t>
	<t>n_p is the length, in bits, of the F function's output.
		This is therefore the length of the keys in the key chain;</t>
	<t>n_f is the length, in bits, of the F' function's output.
		This is therefore the length of the HMAC keys;</t>
	<t>n_m is the length, in bits, of the truncated output of the MAC <xref target="RFC2104"/>.
		Only the n_m most significant bits of the MAC output are kept;</t>
	<t>N is the length of a key chain.
		There are N+1 keys in a key chain: K_0, K_1, .. K_N.
		When several chains are used, all the chains MUST have the same length
		and keys are numbered consecutively, following the time interval numbering;</t>
	<t>n_c is the number of keys in a key chain. Therefore: n_c = N+1;</t>
	<t>n_tx_lastkey is the number of additional intervals during which the last key of
		the old key chain SHOULD be sent, after switching to a new key
		chain and after waiting for the disclosure delay d. These extra transmissions
		take place after the interval during which the last key is normally
		disclosed. The n_tx_lastkey value is either 0 (no extra disclosure) or larger.
		This parameter is sender specific and is not communicated to the receiver;</t>
	<t>n_tx_newkcc is the number of intervals during which the commitment to
		a new key chain SHOULD be sent, before switching to the new key chain.
		The n_tx_newkcc value is either 0 (no commitment sent within authentication tags)
		or larger.
		This parameter is sender specific and is not communicated to the receiver;</t>
	<t>K_g is a shared group key, communicated to all group members, confidentially,
		during the TESLA bootstrapping (<xref target="sec:intro_to_bootstrap"/>);</t>
	<t>n_w is the length, in bits, of the truncated output of the MAC of the optional
		group authentication scheme:
		only the n_w most significant bits of the MAC output are kept.
		n_w is typically small, multiple of 32 bits (e.g., 32 bits);</t>
</list></t>
</section>

<section title="Notations and Definitions Related to Time">
<!-- =================================== -->

<t>
Notations and definitions related to time:
<list style='symbols'> 
	<t>i is the time interval index. Interval numbering starts at 0 and
		increases consecutively. Since the interval index is stored as a 32 bit
		unsigned integer, wrapping to 0 might take place in long sessions.</t>
	<t>t_s is the sender local time value at some absolute time (in NTP timestamp format);</t>
	<t>t_r is the receiver local time value at the same absolute time (in NTP timestamp format);</t>
	<t>T_0 is the start time corresponding to the beginning of the session, i.e., the
		beginning of time interval 0 (in NTP timestamp format);</t>
	<t>T_int is the interval duration (in milliseconds);</t>
	<t>d is the key disclosure delay (in number of intervals);</t>
	<t>D_t is the upper bound of the lag of the receiver's clock with respect to
		the clock of the sender;</t>
	<t>S_sr is an estimated bound of the clock drift between the sender and a receiver
		throughout the duration of the session;</t>
	<t>D^O_t is the upper bound of the lag of the sender's clock with respect to
		the time reference in indirect time synchronization mode;</t>
	<t>D^R_t is the upper bound of the lag of the receiver's clock with respect to
		the time reference in indirect time synchronization mode;</t>
	<t>D_err is an upper bound of the time error between all the time references,
		in indirect time synchronization mode;</t>
	<t>NTP timestamp format consists in a 64-bit unsigned fixed-point number,
		in seconds relative to 0h on 1 January 1900. The integer part is in
		the first 32 bits and the fraction part in the last 32 bits
		<xref target="RFC1305"/>;</t>
</list></t>
</section>

</section>

</section><!-- =Introduction= -->

<!-- ======================================================================= -->

<section title="Using TESLA with ALC and NORM: General Operations" anchor="using_tesla_with_cdp"> 
<!-- =================================== -->

<section title="ALC and NORM Specificities that Impact TESLA"
	 anchor="alc_norm_specificities"> 
<!-- =================================== -->

<t>The ALC and NORM protocols have features and requirements that largely impact
the way TESLA can be used.</t>

<t>In case of ALC:
<list style='symbols'> 
	<t>ALC is massively scalable:
	nothing in the protocol specification limits the number of receivers
	that join a session.
	Therefore an ALC session potentially includes a huge number (e.g., millions
	or more) of receivers;
	</t>
	<t>ALC can work on top of purely unidirectional transport channels:
	this is one of the assets of ALC, and examples of unidirectional channels
	include satellite (even if a back channel might exist in some use cases)
	and broadcasting networks like DVB-H/SH;
	</t>
	<t>ALC defines an on-demand content delivery model <xref target="RMT-PI-ALC"/>
	where receivers can arrive at any time, at their own discretion,
	download the content and leave the session.
	Other models (e.g., push or streaming) are also defined;
	</t>
	<t>ALC sessions are potentially very long:
	a session can last several days or months during which the
	content is continuously transmitted within a carousel.
	The content can be either static (e.g., a software update) or
	dynamic (e.g., a web site).</t>
</list>
Depending on the use case, some of the above features may not apply.
For instance ALC can also be used over a bidirectional channel or
with a limited number of receivers.
</t>

<t>In case of NORM:
<list style='symbols'>
	<t>NORM has been designed for medium size sessions:
	indeed, NORM relies on feedback messages and the sender
	may collapse if the feedback message rate is too high;
	</t>
	<t>NORM requires a bidirectional transport channel:
	the back channel is not necessarily a high data rate channel since
	the control traffic sent over it by a single receiver is an order
	of magnitude lower than the downstream traffic.
	Networks with an asymmetric connectivity (e.g., a high rate satellite
	downlink and a low-rate RTC based return channel) are appropriate;
	</t>
</list>
</t>

</section>

<section title="Bootstrapping TESLA" anchor="sec:intro_to_bootstrap">
<!-- =================================== -->

<t>
In order to initialize the TESLA component at a receiver, the sender MUST
communicate some key information in a secure way, so that the receiver can check
the source of the information and its integrity.
Two general methods are possible:
<list style='symbols'>
<t>	by using an out-of-band mechanism, or
	</t>
<t>	by using an in-band mechanism.
	</t>
</list>
The current specification does not recommend any mechanism to bootstrap
TESLA. Choosing between an in-band and out-of-band scheme is left to
the implementer, depending on the target use-case.
However, it is RECOMMENDED that TESLA implementations support the use of
the in-band mechanism for interoperability purposes.</t>

<section title="Bootstrapping TESLA with an Out-Of-Band Mechanism">
<!-- =================================== -->

<t>
For instance <xref target="RFC4442"/> describes the use of the MIKEY 
(Multimedia Internet Keying) protocol to bootstrap TESLA.
As a side effect, MIKEY also provides a loose time synchronization
feature, that TESLA can benefit.
Other solutions, for instance based on an extended session description,
are possible, on condition these solutions provide the required security
level.
</t>
</section>

<section title="Bootstrapping TESLA with an In-Band Mechanism" anchor="sec:intro_to_inband_boostrap">
<!-- =================================== -->

<t>
This specification describes an in-band mechanism.
In some use-cases, it might be desired that bootstrap take place
without requiring the use of an additional external mechanism.
For instance each device may feature a clock with a known time-drift
that is negligible in front of the time accuracy required by TESLA,
and each device may embed the public key of the sender.
It is also possible that the use-case does not feature a bidirectional
channel which prevents the use of out-of-band protocols like MIKEY.
For these two examples, the exchange of a bootstrap information message
(described in <xref target="sec:bootstrap_info_format"/>) and the knowledge
of a few additional parameters (listed below) are sufficient to bootstrap
TESLA at a receiver.
</t>

<t>
Some parameters cannot be communicated in-band.
In particular:
<list style='symbols'>
<t>	the sender or group controller MUST either communicate the public key of the sender or a certificate
	(which also means that a PKI has been setup) to all receivers, so that
	each receiver be able to verify the signature of the bootstrap message and direct time
	synchronization response messages (when applicable).
<!--
	As a side effect, the receivers also know the key length
	and the signature length, the two parameters being equal.
-->
	</t>
<t>	when time synchronization is performed with NTP/SNTP,
	the sender or group controller MUST communicate the list of valid
	NTP/SNTP servers to all the session members (sender included), so that
	they all be able to synchronize themselves on
	the same NTP/SNTP servers.</t>
<t>	when the Group MAC feature is used,
	the sender or group controller MUST communicate the K_g group key to
	all the session members (sender included).
	This group key may be periodically refreshed.</t>
</list>
The way these parameters are communicated is out of the scope of this document.
</t>
</section>

</section>

<section title="Setting Up a Secure Time Synchronization"
	anchor="sec:need_for_time_sync">
<!-- =================================== -->

<t>
The security offered by TESLA heavily relies on time.
Therefore the session's sender and each receiver need to be time synchronized
in a secure way.
To that purpose, two general methods exist:
<list style='symbols'> 
	<t>direct time synchronization, and</t>
	<t>indirect time synchronization.</t>
</list>
It is also possible that a given session include receivers that use the direct
time synchronization mode while others use the indirect time synchronization mode.
</t>

<section title="Direct Time Synchronization" anchor="sec:intro_to_direct_time_sync">
<!-- =================================== -->

<t>
When direct time synchronization is used, each receiver asks the sender for
a time synchronization. To that purpose, a receiver sends a "Direct Time Synchronization
Request" (<xref target="sec:direct_synch_request_format" />).
The sender then directly answers to each request with a "Direct Time Synchronization
Response" (<xref target="sec:direct_synch_response_format" />), signing this reply.
Upon receiving this response, a receiver first verifies the signature, and then calculates
an upper bound of the lag of his clock with respect to the clock of the sender, D_t.
The details on how to calculate D_t are given in <xref target="sec:delay_bound_calc_direct_sync"/>.
</t>

<t>
This synchronization method is both simple and secure.
Yet there are two potential issues:
<list style='symbols'>
	<t>a bidirectional channel must exist between the sender and each receiver, and</t>
	<t>the sender may collapse if the incoming request rate is too high.</t>
</list>
</t>
<t>
Relying on direct time synchronization is not expected to be an issue with NORM since
(1) bidirectional communications already take place, and (2) NORM scalability is anyway limited.
Yet it can be required that a mechanism, that is out of the scope of this document, be used
to spread the transmission of "Direct time synchronization request" messages over the
time if there is a risk that the sender may collapse.
</t>

<t>
But direct time synchronization is potentially incompatible with ALC since (1) there
might not be a back channel and (2) there are potentially
a huge number of receivers and therefore a risk that the sender collapses.
</t>
</section>

<section title="Indirect Time Synchronization"
	anchor="sec:intro_to_indirect_time_sync">
<!-- =================================== -->

<t>
When indirect time synchronization is used, the sender and each receiver must
synchronize securely via an external time reference.
Several possibilities exist:
<list style='symbols'> 
	<t>sender and receivers can synchronize through a NTPv3
	(Network Time Protocol version 3) <xref target="RFC1305"/>
	hierarchy of servers.
	The authentication mechanism of NTPv3 MUST be used in order
	to authenticate each NTP message individually. It prevents
	for instance an attacker to impersonate a NTP server;</t>
	<t>they can synchronize through a NTPv4
	(Network Time Protocol version 4) <xref target="NTP-NTPv4"/>
	hierarchy of servers.
	The Autokey security protocol of NTPv4 MUST be used in order
	to authenticate each NTP message individually;</t>
	<t>they can synchronize through a SNTPv4
	(Simple Network Time Protocol version 4) <xref target="RFC4330"/>
	hierarchy of servers.
	The authentication features of SNTPv4 must then be used.
	Note that TESLA only needs a loose (but secure) time
	synchronization, which is in line with the time synchronization
	service offered by SNTP;</t>
	<t>they can synchronize through a GPS or Galileo (or similar) device
	that also provides a high precision time reference.
	Spoofing attacks on the GPS system have recently been reported.
	Depending on the use case, the security achieved will be or not
	acceptable;</t>
	<t>they can synchronize thanks to a dedicated hardware,
	embedded on each sender and receiver, that provides a clock
	with a time-drift that is negligible in front of the TESLA time
	accuracy requirements. This feature enables a device to synchronize
	its embedded clock with the official time reference from time to
	time (in an extreme case once, at manufacturing time),
	and then to remain autonomous for a duration that depends on the
	known maximum clock drift.</t>
</list>
A bidirectional channel is required by the NTP/SNTP schemes.
On the opposite, with the GPS/Galileo and high precision clock schemes,
no such assumption is made.
In situations where ALC is used on purely unidirectional transport
channels (<xref target="alc_norm_specificities"/>), using the NTP/SNTP
schemes is not possible.
Another aspect is the scalability requirement of ALC, and to a lesser
extent of NORM. 
>From this point of view, the above mechanisms usually do not raise any
problem, unlike the direct time synchronization schemes.
Therefore, using indirect time synchronization can be a good choice.
It should be noted that the NTP/SNTP schemes assume that each client trusts
the sender and accepts to align its NTP/SNTP configuration to that of the
sender. If this assumption does not hold, the sender SHOULD offer an
alternative solution.
</t>

<t>
The details on how to calculate an upper bound of the lag of a receiver's
clock with respect to the clock of the sender, D_t, are given in
<xref target="sec:delay_bound_calc_indirect_sync"/>.
</t>

<!--
<t>
In any case, this document does not explain in details how to achieve
time synchronization, whether it follows a direct or indirect scheme.
The document only provides general guidelines.
The details are outside the scope of this document.
</t>
-->
</section>

</section><!-- -The Need for Secure Time Synchronization- -->

<section title="Determining the Delay Bounds" anchor="delay_bound"> 
<!-- =================================== -->

<t>
Let us assume that a secure time synchronization has been set up.
This section explains how to define the various timing parameters that
are used during the authentication of received packets.
</t>

<section title="Delay Bound Calculation in Direct Time Synchronization Mode"
	anchor="sec:delay_bound_calc_direct_sync">
<!-- =================================== -->

<t>
In direct time synchronization mode, synchronization between a receiver and the
sender follows the following protocol <xref target="RFC4082"/>:
<list style='symbols'>
	<t> The receiver sends a "Direct Time Synchronization Request" message to the sender,
	that includes t_r, the receiver local time at the moment of sending
	(<xref target="sec:direct_synch_request_format" />).</t>

	<t> Upon receipt of this message, the sender records its local time, t_s,
	and sends to the receiver a "Direct Time Synchronization Response" that includes
	t_r (taken from the request) and t_s (<xref target="sec:direct_synch_response_format" />),
	signing this reply.</t>

	<t> Upon receiving this response, the receiver first verifies that he actually
	sent a request with t_r and then checks the signature.
	Then he calculates D_t = t_s - t_r + S_sr, where S_sr is an estimated bound of the
	clock drift between the sender and the receiver throughout the duration of the
	session.
	This document does not specify how S_sr is estimated.
	</t>
</list>
After this initial synchronization, at any point throughout the session, the receiver
knows that: T_s &lt; T_r + D_t, where T_s is the current time at the sender and T_r is
the current time at the receiver.
</t>
</section>

<section title="Delay Bound Calculation in Indirect time Synchronization Mode"
	anchor="sec:delay_bound_calc_indirect_sync">
<!-- =================================== -->

<t>
In indirect time synchronization, the sender and the receivers must synchronize
indirectly with one or several time references.
</t>

<section title="Single time reference">
<!-- =================================== -->

<t>
Let us assume that there is a single time reference.
<list style='numbers'>
	<t> The sender calculates D^O_t, the upper bound of the lag of the sender's clock with respect
        to the time reference.
	This D^O_t value is then be communicated to the receivers
	(<xref target="sec:bootstrap_info"/>).</t>

	<t> Similarly, a receiver R calculates D^R_t, the upper bound of the lag of
	the receiver's clock with respect to the time reference.</t>

	<t> Then, for receiver R, the overall upper bound of the lag of the receiver's clock
	with respect to the clock of the sender, D_t, is the sum:
		D_t = D^O_t + D^R_t.</t>
</list>
The D^O_t and D^R_t calculation depends on the time synchronization mechanism
used (<xref target="sec:intro_to_indirect_time_sync"/>).
In some cases, the synchronization scheme specifications provide these values.
In other cases, these parameters can be calculated by means of a scheme similar to
the one specified in <xref target="sec:delay_bound_calc_direct_sync"/>, for instance
when synchronization is achieved via a group controller <xref target="RFC4082"/>.
</t>
</section>

<section title="Multiple time references">
<!-- =================================== -->

<t>
Let us now assume that there are several time references (e.g., several NTP/SNTP servers).
The sender and receivers use the direct time synchronization scheme to synchronize
with the various time references.
It results in D^O_t and D^R_t.
Let D_err be an upper bound of the time error between all the time references.
Then, the overall value of D_t within receiver R is set to the sum:
	D_t = D^O_t + D^R_t + D_err.
</t>

<t>
In some cases, the D_t value is part of the time synchronization scheme specifications.
For instance NTPv3 <xref target="RFC1305"/> defines algorithms that are
"capable of accuracies in the order of a millisecond, even after extended
periods when synchronization to primary reference sources has been lost".
In practice, depending on the NTP server stratum, the accuracy might be a little bit
worse.
In that case, D_t = security_factor * (1ms + 1ms), where the security_factor is
meant to compensate several sources of inaccuracy in NTP.
The choice of the security_factor value is left to the implementer, depending on
the target use-case.
</t>
</section>

</section>
</section>

<section title="Cryptographic parameter values" anchor="sec:crypto_param_values">
<!-- ==================================== -->

<t>
The F (resp. F') function output length is given by the n_p (resp. n_f) parameter.
The n_p and n_f values depend on the PRF function chosen, as specified below:
</t>
<texttable>
   <preamble></preamble>
   <ttcol align='center'>PRF name</ttcol>
   <ttcol align='center'>n_p and n_f</ttcol>
   <c>HMAC-SHA-1</c>		<c>160 bits (20 bytes)</c>
   <c>HMAC-SHA-224</c>		<c>224 bits (28 bytes)</c>
   <c>HMAC-SHA-256 (default)</c><c>256 bits (32 bytes)</c>
   <c>HMAC-SHA-384</c>		<c>384 bits (48 bytes)</c>
   <c>HMAC-SHA-512</c>		<c>512 bits (64 bytes)</c>
</texttable>

<t>
The computing of regular MAC (resp. Group MAC) makes use of the n_m (resp. n_w) parameter,
i.e., the length of the truncated output of the function.
The n_m and n_w values depend on the MAC function chosen, as specified below:
</t>
<texttable>
   <preamble></preamble>
   <ttcol align='center'>MAC name</ttcol>
   <ttcol align='center'>n_m (regular MAC)</ttcol>
   <ttcol align='center'>n_w (Group MAC)</ttcol>
   <c>HMAC-SHA-1</c>		<c>80 bits (10 bytes)</c> <c>32 bits (4 bytes)</c>
   <c>HMAC-SHA-224</c>		<c>112 bits (14 bytes)</c> <c>32 bits (4 bytes)</c>
   <c>HMAC-SHA-256 (default)</c><c>128 bits (16 bytes)</c> <c>32 bits (4 bytes)</c>
   <c>HMAC-SHA-384</c>		<c>192 bits (24 bytes)</c> <c>32 bits (4 bytes)</c>
   <c>HMAC-SHA-512</c>		<c>256 bits (32 bytes)</c> <c>32 bits (4 bytes)</c>
</texttable>

</section>

</section><!-- -Time Synchronization and Delay Bound Calculations- -->

<!-- ======================================================================= -->

<section title="Sender Operations">
<!-- ==================================== -->

<t>
This section describes the TESLA operations at a sender.
</t>

<section title="TESLA Parameters">
<!-- =================================== -->

<section title="Time Intervals" anchor="sec:time_intervals">
<!-- =================================== -->

<t>
The sender divides the time into uniform intervals of duration T_int.
Time interval numbering starts at 0 and is incremented consecutively.
The interval index MUST be stored in an unsigned 32 bit integer
so that wrapping to 0 takes place only after 2^^32 intervals.
For instance, if T_int is equal to 0.5 seconds, then wrapping takes place
after approximately 68 years.
</t>

</section>

<section title="Key Chains" anchor="sec:key_chains">
<!-- =================================== -->

<section title="Principles" anchor="sec:key_chains_principles">
<!-- =================================== -->

<t>
The sender computes a one-way key chain of n_c = N+1 keys, and assigns
one key from the chain to each interval, consecutively but in reverse order.
Key numbering starts at 0 and is incremented consecutively, following the
time interval numbering: K_0, K_1 .. K_N.
</t>

<t>
In order to compute this chain, the sender must first select a Primary Key,
K_N, and a PRF function, f (<xref target="sec:iana"/>, TESLA-PRF).
The randomness of the Primary Key, K_N, is vital to the security and no one
should be able to guess it.
</t>

<t>
The function F is a one-way function that is defined as:
F(k) = f_k(0), where f_k(0) is the result of the application
of the PRF f to k and 0.
When f is a HMAC (<xref target="sec:iana"/>),
k is used as the key, and 0 as the message, using the algorithm described in
<xref target="RFC2104"/>.
Similarly, the function F' is a one-way function that is defined as:
F'(k) = f_k(1), where f_k(1) is the result of the application
of the same PRF f to k and 1.
</t>

<t>
The sender then computes all the keys of the chain, recursively, starting with K_N,
using: K_{i-1} = F(K_i).
Therefore: K_i = F^{N-i}(K_N), where F^i(x) is the execution of function F with
the argument x, i times.
The receiver can then compute any value in the key chain from K_N,
even if it does not have intermediate values <xref target="RFC4082"/>.
The key for MAC calculation can then be derived from the corresponding K_i
key by K'_i = F'(K_i).
</t>

<t>The key chain has a finite length, N, which corresponds to a maximum time
duration of (N + 1) * T_int.
The content delivery session has a duration T_delivery, which may either be
known in advance, or not.
A first solution consists in having a single key chain of an appropriate
length, so that the content delivery session finishes before the end of the key chain,
i.e., T_delivery &le; (N + 1) * T_int.
But the longer the key chain, the higher the memory and computation required
to cope with it.
Another solution consists in switching to a new key chain, of the same length,
when necessary <xref target="Perrig04"/>.
</t>

</section>

<section title="Using Multiple Key Chains">
<!-- =================================== -->

<t>
When several key chains are needed, all of them MUST be of the same length.
Switching from the current key chain to the next one requires that a commitment
to the new key chain be communicated in a secure way to the receiver.
This can be done by using either an out-of-band mechanism, or an in-band
mechanism.
This document only specifies the in-band mechanism.
</t>

<t>
<figure anchor='fig:key_chain_switch' title="Switching to the second key chain
with the in-band mechanism, assuming that d=2, n_tx_newkcc=3, n_tx_lastkey=3.">
      <preamble></preamble>
      <artwork>
< -------- old key chain --------- >||< -------- new key chain --...
+-----+-----+ .. +-----+-----+-----+||+-----+-----+-----+-----+-----+
   0     1    ..   N-2   N-1    N   ||  N+1   N+2   N+3   N+4   N+5  
                                    ||                               
Key disclosures:                    ||                               
  N/A   N/A   ..  K_N-4 K_N-3 K_N-2 || K_N-1  K_N  K_N+1 K_N+2 K_N+3 
                 |                  ||            |                 |
                 |< -------------- >||            |< ------------- >|
Additional key        F(K_N+1)      ||                   K_N
disclosures        (commitment to   ||              (last key of the
(in parallel):      the new chain)  ||                 old chain)
      </artwork>
</figure>
</t>

<t>
<xref target="fig:key_chain_switch"/> illustrates the switch to the
new key chain, using the in-band mechanism.
Let us say that the old key chain stops at K_N and the new key chain
starts at K_{N+1} (i.e., F(K_{N+1}) and K_N are two different keys).
Then the sender includes the commitment F(K_{N+1}) to the new key chain
into packets authenticated with the old key chain
(see <xref target='sec:auth_tag_format_new_kcc'/>).
This commitment SHOULD be sent during n_tx_newkcc time intervals before the end
of the old key chain.
Since several packets are usually sent during an interval, the sender
SHOULD alternate between sending a disclosed key of the old key chain
and the commitment to the new key chain.
The details of how to alternate between the disclosure and commitment
are out of the scope of this document.
</t>

<t>The receiver will keep the commitment until the key K_{N+1} is disclosed,
at interval N+1+d.
Then the receiver will be able to test the validity of that key by computing
F(K_{N+1}) and comparing it to the commitment.</t>

<t>When the key chain is changed, it becomes impossible to recover a previous
key from the old key chain.
This is a problem if the receiver lost the packets disclosing the last key of
the old key chain.
A solution consists in re-sending the last key, K_N, of the old key chain
(see <xref target='sec:auth_tag_format_old_kck'/>). 
This SHOULD be done during n_tx_lastkey additional time intervals after the
end of the time interval where K_N is disclosed.
Since several packets are usually sent during an interval, the sender
SHOULD alternate between sending a disclosed key of the new key chain,
and the last key of the old key chain.
The details of how to alternate between the two disclosures
are out of the scope of this document.
</t>

<t>
In some cases a receiver having experienced a very long disconnection might
have lost the commitment of the new chain.
Therefore this receiver will not be able to authenticate any packet related to
the new chain and all the following ones.
The only solution for this receiver to catch up consists in receiving an additional
bootstrap information message.
This can happen by waiting for the next periodic transmission (if sent in-band)
or through an external mechanism (<xref target="sec:bootstrap_info"/>).
</t>
</section>

<section title="Values of the n_tx_lastkey and n_tx_newkcc Parameters"
	anchor="sec:value_of_tx_lastkey_tx_newkcc">
<!-- =================================== -->

<t>
When several key chains and the in-band commitment mechanism are used,
a sender MUST initialize the n_tx_lastkey
and n_tx_newkcc parameters in such a way that no overlapping occur.
In other words, once a sender starts transmitting commitments for a new
key chain, he MUST NOT send a disclosure for the last key of the old
key chain any more.
Therefore, the following property MUST be verified:
	<list style="empty">
	<t>d + n_tx_lastkey + n_tx_newkcc &le; N + 1</t>
	</list>
</t>

<t>
It is RECOMMENDED, for robustness purposes, that, once n_tx_lastkey has
been chosen, then:
	<list style="empty">
	<t>n_tx_newkcc = N + 1 - n_tx_lastkey - d</t>
	</list>
In other words, the sender starts transmitting a commitment to the following
key chain immediately after having sent all the disclosures of the last
key of the previous key chain.
Doing so increases the probability that a receiver gets a commitment for
the following key chain.
</t>

<t>
In any case, these two parameters are sender specific and need not be
transmitted to the receivers.
Of course, as explained above, the sender alternates between the disclosure
of a key of the current key chain and the commitment to the new key chain
(or the last key of the old key chain).
</t>
</section>

<section title="The Particular Case of the Session Start">
<!-- =================================== -->

<t>
Since a key cannot be disclosed before the disclosure delay, d, no key will
be disclosed during the first d time intervals (intervals 0 and 1 in
<xref target="fig:key_chain_switch"/>) of the session.
To that purpose, the sender uses the Authentication Tag Without Key Disclosure
<xref target="sec:auth_tag_wo_key_discl_format"/>.
The following key chains, if any, are not concerned since they will
disclose the last d keys of the previous chain.
</t>
</section>

<section title="Managing Silent Periods">
<!-- =================================== -->

<t>
An ALC or NORM sender may stop transmitting packets for some time.
For instance it can be the end of the session and all packets have already been sent,
or the use-case may consist in a succession of busy periods (when fresh
objects are available) followed by silent periods.
In any case, this is an issue since the authentication of the packets
sent during the last d intervals requires that the associated keys be
disclosed, which will take place during d additional time intervals.
</t>

<t>
To solve this problem, it is recommended that the sender transmit empty
packets (i.e., without payload) containing the TESLA EXT_AUTH header
extension along with a Standard Authentication Tag during at
least d time intervals after the end of the regular ALC or NORM packet transmissions.
The number of such packets and the duration during which they are sent
must be sufficient for all receivers to receive, with a high probability,
at least one packet disclosing the last useful key (i.e., the key used for
the last non-empty packet sent).
</t>
</section>

</section>

<section title="Time Interval Schedule" anchor="sec:time_int_schedule">
<!-- =================================== -->

<t>
The sender must determine the following parameters:
<list style='symbols'>
	<t>T_0, the start time corresponding to the beginning of the session, i.e., the
		beginning of time interval 0 (in NTP timestamp format);</t>
	<t>T_int, the interval duration (in milliseconds), usually ranging from 100 milliseconds to 1 
		second;</t> 
	<t>d, the key disclosure delay (in number of intervals). It is the time to wait
		before disclosing a key;</t>
	<t>N, the length of a key chain;</t>
</list></t>

<t>
The correct choice of T_int, d, and N is crucial for the efficiency of the scheme.
For instance, a T_int * d product that is too long will cause excessive delay in the
authentication process. 
A T_int * d product that is too short prevents many receivers from verifying packets.
A N * T_int product that is too small will cause the sender to switch too often to
new key chains.
A N that is too long with respect to the expected session duration (if known)
will require the sender to compute too many useless keys.
<xref target="RFC4082"/> sections 3.2 and 3.6 give general guidelines for
initializing these parameters.
</t>

<t>
The T_0, T_int, d and N parameters MUST NOT be changed during the lifetime of the session.
This restriction is meant to prevent introducing vulnerabilities.
For instance if a sender was authorized to change the key disclosure schedule, a receiver that did
not receive the change notification would still believe in the old key disclosure schedule,
thereby creating vulnerabilities <xref target="RFC4082"/>.
</t>

</section>

<section title="Timing Parameters" anchor="sec:timing_params">
<!-- =================================== -->

<t>
In indirect time synchronization mode, 
the sender must determine the following parameter:
<list style='symbols'>
	<t> D^O_t, the upper bound of the lag of the sender's clock with respect
	to the time reference.</t>
</list>
The D^O_t parameter MUST NOT be changed during the lifetime of the session.
</t>

</section>

</section><!-- TESLA Parameters -->

<section title="TESLA Signaling Messages">
<!-- =================================== -->

<t>
At a sender, TESLA produces two types of signaling information:
<list style='symbols'> 
<t>The bootstrap information:
	it can be either sent out-of-band or in-band.
	In the latter case, a digitally signed packet contains all the 
	information required to bootstrap TESLA at a receiver;</t>
<t>The direct time synchronization response, which enables a receiver to finish a
	direct time synchronization;</t>
</list>
</t>

<section title="Bootstrap Information" anchor="sec:bootstrap_info">
<!-- =================================== -->

<t>
In order to initialize the TESLA component at a receiver, the sender must
communicate some key information in a secure way.
This information can be sent in-band or out-of-band, as discussed in
<xref target="sec:intro_to_bootstrap"/>.
In this section we only consider the in-band scheme.
</t>

<t>
The TESLA bootstrap information message MUST be digitally signed
(<xref target="sec:rsa_signatures"/>).
The goal is to enable a receiver to check the packet source and packet integrity.
Then, the bootstrap information can be:
<list style='symbols'>
<t> unicast to a receiver during a direct time synchronization request/response exchange;</t>
<t> broadcast to all receivers.
	This is typically the case in indirect time synchronization mode.
	It can also be used in direct time synchronization mode, for instance
	when a large number of clients arrive at the same time, in which case
	it is more efficient to answer globally.</t>
</list>
</t>

<t>
Let us consider situations where the bootstrap information is broadcast.
This message should be broadcast at the beginning of the session, before
data packets are actually sent.
This is particularly important with ALC or NORM sessions in "push" mode,
when all clients join the session in advance.
For improved reliability, bootstrap information might be sent a certain
number of times.
</t>

<t>
A periodic broadcast of the bootstrap information message
could also be useful when:
<list style='symbols'>
<t>the ALC session uses an "on-demand" mode, clients arriving at their own
	discretion;</t>
<t>some clients experience an intermittent connectivity.
	This is particularly important when several key chains are used in an
	ALC or NORM session, since there is a risk that a receiver
	loses all the commitments to the new key chain.</t>
</list>
A balance must be found between the signaling overhead and the maximum initial
waiting time at the receiver before starting the delayed authentication process.
A period of a few seconds for the transmission of this bootstrap information
is often a reasonable value.
</t>

</section>

<section title="Direct Time Synchronization Response" anchor="sec:direct_synch_response">
<!-- =================================== -->

<t>
In Direct Time Synchronization, upon receipt of a synchronization request, the sender
records its local time, t_s, and sends a response message that contains both t_r and t_s
(<xref target="sec:delay_bound_calc_direct_sync"/>).
This message is unicast to the receiver.
This Direct Time Synchronization Response message MUST be digitally signed in order to
enable a receiver to check the packet source and packet integrity
(<xref target="sec:rsa_signatures"/>).
The receiver MUST also be able to associate this response and his request, which
is the reason why t_r is included in the response message.
</t>

</section>

</section> <!-- TESLA Messages -->

<section title="TESLA Authentication Information">
<!-- =================================== -->

<t>
At a sender, TESLA produces three types of security tags:
<list style='symbols'> 
<t>an authentication tag, in case of data packets, and which contains
	the MAC of the packet;</t>
<t>a digital signature, in case of one of the two TESLA signaling packets,
	namely a Bootstrap Information Message or a Direct Time Synchronization
	Response; and</t>
<t>an optional group authentication tag, that can be added
	to all the packets to mitigate attacks coming from outside
	of the group.</t>
</list>
</t>

<t>
Because of interdependencies, their computation MUST follow a strict
order:
<list style='symbols'> 
<t>first of all, compute the authentication tag (with data packet) or the
	digital signature (with signaling packet);</t>
<t>finally compute the Group Mac;</t>
</list>
</t>

<section title="Authentication Tags" anchor="sec:auth_tag">
<!-- =================================== -->

<t>
All the data packets sent MUST have an authentication tag containing:
<list style='symbols'>
    <t> the interval index, i, which is also the index of the key
	used for computing the MAC of this packet;</t>
<!--
	With the compact authentication tags, a subset of i will
	be communicated.
	In that case, a receiver must guess the original i value
	from the few bits carried in the packet
	(<xref target="sec:auth_received_pkts_guidelines"/>);</t>
-->
    <t> the MAC of the message: MAC(K'_i, M), where K'_i=F'(K_i);</t>
    <t> either a disclosed key (that belongs to the current key chain or the
	previous key chain), or a commitment to a new key chain,
	or no key at all;</t>
</list>
</t>

<t>
The computation of MAC(K'_i, M) MUST include the ALC or NORM header (with the
various header extensions) and the payload (when applicable).
The UDP/IP headers MUST NOT be included.
During this computation, the MAC(K'_i, M) field of the authentication tag 
MUST be set to 0.
</t>

</section>

<section title="Digital Signatures"
	anchor="sec:rsa_signatures">
<!-- =================================== -->

<t>
The Bootstrap Information message (with the in-band bootstrap scheme)
and Direct Time Synchronization Response message (with the indirect time
synchronization scheme) both need to be signed by the sender.
These two messages contain a "Signature" field to hold the digital signature.
The bootstrap information message also contains the "Signature Encoding Algorithm",
the "Signature Cryptographic Function", and the "Signature Length" fields that
enable a receiver to process the "Signature" field.
Note that there is no such "Signature Encoding Algorithm", "Signature Cryptographic Function" and
"Signature Length" fields in case of a Direct Time Synchronization Response
message since it is assumed that these parameters are already known
(i.e., the receiver either received a bootstrap information message before,
or these values have been communicated out-of-band).
</t>

<t>
Several "Signature Encoding Algorithms" can be used, including
RSASSA-PKCS1-v1_5, the default, and RSASSA-PSS (<xref target="sec:iana"/>).
With these encodings, SHA-256 is the default "Signature Cryptographic Function".
</t>

<t>
The computation of the signature MUST include the ALC or NORM header (with the
various header extensions) and the payload when applicable.
The UDP/IP headers MUST NOT be included.
During this computation, the "Signature" field MUST be set to 0 as well as
the optional Group MAC, when present, since this Group MAC is calculated later on.
</t>

<t>
More specifically, from <xref target="RFC4359"/>:
digital signature generation is performed as described in
<xref target="RFC3447"/>, Section 8.2.1 for RSASSA-PKCS1-v1_5 and
Section 8.1.1 for RSASSA-PSS.
The authenticated portion of the packet is used as the message M,
which is passed to the signature generation function.
The signer's RSA private key is passed as K.
In summary (when SHA-256 is used), the signature generation process computes
a SHA-256 hash of the authenticated packet bytes, signs the SHA-256 hash using
the private key, and encodes the result with the specified RSA encoding type.
This process results in a value S, which is the digital signature to
be included in the packet.
</t>

<t>
With RSASSA-PKCS1-v1_5 and RSASSA-PSS signatures,
the size of the signature is equal to the "RSA modulus", unless the "RSA modulus"
is not a multiple of 8 bits. In that case, the signature MUST be prepended with
between 1 and 7 bits set to zero such that the signature is a multiple of 8 bits
<xref target="RFC4359"/>.
The key size, which in practice is also equal to the "RSA modulus", has major security
implications.
<xref target="RFC4359"/> explains how to choose this value depending on the maximum
expected lifetime of the session.
This choice is out of the scope of this document.
</t>

</section>

<section title="Group MAC Tags" anchor="sec:group_auth_tag">
<!-- =================================== -->

<t>
An optional Group MAC can be used to mitigate DoS attacks coming from attackers
that are not group members <xref target="RFC4082"/>. 
This feature assumes that a group key, K_g, is shared by the sender and all receivers.
When the attacker is not a group member, the benefits of adding a group MAC to every
packet sent are threefold:
<list style='symbols'>
	<t> a receiver can immediately drop faked packets, without
	having to wait for the disclosure delay, d;
	</t>
	<t> a sender can immediately drop faked direct time synchronization requests,
	and avoid to check the digital signature, a computation intensive task;
	</t>
	<t> a receiver can immediately drop faked direct time synchronization response
	and bootstrap messages, without having to verify the digital signature, a computation
	intensive task;
	</t>
</list>
</t>

<t>
The computation of the group MAC, MAC(K_g, M), MUST include the ALC or NORM header
(with the various header extensions) and the payload when applicable.
The UDP/IP headers MUST NOT be included.
During this computation, the Group MAC field MUST be set to 0.
However the digital signature (e.g., of a bootstrap message) and the MAC fields
(e.g., of an authentication tag), when present, MUST have been calculated since 
they are included in the Group MAC calculation itself.
Then the sender truncates the MAC output to keep the n_w most significant bits
and stores the result in the Group MAC field.
</t>

<t>
This scheme features a few limits:
<list style='symbols'>
	<t>it is of no help if a group member (who knows K_g) impersonates
	the sender and sends forged messages to other receivers;</t>
	<t>it requires an additional MAC computing for each packet,
	both at the sender and receiver sides;</t>
	<t>it increases the size of the TESLA authentication headers.
	In order to limit this problem, the length of the truncated output of the
	MAC, n_w, SHOULD be kept small (e.g., 32 bits)
	(see <xref target="RFC3711"/> section 9.5).
	As a side effect, the authentication service is significantly weakened:
	the probability that any forged packet be successfully authenticated
	becomes one in 2^32.
	Since the group MAC check is only a pre-check that must be followed
	by the standard TESLA authentication check, this is not considered to
	be an issue.</t>
</list>
For a given use-case, the benefits brought by the group MAC must be balanced
against these limitations.
</t>

<t>
Note that the Group MAC function can be different from the TESLA MAC function
(e.g., it can use a weaker but faster MAC function).
Note also that the mechanism by which the group key, K_g, is communicated to all
group members, and perhaps periodically updated, is out of the scope of this document.
</t>

</section>

</section> <!-- TESLA Messages -->

<section title="Format of TESLA Messages and Authentication Tags">
<!-- =================================== -->

<t>
This section specifies the format of the various kinds of TESLA messages
and authentication tags sent by the session's sender.
Because these TESLA messages are carried as EXT_AUTH header extensions
of the ALC or NORM packets (<xref target="sec:alc_norm_integration"/>),
the following formats do not start on 32 bit word boundaries.
</t>

<section title="Format of a Bootstrap Information Message" anchor="sec:bootstrap_info_format">
<!-- =================================== -->

<t>
When bootstrap information is sent in-band, the following message is
used:
<figure anchor='fig:bootstrap_info_format' title="Bootstrap information format.">
      <preamble></preamble>
      <artwork>
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                                +-+-+-+-+-+-+-+-+  ---
                                                | V |resvd|S|G|A|  ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|       d       |    PRF Type   | MAC Func Type |Gr MAC Fun Type|  | f
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | i
|   SigEncAlgo  | SigCryptoFunc |       Signature Length        |  | x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | e
|            Reserved           |             T_int             |  | d
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|                                                               |  | l
+                  T_0 (NTP timestamp format)                   +  | e
|                                                               |  | n
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | g
|                      N (Key Chain Length)                     |  | t
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | h
|                    Current Interval Index i                   |  v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ---
|                                                               |
~                 Current Key Chain Commitment  +-+-+-+-+-+-+-+-+
|                                               |   Padding     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
~                           Signature                           ~
+                                               +-+-+-+-+-+-+-+-+
|                                               |    Padding    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P|                                                             |
+-+       D^O_t Extension (optional, present if A==1)           +
|    (NTP timestamp diff, positive if P==1, negative if P==0)   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                      Group MAC (optional)                     ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      </artwork>
</figure>
</t>

<t>
The format of the bootstrap information is depicted in
<xref target="fig:bootstrap_info_format"/>.
The fields are:</t>

<t>"V" (Version) field (2 bits):</t>
<t><list><t>
	The "V" field contains the version number of the protocol.
	For this specification, the value of 0 MUST be used.
</t></list></t>

<t>"Reserved" field (3 bits):</t>
<t><list><t>
	This is a reserved field that MUST be set to zero in this specification.
</t></list></t>

<t>"S" (Single Key Chain) flag (1 bits):</t>
<t><list><t>
	The "S" flag indicates whether this TESLA session is restricted to a single
	key chain (S==1) or relies on one or multiple key chains (S==0).
</t></list></t>

<t>"G" (Group MAC Present) flag (1 bits):</t>
<t><list><t>
	The "G" flag indicates whether the Group MAC feature is used
	(G==1) or not (G==0). When it is used, a "Group MAC" field
	is added to all the packets containing a  TESLA EXT_AUTH Header Extension
	(including this bootstrap message).
</t></list></t>

<t>"A" flag (1 bit):</t>
<t><list><t>
	The "A" flag indicates whether the P flag and D^O_t fields are present
	(A==1) or not (A==0).
	In indirect time synchronization mode, A MUST be equal to 1 since these
	fields are needed.
</t></list></t>

<!--
<t>"Sequence Number" field (8 bits):</t>
<t><list><t>
	The "Sequence Number" is incremented by the sender each time a new bootstrap
	information is sent, and reset by the sender each time a new "i" value is used.
	Since wrapping is prohibited, there can be a maximum of 256 bootstrap messages
	sent for a given "i" value.
	The Tuple (sequence number; i) is meant to protect the receiver against replay
	attacks, where the attacker stores a valid bootstrap information message and
	replays it after a certain delay.
</t></list></t>
-->

<t>"d" field (8 bits):</t>
<t><list><t>
	d is an unsigned integer that defines the key disclosure delay (in number of intervals).
	d MUST be greater or equal to 2.
</t></list></t>

<t>"PRF Type" field (8 bits):</t>
<t><list><t>
	The "PRF Type" is the reference number of the f function used to derive
        the F (for key chain) and F' (for MAC keys) functions (<xref target="sec:iana"/>).
</t></list></t>

<t>"MAC Function Type" field (8 bits):</t>
<t><list><t>
	The "MAC Function Type" is the reference number of the function used to compute
	the MAC of the packets (<xref target="sec:iana"/>).
</t></list></t>

<t>"Group MAC Function Type" field (8 bits):</t>
<t><list><t>
	When G==1, this field contains the reference number of the cryptographic MAC function
	used to compute the group MAC (<xref target="sec:iana"/>).
	When G==0, this field MUST be set to zero.
</t></list></t>

<t>"Signature Encoding Algorithm" field (8 bits):</t>
<t><list><t>
	The "Signature Encoding Algorithm" is the reference number (<xref target="sec:iana"/>) of the digital
	signature used to authenticate this bootstrap information and included in the
	"Signature" field.
</t></list></t>

<t>"Signature Cryptographic Function" field (8 bits):</t>
<t><list><t>
	The "Signature Cryptographic Function" is the reference number (<xref target="sec:iana"/>)
	of the cryptographic function used within the digital signature.
</t></list></t>

<t>"Signature Length" field (16 bits):</t>
<t><list><t>
	The "Signature Length" is an unsigned integer that indicates the signature field size in bytes
	in the "Signature Extension" field.
	This is also the signature key length, since both parameters are equal.
</t></list></t>

<t>"Reserved" fields (16 bits):</t>
<t><list><t>
	This is a reserved field that MUST be set to zero in this specification.
</t></list></t>

<t>"T_int" field (16 bits):</t>
<t><list><t>
	T_int is an unsigned 16 bit integer that defines the interval duration (in milliseconds).
</t></list></t>

<t>"T_0" field (64 bits):</t>
<t><list><t>
	"T_0" is a timestamp in NTP timestamp format that indicates the beginning of the session, i.e., the
		beginning of time interval 0.
</t></list></t>

<t>"N" field (32 bits):</t>
<t><list><t>
	"N" is an unsigned integer that indicates the key chain length.
	There are N + 1 keys per chain.
</t></list></t>

<t>"i" (Interval Index of K_i) field (32 bits):</t>
<t><list><t>
	"i" is an unsigned integer that indicates the current interval index
	when this bootstrap information message is sent.
</t></list></t>

<t>"Current Key Chain Commitment" field (variable size, padded if necessary for 32 bit word alignment):</t>
<t><list><t>
	"Key Chain Commitment" is the commitment to the current key chain,
	i.e., the key chain corresponding to interval i.
	For instance, with the first key chain, this commitment is equal to F(K_0),
	with the second key chain, this commitment is equal to F(K_{N+1}), etc.).
	If need be, this field is padded (with 0) up to a multiple of 32 bits.
</t></list></t>

<t>"Signature" field (variable size, padded if necessary for 32 bit word alignment):</t>
<t><list><t>
	The "Signature" field is mandatory.
	It contains a digital signature of this message, as specified by the
	encoding algorithm, cryptographic function and key length parameters.
	If the signature length is not multiple of 32 bits, this field is padded
	with 0.
</t></list></t>

<t>"P" flag (optional, 1 bit if present):</t>
<t><list><t>
	The "P" flag is optional and only present if the A flag is equal to 1..
	It is only used in indirect time synchronization mode.
	This flag indicates whether the D^O_t NTP timestamp difference is positive
	(P==1) or negative (P==0).
</t></list></t>

<t>"D^O_t" field (optional, 63 bits if present):</t>
<t><list><t>
	The "D^O_t" field is optional and only present if the A flag is equal to 1.
	It is only used in indirect time synchronization mode.
	It is the upper bound of the lag of the sender's clock with
	respect to the time reference.
	When several time references are specified (e.g., several NTP servers), then
	D^O_t is the maximum upper bound of the lag with each time reference.
	D^O_t is composed of two unsigned integers, as with NTP timestamps:
	the first 31 bits give the time difference in seconds and the remaining 32 bits
	give the sub-second time difference.
<!--
<list><t> Editor's note: a first alternative would be to use floating
	point arithmetic, IEEE754 for carrying D^O_t.
	NTP timestamp difference is usually performed with double floating
	point arithmetic internally (at least in TESLA and NTPv4 implementations),
	so it makes sense. But it looks a bit awkward.
	A second alternative would be to use a signed integer representing the
	difference in sub-second units (e.g., in milliseconds). This is simple
	but it requires NTP timestamp/ms conversions on both sides.
	The use of the "P" flag seems simpler...
	</t>
</list>
-->
</t></list></t>

<t>"Group MAC" field (optional, variable length, multiple of 32 bits):</t>
<t><list><t>
	This field contains the group MAC, calculated with the group key, K_g,
	shared by all group members.
	The field length, in bits, is given by n_w which is known once the
	group MAC function type is known (<xref target="sec:iana"/>).
</t></list></t>

<t>
Note that the first byte and the following seven 32-bit words are mandatory fixed
length fields.
The Current Key Chain Commitment and Signature fields are mandatory but variable length fields.
The remaining D^O_t and Group MAC fields are optional.
</t>

<t>
In order to prevent attacks, some parameters MUST NOT be changed during the lifetime of the session
(<xref target="sec:time_int_schedule"/>, <xref target="sec:timing_params"/>).
The following table summarizes the parameters status:
</t>
       <texttable>
           <preamble></preamble>
           <ttcol align='center' width='35%'>Parameter</ttcol>
           <ttcol align='center'>Status</ttcol>
           <c>V</c><c>set to 0 in this specification</c>
           <c>S</c><c>static (during whole session)</c>
           <c>G</c><c>static (during whole session)</c>
           <c>A</c><c>static (during whole session)</c>
           <c>T_O</c><c>static (during whole session)</c>
           <c>T_int</c><c>static (during whole session)</c>
           <c>d</c><c>static (during whole session)</c>
           <c>N</c><c>static (during whole session)</c>
           <c>D^O_t (if present)</c><c>static (during whole session)</c>
           <c>PRF Type</c><c>static (during whole session)</c>
           <c>MAC Function Type</c><c>static (during whole session)</c>
           <c>Signature Encoding Algorithm</c><c>static (during whole session)</c>
           <c>Signature Crypto. Function</c><c>static (during whole session)</c>
           <c>Signature Length</c><c>static (during whole session)</c>
           <c>Group MAC Func. Type</c><c>static (during whole session)</c>
           <c>i</c><c>dynamic (related to current key chain)</c>
           <c>K_i</c><c>dynamic (related to current key chain)</c>
           <c>signature</c><c>dynamic, packet dependent</c>
           <c>Group MAC (if present)</c><c>dynamic, packet dependent</c>
       </texttable>

</section><!-- -Bootstrap Information Format- -->

<section title="Format of a Direct Time Synchronization Response"
	anchor='sec:direct_synch_response_format'>
<!-- =================================== -->

<t>
<figure anchor='fig:direct_synch_response_format'
	title="Format of a Direct Time Synchronization Response">
      <preamble></preamble>
      <artwork>
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                                 +-+-+-+-+-+-+-+-+
                                                 |    Reserved   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 +                     t_s (NTP timestamp)                       +
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 +                     t_r (NTP timestamp)                       +
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 +                                                               +
 ~                           Signature                           ~
 +                                               +-+-+-+-+-+-+-+-+
 |                                               |    Padding    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                     Group MAC (optional)                      ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      </artwork>
</figure>
</t>

<t>The response to a direct time synchronization request contains the following
information:</t>

<t>"Reserved" fields (8 bits):</t>
<t><list><t>
	This is a reserved field that MUST be set to zero in this specification.
</t></list></t>

<t>"t_s" (NTP timestamp, 64 bits):</t>
<t><list><t>
	t_s is a timestamp in NTP timestamp format that corresponds to the sender local time value when receiving
	the direct time synchronization request message.
</t></list></t>

<t>"t_r" (NTP timestamp, 64 bits):</t>
<t><list><t>
	t_r is a timestamp in NTP timestamp format that contains the receiver local time value received
	in the direct time synchronization request message.
</t></list></t>

<t>"Signature" field (variable size, padded if necessary for 32 bit word alignment):</t>
<t><list><t>
	The "Signature" field is mandatory.
	It contains a digital signature of this message, as specified by the
	encoding algorithm, cryptographic function and key length parameters
	communicated in the  bootstrap information message (if applicable) or out-of-band.
	If the signature length is not multiple of 32 bits, this field is padded
	with 0.
</t></list></t>

<t>"Group MAC" field (optional, variable length, multiple of 32 bits):</t>
<t><list><t>
	This field contains the Group MAC, calculated with the group key, K_g,
	shared by all group members.
	The field length, in bits, is given by n_w, which is known once the
	group MAC function type is known (<xref target="sec:iana"/>).
</t></list></t>

</section><!-- -Direct Time Synch Response Format- -->

<section title="Format of a Standard Authentication Tag" anchor='sec:auth_tag_format'>
<!-- =================================== -->

<t>
<figure anchor='fig:authentication_tag' title="Format of the  Standard Authentication Tag">
      <preamble></preamble>
      <artwork>
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                                 +-+-+-+-+-+-+-+-+
                                                 |   Reserved    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                i (Interval Index of K'_i)                     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                    Disclosed Key K_{i-d}                      ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                       MAC(K'_i, M)            +-+-+-+-+-+-+-+-+
 |                                               |   Padding     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                     Group MAC (optional)                      ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      </artwork>
</figure>
</t>

<t>
<xref target='fig:authentication_tag'/> shows the format of the Standard Authentication Tag:</t>

<t>"Reserved" field (8 bits):</t>
<t><list><t>
 	The "Reserved" field is not used in the current specification
	and MUST be set to zero by the sender.
</t></list></t>

<t>"i" (Interval Index) field (32 bits):</t>
<t><list><t>
	i is the interval index associated to the key (K'_i) used to compute
	the MAC of this packet.
</t></list></t>

<t>"Disclosed Key" (variable size, non padded):</t>
<t><list><t>
	The "Disclosed Key" is the key used for interval i-d: K_{i-d}.
	There is no padding between the "Disclosed Key" and "MAC(K'_i, M)"
	fields, and the latter MAY not start on a 32 bit boundary,
	depending on the n_p parameter.
</t></list></t>

<t>"MAC(K'_i, M)" (variable size, padded if necessary for 32 bit word alignment):</t>
<t><list><t>
	MAC(K'_i, M) is the truncated message authentication code of the current packet.
	Only the n_m most significant bits of the MAC output are kept <xref target="RFC2104"/>.
</t></list></t>

<t>"Group MAC" field (optional, variable length, multiple of 32 bits):</t>
<t><list><t>
	This field contains the Group MAC, calculated with a group key, K_g, shared
	by all group members.
	The field length is given by n_w, in bits.
</t></list></t>

<t>
Note that because a key cannot be disclosed before the disclosure delay, d,
the sender MUST NOT use this tag during the first d intervals of the session:
{0 .. d-1} (inclusive).
Instead the sender MUST use an Authentication Tag Without Key Disclosure.
</t>

</section>

<section title="Format of an Authentication Tag Without Key Disclosure"
	anchor='sec:auth_tag_wo_key_discl_format'>
<!-- =================================== -->

<t>
The authentication tag without key disclosure is meant to be used in situations where a
high number of packets are sent in a given time interval.
In such a case, it can be advantageous to disclose the K_{i-d} key only in a subset of the
packets sent, using a Standard Authentication Tag, and use the shortened version that
does not disclose the K_{i-d} key in the remaining packets.
It is left to the implementer to decide how many packets should disclose the K_{i-d}
key.
This Authentication Tag Without Key Disclosure MUST also be used during the first
d intervals: {0 .. d-1} (inclusive).
</t>

<t>
<figure anchor='fig:authentication_tag_wo_key_discl' title="Format of the Authentication Tag Without Key Disclosure">
      <preamble></preamble>
      <artwork>
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                                 +-+-+-+-+-+-+-+-+
                                                 |   Reserved    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                i (Interval Index of K'_i)                     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                       MAC(K'_i, M)            +-+-+-+-+-+-+-+-+
 |                                               |   Padding     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                     Group MAC (optional)                      ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      </artwork>
</figure>
</t>

</section>

<section title="Format of an Authentication Tag with a ``New Key Chain'' Commitment"
	anchor='sec:auth_tag_format_new_kcc'>
<!-- =================================== -->
<t>
During the last n_tx_newkcc intervals of the current key chain, the sender
SHOULD send commitments to the next key chain.
This is done by replacing the disclosed key of the 
authentication tag with the new key chain commitment, F(K_{N+1})
(or F(K_{2N+2}) in case of a switch between the second and third key chains, etc.).
<xref target='fig:new_comm_tag'/> shows the corresponding format.
</t>

<t>
Note that since there is no padding between the "F(K_{N+1})" and "MAC(K'_i, M)"
fields, this latter MAY not start on a 32 bit boundary,
depending on the n_p parameter.
</t>

<t>
<figure anchor='fig:new_comm_tag' title="Format of the Authentication Tag with a New
        Key Chain Commitment">
      <preamble></preamble>
      <artwork>
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                                 +-+-+-+-+-+-+-+-+
                                                 |   Reserved    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                i (Interval Index of K'_i)                     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~              New Key Commitment F(K_{N+1})                    ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                       MAC(K'_i, M)            +-+-+-+-+-+-+-+-+
 |                                               |   Padding     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                     Group MAC (optional)                      ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      </artwork>
</figure>
</t>
</section><!-- -New key chain commitment- -->

<section title="Format of an Authentication Tag with a ``Last Key of Old Chain'' Disclosure" 
	anchor='sec:auth_tag_format_old_kck'>
<!-- =================================== -->
<t>
During the first n_tx_lastkey intervals of the new key chain after
the disclosing interval, d, the sender SHOULD disclose the last key
of the old key chain.
This is done by replacing the disclosed key of the 
authentication tag with the last key of the old chain, K_N
(or K_{2N+1} in case of a switch between the second and third key chains, etc.).
<xref target='fig:old_comm_tag'/> shows the corresponding format.
</t>

<t>
Note that since there is no padding between the "K_N" and "MAC(K'_i, M)"
fields, this latter MAY not start on a 32 bit boundary,
depending on the n_p parameter.
</t>

<t>
<figure anchor='fig:old_comm_tag' title="Format of the authentication tag with an old chain
last key disclosure">
      <preamble></preamble>
      <artwork>
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                                 +-+-+-+-+-+-+-+-+
                                                 |   Reserved    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                i (Interval Index of K'_i)                     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                  Last Key of Old Chain, K_N                   ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                       MAC(K'_i, M)            +-+-+-+-+-+-+-+-+
 |                                               |   Padding     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                     Group MAC (optional)                      ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      </artwork>
</figure>
</t>

</section><!-- -Old key chain commitment- -->

</section><!-- -Signaling Information Format- -->

</section><!-- =Sender= -->

<!-- ======================================================================= -->

<section title="Receiver Operations">
<!-- ==================================== -->

<t>
This section describes the TESLA operations at a receiver.
</t>

<section title="Verification of the Authentication Information" anchor="sec:verif_auth_info">
<!-- =================================== -->

<t>
This section details the computation steps required to verify
each of the three possible authentication information of an
incoming packet.
The verification MUST follow a strict order:
<list style='symbols'> 
<t>first of all, if the Group MAC is present and if the session uses this feature
	(e.g., if the G bit is set in the bootstrap information message), then verify
	the Group MAC.
	A packet that does not contain a Group MAC tag whereas the session uses
	this feature MUST be immediately dropped.
	On the opposite, if a packet contains a Group MAC tag whereas the session does
	not use this feature, this tag MUST be ignored;</t>
<t>then verify the digital signature (with TESLA signaling
	packets) or enter the TESLA authentication process
	(with data packets)</t>
</list>
</t>

<section title="Processing the Group MAC Tag" anchor="sec:verif_group_mac">
<!-- =================================== -->

<t>
Upon receiving a packet containing a Group MAC Tag, the receiver
recomputes the Group MAC and compares it to the value carried in the packet.
If the check fails, the packet MUST be immediately dropped.
</t>

<t>
More specifically, recomputing the Group MAC requires to save the
value of the Group MAC field, to set this field to 0, and to do
the same computation as a sender does (see <xref target="sec:group_auth_tag"/>).
</t>

</section>

<section title="Processing the Digital Signature">
<!-- =================================== -->

<t>
Upon receiving a packet containing a digital signature, the receiver
verifies the signature as follows.
</t>

<t>
The computation of the signature MUST include the ALC or NORM header (with the
various header extensions) and the payload when applicable.
The UDP/IP headers MUST NOT be included.
During this computation, the "Signature" field MUST be set to 0 as well as
the optional Group MAC, when present.
</t>

<t>
>From <xref target="RFC4359"/>:
Digital signature verification is performed as described in
<xref target="RFC3447"/>, Section 8.2.2 (RSASSA-PKCS1-v1_5) and
<xref target="RFC3447"/>, Section 8.1.2 (RSASSA-PSS).
Upon receipt, the digital signature is passed to the
verification function as S.
The authenticated portion of the packet is used as the message M,
and the RSA public key is passed as (n, e).
In summary (when SHA-256 is used), the verification function computes a SHA-256
hash of the authenticated packet bytes, decrypts the SHA-256 hash in
the packet, and validates that the appropriate encoding was applied.
<!--and was correct.-->
The two SHA-256 hashes are compared, and if they are identical the
validation is successful.
</t>

<t>
It is assumed that the receivers have the possibility
to retrieve the sender's public key required to check this digital signature
(<xref target="sec:intro_to_bootstrap"/>).
This document does not specify how the public key of the sender is
communicated reliably and in a secure way to all possible receivers.
</t>

</section>

<section title="Processing the Authentication Tag">
<!-- =================================== -->

<t>
When a receiver wants to authenticate a packet using an Authentication Tag and
when he has the key for the associated time interval (i.e., after the disclosing
delay, d), the receiver recomputes the MAC and compares it to the value carried
in the packet.
If the check fails, the packet MUST be immediately dropped.
</t>

<t>
More specifically, recomputing the MAC requires to save the
value of the MAC field, to set this field to 0, and to do
the same computation as a sender does (see <xref target="sec:auth_tag"/>).
</t>

</section>

</section><!-- -Verification of the Authentication Information- -->

<section title="Initialization of a Receiver">
<!-- =================================== -->

<t>
A receiver MUST be initialized before being able to authenticate the source
of incoming packets.
This can be done by an out-of-band mechanism or an in-band mechanism
(<xref target="sec:intro_to_bootstrap"/>).
Let us focus on the in-band mechanism.
Two actions must be performed:
<list style='symbols'> 
<t>receive and process a bootstrap information message, and</t>
<t>calculate an  upper bound of the sender's local time. 
	To that purpose, the receiver must perform time synchronization.</t>
</list>
</t>

<section title="Processing the Bootstrap Information Message" anchor="sec:recv_process_bootstrap">
<!-- =================================== -->

<t>
A receiver must first receive a packet containing the bootstrap
information, digitally signed by the sender.
Once the bootstrap information has been authenticated (sec
<xref target="sec:verif_auth_info"/>), the receiver can initialize its TESLA
component.
The receiver MUST then ignore the following bootstrap information messages,
if any.
There is an exception though: when a new key chain is used and if a receiver
missed all the commitments for this new key chain, then this receiver
MUST process one of the future Bootstrap information messages (if any) in
order to be able to authenticate the incoming packets associated to this
new key chain.
</t>

<t>
Before TESLA has been initialized, a receiver MUST discard incoming packets
other than the bootstrap information message and direct time synchronization response.
<!--
VR: dangereux car il y aura un dephasage temporel ensuite, lorsque la synchro
NTP aura lieu, et on n'aura plus la garantie permettant de passer le test
"Safe Pkt Test"... Dangereux, donc a eviter...

Yet, a receiver MAY chose to buffer incoming packets, recording the reception time
of each packet, and proceed with delayed authentication later, once the
receiver will be fully initialized.
In that case, the buffer must be carefully sized in order to prevent memory
starvation (e.g., an attacker who sends faked packets before the session actually
starts can exhaust the memory of receivers who do not limit the maximum incoming
buffer size).
-->
</t>

</section>

<section title="Performing Time Synchronization" anchor="sec:rx_time_synchro">
<!-- =================================== -->

<t>
First of all, the receiver must know whether the ALC or NORM session
relies on direct or indirect time synchronization.
This information is communicated by an out-of-band mechanism (for instance when
describing the various parameters of an ALC or NORM session.
In some cases, both mechanisms might be available and the receiver can choose
the preferred technique.
</t>

<section title="Direct Time Synchronization" anchor="sec:direct_synch_request_format">
<!-- =================================== -->

<t>
In case of a direct time synchronization, a receiver MUST synchronize
with the sender.
To that purpose, the receiver sends a direct time synchronization request message.
This message includes the local time (in NTP timestamp format) at the receiver when sending
the message.
This timestamp will be copied in the sender's response for the receiver to
associate the response to the request.
</t>

<t>
The direct time synchronization request message format is the following:
</t>

<t>
<figure anchor='fig:direct_synch_request_format'
	title="Format of a Direct Time Synchronization Request">
      <preamble></preamble>
      <artwork>
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 +                     t_r (NTP timestamp)                       +
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                     Group MAC (optional)                      ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      </artwork>
</figure>
</t>

<t>The direct time synchronization request (<xref target="fig:direct_synch_request_format"/>)
contains the following information:</t>

<t>"t_r" (NTP timestamp, 64 bits):</t>
<t><list><t>
	t_r is a timestamp in NTP timestamp format that contains the receiver local time value when
	sending this direct time synchronization request message;
</t></list></t>

<t>"Group MAC" field (optional, variable length, multiple of 32 bits):</t>
<t><list><t>
	This field contains the Group MAC, calculated with the group key, K_g, shared
	by all group members.
	The field length, in bits, is given by n_w, which is known once the Group MAC
	function type is known (Section 7).
</t></list></t>

<t>
<!--
<xref target="sec:direct_synch_response_format"/> specifies the
direct time synchronization response message format.
-->
The receiver then awaits a response message (<xref target="sec:direct_synch_response_format"/>).
Upon receiving this message, the receiver:
<list>
<t>	checks that this response relates to the request, by comparing the t_r fields;</t>
<t>	checks the Group MAC if present;</t>
<t>	checks the signature;</t>
<t>	retrieves the t_s value and calculates D_t
	(<xref target="sec:delay_bound_calc_direct_sync"/>);</t>
</list>
</t>

<t>
Note that in an ALC session, the direct time synchronization request message
is sent to the sender by an out-of-band mechanism that is not specified by
the current document.
</t>

</section>

<section title="Indirect Time Synchronization">
<!-- =================================== -->

<t>
With the indirect time synchronization method, the sender MAY provide out-of-band
the URL or IP address of the NTP server(s) he trusts along with an OPTIONAL certificate
for each NTP server.
When several NTP servers are specified, a receiver MUST choose one of them.
This document does not specify how the choice is made, but for the sake
of scalability, the clients SHOULD NOT use the same server if several
possibilities are offered.
The NTP synchronization between the NTP server and the receiver
MUST be authenticated, either using the certificate provided by the server,
or another certificate the client may obtain for this NTP server.
</t>

<t>
Then the receiver computes the time offset between itself and the NTP
server chosen. 
Note that the receiver does not need to update the local time, 
(which often requires root privileges), computing the
time offset is sufficient.
</t>

<t>
Since the offset between the server and the time reference, D^O_t, is indicated
in the bootstrap information message (or communicated out-of-band), the receiver
can now calculate an upper bound of the sender's local time
(<xref target="sec:delay_bound_calc_indirect_sync"/>).
</t>

<t>
Note that this scenario assumes that each client trusts the sender and accepts to
align its NTP configuration to that of the sender, using one of the NTP server(s)
suggested. If this assumption does not hold, the client MUST NOT use the NTP indirect
time synchronization method (<xref target="sec:intro_to_indirect_time_sync"/>).
</t>

</section>

</section>

</section><!-- -Initialization of a Receiver- -->

<section title="Authentication of Received Packets" anchor="sec:auth_received_pkts_guidelines">
<!-- =================================== -->

<t>
The receiver can now authenticate incoming packets (other than bootstrap information and
direct time synchronization response packets).
To that purpose, he MUST follow different steps (see <xref target="RFC4082"/> section 3.5):
<list style='numbers'>
<t>The receiver parses the different packet headers.
	If none of the four TESLA authentication tags is present, the receiver MUST
	discard the packet.
	If the session is in "Single Key Chain" mode (e.g., when the "S" flag is set
	in the bootstrap information message), then the receiver MUST discard
	any packet containing an Authentication Tag With a New Key Chain Commitment
	or an Authentication Tag With a Last Key of Old Chain Disclosure.
</t>

<t> Safe packet test:
	When the receiver receives packet P_j, it first records the
	local time T at which the packet arrived.
	The receiver then computes an upper bound t_j on the sender's
        clock at the time when the packet arrived: t_j = T + D_t.
	The receiver then computes the highest interval the sender
	could possibly be in: highest_i = floor((t_j - T_0) / T_int).
<!--
	Two possibilities arise then:
	<list style='symbols'>
		<t> with a non compact authentication tag, the "i" interval
		index is available. Get it from the header.
		</t>

		<t>
		When a compact authentication tag is used, the receiver must
		compute the corresponding "i" interval index from the "i_LSB"
		and perhaps "i_NSB" fields. The following algorithm is used:
<figure>
<artwork>
if (MAC(K'_i, M) is not padded) {
    // with HMAC-SHA-256 and higher, the i_LSB field is the only
    // field available to guess i.
    i_mask = 0xFFFFFF00;
    i_low = i_LSB;              // lower bits of "i"
} else {
    // with a two byte padding (i.e., HMAC-SHA-1 and HMAC-SHA-224),
    // the 2 byte i_NSB field is available in addition to i_LSB.
    i_mask = 0xFF000000;
    i_low = i_LSB + i_NSB;      // lower bits of "i"
}
i_high = highest_i & i_mask;    // (guessed) higher bits of "i", using
                                // the highest interval the sender can
                                // possibly be in.
i = i_high + i_low;             // raw guessed "i"
if (i > highest_i) {
    // cycling took place. Since "i" cannot be larger than "highest_i",
    // decrement it.
    i_cycle = (~i_mask) + 1;    // length of a cycle
    i = i - i_cycle;
}
</artwork>
</figure>
		</t>
	</list>
-->
	He also retrieves the "i" interval index from the
	authentication tag.
	The receiver can now proceed with the "safe packet" test.
	If highest_i < i + d, then the sender is not yet in the interval
	during which it discloses the key K_i. The packet is safe (but
	not necessarily authentic).
	If the test fails, the packet is unsafe, and the receiver MUST
	discard the packet.
</t>

<t> Group MAC test: if the optional Group MAC tag is present and if the
	session uses this feature, then verify the Group MAC
	(<xref target="sec:verif_group_mac"/>).
	If the verification fails, the packet MUST be immediately dropped.
	A packet that does not contain a Group MAC tag whereas the session uses
	this feature MUST be immediately dropped.
	On the opposite, if a packet contains a Group MAC tag whereas the session does
	not use this feature, this tag MUST be ignored.
</t>

<!--
<t> New key index test: Next the receiver checks whether a key K_v
	has already been disclosed with the same index v as the
	current disclosed key K_{i-d}, or with a later one; that is,
	with v >= i-d.
</t>

<t> Key verification test: If the disclosed key index is new, the
	receiver checks the legitimacy of K_{i-d} by verifying, for
	some earlier disclosed key K_v (with v < i-d), that
	K_v = F^{i-d- v}(K_{i-d}).
	In other words, the receiver checks the disclosed key by
	computing the necessary number of PRF functions to obtain a
	previously safe disclosed key.

	If the key verification fails, the receiver MUST discard the packet.
	If the key verification succeeds, this key is said legitimate.
</t>
-->
<t> Disclosed Key processing:
	When the packet discloses a key (i.e., with a Standard Authentication Tag, or
	with an Authentication Tag with a ``Last Key of Old Chain'' Disclosure),
	the following tests are performed:
	<list style='symbols'>
	<t> New key index test: the receiver checks whether a legitimate key 
		already exists with the same index (i.e., i-d).
		<!-- or with an index strictly superior (i.e., with an index > i-d).-->
		If such a legitimate key exists, the receiver compares its
		value with the current disclosed key and if they are identical,
		skips the "Unverifiable key test" and "Key verification test".
		If such a legitimate key exists but the values differ, the
		receiver MUST discard the packet.
	</t>

	<t> Unverifiable key test: when the disclosed key index is new, it is
		possible that no earlier disclosed and legitimate key exists
		for this key chain, thereby preventing the verification of the
		disclosed key.
		This happens when the disclosed key belongs to the old
		key chain and no commitment to this old key chain has
		ever been received (e.g., because the first bootstrap packet
		received by a latecomer is for the current key chain, and
		therefore includes a commitment to the current key chain, not
		the previous one).
		
		When this happens, the receiver MUST ignore the disclosed key
		(anyway useless) and skip the "Key verification test".
	</t>

	<t> Key verification test: If the disclosed key index is new and the
		key can be verified, the receiver checks the legitimacy of
		K_{i-d} by verifying, for some earlier disclosed and legitimate
		key K_v (with v < i-d), that K_v and F^{i-d-v}(K_{i-d}) are identical.
		In other words, the receiver checks the disclosed key by
		computing the necessary number of PRF functions to obtain a
		previously disclosed and legitimate (i.e., verified) key.

		If the key verification fails, the receiver MUST discard the packet.
		If the key verification succeeds, this key is said legitimate and
		is stored by the receiver, as well as all the keys between indexes
		v and i-d.
	</t>
	</list>
	</t>

<!--
<t> New Key Chain Commitment processing:
	When the packet includes a new key chain commitment (i.e., with a
	standard or compact authentication tag with a new key chain commitment),
	the receiver first checks whether a commitment has already been received
	or not for this new key chain.
	If this is a new commitment, the receiver stores it.
	If a commitment is already available, it is recommended that the receiver
	stores the new commitment. Indeed, the previously stored commitment(s)
	may fail the authentication test and therefore turn out to be useless.

	When the commitment is stored, it is marked as non-verified. This commitment
	will be validated later on, when the associated packet is authenticated.
</t>
-->

<t>When applicable, the receiver performs any congestion control related action
	(i.e., the ALC or NORM headers are used by the associated congestion control
	building block, if any), even if the packet has not yet been
	authenticated <xref target="RMT-BB-LCT"/>.
	If this feature leads to a potential DoS attack (the attacker can send
	a faked packet with a wrong sequence number to simulate packet losses),
	it does not compromise the security features offered by TESLA and enables
	a rapid reaction in front of actual congestion problems.
</t>

<t>The receiver then buffers the packet for a later authentication, once the corresponding
	key will be disclosed (after d time intervals) or deduced from another key
	(if all packets disclosing this key are lost).
	In some situations, this packet might also be discarded later on, if
	it turns out that the receiver will never be able to deduce the associated key.
</t>

<t>Authentication test:
	Let v be the smallest index of the legitimate keys known by the receiver
	so far. For all the new keys K_w, with v < w &le; i-d, that have been
	either disclosed by this packet (i.e., K_{i-d}) or derived by K_{i-d}
	(i.e., keys in interval {v+1,.. i-d-1}), the receiver verifies the
	authenticity of the safe packets buffered for the corresponding
	interval w.

	To authenticate one of the buffered packets P_h containing
	message M_h protected with a MAC that used key index w, the
	receiver will compute K'_w = F'(K_w) from which it can
	compute MAC( K'_w, M_h).

	If this MAC does not equal the MAC stored in the packet, the receiver
	MUST discard the packet.

	If the two MAC are equal, the packet is successfully authenticated and the
	receiver continues processing it.
</t>

<t>Authenticated new key chain commitment processing:
	If the authenticated packet contains a new key chain commitment and if
	no verified commitment already exists, then the receiver stores the
	commitment to the new key chain.
	Then, if there are non authenticated packets for a previous chain
	(i.e., the key chain before the current one), all these packets can be
	discarded (<xref target="sec:flushing_pkts_of_prev_key_chain"/>).
</t>

<t>The receiver continues the ALC or NORM processing of all the packets
	authenticated during the authentication test.
</t>

</list></t>

<t>
In this specification, a receiver using TESLA MUST immediately drop unsafe packets.
But the receiver MAY also decide, at any time, to continue an ALC or NORM session in
unsafe (insecure) mode, ignoring TESLA extensions. There SHOULD be an explicit
user action to that purpose.
</t>

<!-- 
<section title="Wrong Guess of the i Parameter">

<t>
When a compact authentication tag is used, the receiver computes the "i"
interval index from the "i_LSB" and perhaps "i_NSB" fields, and therefore
there is a risk of error.
Let us consider the case where only "i_LSB" is used (situation with the
highest risks of error).
An error occurs when the calculated i_high (at a receiver)
differs from the original i_high (at the sender),
where the receiver calculates i_high by: i_high = floor((t_j - T_0) / T_int) & 0xFFFFFF00).
So an error occurs if the elapsed time: t_j - T_0 >= K*(256*T_int),
where K is an integer greater or equal to 1.
So there will be an error if the packet has been delayed by at least 256*T_int milliseconds.
Since T_int is roughly equal to the RTT, the probability is low.
This is even more true when both "i_LSB" and "i_NSB" fields are used.
</t>

<t>
Of course, an attacker can also deliberately corrupt the "i_LSB"/"i_NSB"
fields, but the same remark can be done with the "i" field.
</t>

<t>
If ever an error occurs, be it intentional (attack) or not, this error will
be caught either (<xref target="sec:auth_received_pkts_guidelines"/>):
<list style='symbols'>
	<t> by the safe packet test (step 2), or</t>
	<t> by the new key index test (step 4a) or key verification test (step 4b)
	    if this packet discloses a key,</t>
	<t> or by the authentication test (step 7), when the key corresponding
	    to this wrong interval index is disclosed. This final test always
	    catches the wrong "i" parameter value.</t>
</list>
If an error is identified, the receiver MUST discard the packet.
TESLA is therefore robust to wrong "i" parameter values.
</t>

</section>
-->

<section title="Discarding Unnecessary Packets Earlier">
<!-- =================================== -->

<t>
Following strictly the above steps can lead to excessive processing overhead
in certain situations.
This is the case when a receiver receives packets for an unwanted object with
the ALC or NORM protocols, i.e., an object for which the application (or the
end user) explicitly mentioned it is not interested in.
This is also the case when a receiver receives packets for an already decoded
object, or when this object has been partitioned in several blocks, for an
already decoded block.
When such a packet is received, which is easily identified by looking at the
receiver's status for the incoming ALC or NORM packet, the receiver MUST also
check that the packet is a pure data packet that does not contain any signaling
information of importance for the session.
</t>

<t>
With ALC, a packet containing a "A" flag ("Close Session") or a "B" flag
("Close Object") MUST NOT be discarded before having been authenticated
and processed normally.
Otherwise, the receiver can safely discard the incoming packet for instance
just after step 1 of <xref target="sec:auth_received_pkts_guidelines"/>.
This optimization can dramatically reduce the processing overhead, by
avoiding many useless authentication checks.
</t>

</section>

</section><!-- -Receiving authenticated data- -->

<section title="Flushing the Non Authenticated Packets of a Previous Key Chain"
anchor="sec:flushing_pkts_of_prev_key_chain">
<!-- =================================== -->

<t>
In some cases a receiver having experienced a very long disconnection might
have lost all the disclosures of the last key(s) of a previous key chain.
Let j be the index of this key chain for which there remains non authenticated
packets.
This receiver can flush all the packets of the key chain j if he determines that:
<list style='symbols'>
	<t>he has just switched to a chain of index j+2 (inclusive) or higher; </t>
	<t>the sender has sent a commitment to the new key chain of index j+2
	(<xref target="sec:value_of_tx_lastkey_tx_newkcc"/>).
	This situation requires that the receiver has received a packet containing
	such a commitment and that he has been able to check its integrity.
	In some cases it might require to receive a bootstrap information message
	for the current key chain.</t>
</list>
If one of the above two tests succeeds, the sender can discard all the awaiting
packets since there is no way to authenticate them.
</t>

</section><!-- -Flushing non auth pkts- -->
</section><!-- =Receiver= -->

<!-- ======================================================================= -->

<section title="Integration in the ALC and NORM Protocols"
	anchor='sec:alc_norm_integration'>
<!-- =================================== -->

<section title="Authentication Header Extension Format"
	anchor='sec:auth_he_format'>
<!-- =================================== -->

<t>
The integration of TESLA in ALC or NORM is similar and relies on the 
header extension mechanism defined in both protocols.
More precisely this document details the EXT_AUTH==1 header extension defined
in <xref target="RMT-BB-LCT"/>.
</t>

<!--
<t>
<list><t> Editor's note:
	All authentication schemes using the EXT_AUTH header extension MUST
	reserve the same 4 bit "ASID" field after the HET/HEL fields.
	This way, several authentication schemes can be used in the same ALC
	or NORM session, even on the same communication path.
	</t>
</list>
</t>
-->

<t>
Several fields are added in addition to the HET (Header Extension Type) and HEL
(Header Extension Length) fields (<xref target="lct_integration"/>).
</t>

<t>
<figure title='Format of the TESLA EXT_AUTH header extension.'
	anchor='lct_integration'>
      <artwork>
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   HET (=1)    |      HEL      |  ASID |  Type |               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
 |                                                               |
 ~                                                               ~
 |                            Content                            |
 ~                                                               ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      </artwork>
</figure>
</t>

<t>
The fields of the TESLA EXT_AUTH header extension are:</t>

<t>"ASID" (Authentication Scheme IDentifier) field (4 bits):</t>
<t><list><t>
	The "ASID" identifies the source authentication scheme or protocol
	in use.
	The association between the "ASID" value and the actual authentication
	scheme is defined out-of-band, at session startup.
</t></list></t>

<t>"Type" field (4 bits):</t>
<t><list><t>
	The "Type" field identifies the type of TESLA information carried
	in this header extension.
	This specification defines the following types:
	<list style='symbols'> 
	<t>0: Bootstrap Information, sent by the sender periodically
		or after a direct time synchronization request;</t>
	<t>1: Standard Authentication Tag for the on-going key chain, sent by
		the sender along with a packet;</t>
	<t>2: Authentication Tag Without Key Disclosure, sent by
		the sender along with a packet;</t>
	<t>3: Authentication Tag with a New Key Chain Commitment,
		sent by the sender when approaching the end of a key chain;</t>
	<t>4: Authentication Tag with a Last Key of Old Chain Disclosure,
		sent by the sender some time after moving to a new key chain;</t>
<!--
	<t>5: compact (i.e., that contains the last byte of the interval index)
		authentication tag
		for the on-going key chain, sent by the sender along with a packet;</t>
	<t>6: compact (i.e., that contains the last byte of the interval index)
		authentication tag without any key disclosure, sent by the sender
		along with a packet;</t>
	<t>7: compact (i.e., that contains the last byte of the interval index)
		authentication tag with a new key chain commitment,
		sent by the sender when approaching the end of a key chain;</t>
	<t>8: compact (i.e., that contains the last byte of the interval index)
		authentication tag with a last key of old chain disclosure,
		sent by the sender some time after moving to a new key chain;</t>
-->
	<t>5: Direct Time Synchronization Request, sent by a NORM receiver.
		This type of message is invalid in case of an ALC session
		since ALC is restricted to unidirectional transmissions.
		Yet an external mechanism may provide the direct time
		synchronization functionality;</t>
	<t>6: Direct Time Synchronization Response, sent by a NORM sender.
		This type of message is invalid in case of an ALC session
		since ALC is restricted to unidirectional transmissions.
		Yet an external mechanism may provide the direct time
		synchronization functionality;</t>
	</list>
</t></list></t>

<t>"Content" field (variable length):</t>
<t><list><t>
	This is the TESLA information carried in the header extension, whose
	type is given by the "Type" field.
</t></list></t>

</section>

<section title="Use of Authentication Header Extensions"
	anchor='sec:auth_he_use'>
<!-- =================================== -->

<t>
Each packet sent by the session's sender MUST contain exactly one
TESLA EXT_AUTH header extension.
</t>

<t>
All receivers MUST recognize EXT_AUTH but MAY not be able to parse its content,
for instance because they do not support TESLA.
In that case these receivers MUST ignore the TESLA EXT_AUTH extensions.
In case of NORM, the packets sent by receivers MAY contain a direct
synchronization request but MUST NOT contain any of the other five
TESLA EXT_AUTH header extensions.
</t>

<section title="EXT_AUTH Header Extension of Type Bootstrap Information"
	anchor='sec:auth_he_use_bootstrap'>
<!-- =================================== -->

<t>
The "bootstrap information" TESLA EXT_AUTH (Type==0) MUST be sent in
a stand-alone control packet, rather than in a packet containing application data.
The reason for that is the large size of this bootstrap information.
By using stand-alone packets, the maximum payload size of data packets is only
affected by the (mandatory) authentication information header extension.
</t>

<t>
With ALC, the "bootstrap information" TESLA EXT_AUTH MUST be sent in a
control packet, i.e., containing no encoding symbol.
</t>

<t>
With NORM, the "bootstrap information" TESLA EXT_AUTH MUST be sent in a
NORM_CMD(APPLICATION) message.
</t>

<t>
<figure anchor='fig:bootstrap_with_1024b_sig'
	title="Example: Format of the bootstrap information message (Type 0),
		using SHA-256/1024 bit signatures, the default HMAC-SHA-256 and a Group MAC.">
      <preamble></preamble>
      <artwork>
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ---
|   HET (=1)    |    HEL (=46)  |  ASID |   0   | 0 |  0  |0|1|0|  ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|       d       |       2       |       2       |       2       |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|       1       |       3       |              128              |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|         0 (reserved)          |             T_int             |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|                                                               |  |
+                  T_0 (NTP timestamp format)                   +  | 5
|                                                               |  | 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
|                      N (Key Chain Length)                     |  | b
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | y
|                    Current Interval Index i                   |  | t
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  | e
|                                                               |  | s
+                                                               +  |
|                                                               |  |
+                 Current Key Chain Commitment                  +  |
|                          (20 bytes)                           |  |
+                                                               +  |
|                                                               |  |
+                                                               +  |
|                                                               |  v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ---
|                                                               |  ^ 1
+                                                               +  | 2
|                                                               |  | 8
.                                                               .  |
.                           Signature                           .  | b
.                          (128 bytes)                          .  | y
|                                                               |  | t
+                                                               +  | e
|                                                               |  v s
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  ---
|                           Group MAC                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      </artwork>
</figure>
</t>

<t>
For instance <xref target="fig:bootstrap_with_1024b_sig"/> shows the bootstrap information
message when using the HMAC-SHA-256 transform for the PRF, MAC, and Group MAC functions,
along with SHA-256/128 byte (1024 bit) key digital signatures (which also means that the signature
field is 128 byte long).
The TESLA EXT_AUTH header extension is then 184 byte long (i.e., 46 words of 32 bits).
</t>

</section>

<section title="EXT_AUTH Header Extension of Type Authentication Tag"
	anchor='sec:auth_he_use_auth_info'>
<!-- =================================== -->

<t>
The four "authentication tag" TESLA EXT_AUTH (Type 1, 2, 3, and 4)
MUST be attached to the ALC or NORM packet (data or control packet) that
they protect.
</t>

<t>
<figure anchor='fig:example_authentication_tag'
	title="Example: Format of the Standard Authentication Tag (Type 1), using the default HMAC-SHA-256.">
      <preamble></preamble>
      <artwork>
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   HET (=1)    |   HEL (=10)   |  ASID |   1   |   Reserved    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                i (Interval Index of K'_i)                     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 +                                                               +
 |                                                               |
 +                     Disclosed Key K_{i-d}                     +
 |                          (20 bytes)                           |
 +                                                               +
 |                                                               |
 +                                                               +
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 +                                                               +
 |                         MAC(K'_i, M)                          |
 +                          (16 bytes)                           +
 |                                                               |
 +                                                               +
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      </artwork>
</figure>
</t>

<t>
<figure anchor='fig:example_authentication_tag_wo_key_discl'
	title="Example: Format of the Authentication Tag Without Key Disclosure (Type 2),
	using the default HMAC-SHA-256.">
      <preamble></preamble>
      <artwork>
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   HET (=1)    |   HEL (=5)    |  ASID |   2   |   Reserved    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                i (Interval Index of K'_i)                     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 +                                                               +
 |                         MAC(K'_i, M)                          |
 +                          (16 bytes)                           +
 |                                                               |
 +                                                               +
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      </artwork>
</figure>
</t>

<t>
For instance, <xref target='fig:example_authentication_tag'/> and
<xref target='fig:example_authentication_tag_wo_key_discl'/>
show the format of the authentication tags, respectively with and without
the K_{i-d} key disclosure, when using the (default) HMAC-SHA-256 transform for the PRF
and MAC functions.
In this example, the Group MAC feature is not used.
</t>

</section>

<section title="EXT_AUTH Header Extension of Type Direct Time Synchronization Request"
	anchor='sec:auth_he_use_direct_synch_req'>
<!-- =================================== -->

<t>
With NORM, the "direct time synchronization request" TESLA EXT_AUTH (Type==7)
MUST be sent by a receiver in a NORM_CMD(APPLICATION) NORM packet.
</t>

<t>
With ALC, the "direct time synchronization request" TESLA EXT_AUTH cannot be
included in an ALC packet, since ALC is restricted to unidirectional
transmissions, from the session's sender to the receivers.
An external mechanism must be used with ALC for carrying direct time synchronization
requests to the session's sender.
</t>

<t>
In case of direct time synchronization, it is RECOMMENDED that the
receivers spread the transmission of direct time synchronization
requests over the time (<xref target="sec:intro_to_direct_time_sync"/>).
</t>

</section>

<section title="EXT_AUTH Header Extension of Type Direct Time Synchronization Response"
	anchor='sec:auth_he_use_direct_synch_resp'>
<!-- =================================== -->

<t>
With NORM, the "direct time synchronization response" TESLA EXT_AUTH (Type==8)
MUST be sent by the sender in a NORM_CMD(APPLICATION) message.
</t>

<t>
With ALC, the "direct time synchronization response" TESLA EXT_AUTH can be sent
in an ALC control packet (i.e., containing no encoding symbol) or through the 
external mechanism use to carry the direct time synchronization request.
</t>

</section>

</section>

</section><!-- -LCT or NORM integration- -->

<section title="Security Considerations">
<!-- ==================================== -->

<t>
<xref target="RFC4082"/> discusses the security of TESLA in general.
These considerations apply to the present specification, namely:
<list style='symbols'> 
	<t>great care must be taken to the timing aspects. In particular the D_t parameter
	is critical and must be correctly initialized;</t>

	<t>if the sender realizes that the key disclosure schedule is not
	appropriate, then the current session MUST be closed and a new one
	created. Indeed <xref target="sec:time_int_schedule"/> requires that
	these parameters be fixed during the whole session.
	</t>
<!--
	<t>if the key disclosure schedule is to be changed (e.g., because the sender
	realizes that the parameters do not meet the receiver requirements), then
	this change MUST NOT be announced in-line, within the session.
	Indeed, a receiver that missed the announcement would be vulnerable to
	attacks.
	Note that in the current specification, the parameters that define the
	key disclosure schedule MUST be fixed during the whole session
	(<xref target="sec:time_int_schedule"/>).
	</t>
-->

	<t>when the verifier that authenticates the incoming packets and the application
	that uses the data are two different components, there is a risk that an
	attacker located between these components inject faked data.
	Similarly, when the verifier and the secure timing system are two
	different components, there is a risk that an attacker located between
	these components inject faked timing information.
	For instance, when the verifier reads the local time by means of a
	dedicated system call (e.g., gettimeofday()), if an attacker controls
	the host, he may catch the system call and return a faked time information.
	</t>
</list> 
The current specification discusses additional aspects with more details.
</t>

<section title="Dealing With DoS Attacks">
<!-- =================================== -->

<t>
TESLA introduces new opportunities for an attacker to mount DoS attacks.
For instance an attacker can try to saturate the processing
capabilities of the receiver (faked packets are easy to create but checking
them requires to compute a MAC over the packet or sometimes check a digital
signature as with the bootstrap and direct time synchronization response messages).
An attacker can also try to saturate the receiver's memory (since authentication
is delayed and non-authenticated packets will accumulate), or to make the receiver
believe that a congestion has happened (since congestion control MUST be performed
before authenticating incoming packets, <xref target="sec:auth_received_pkts_guidelines"/>).
</t>

<t>
In order to mitigate these attacks, it is RECOMMENDED to use the Group MAC
scheme (<xref target="sec:group_auth_tag"/>).
No mitigation is possible if a group member acts as an attacker with Group MAC.
</t>

<t>
Generally, it is RECOMMENDED that the amount of memory used to store
incoming packets waiting to be authenticated be limited to a reasonable
value.
</t>

</section>

<section title="Dealing With Replay Attacks">
<!-- =================================== -->

<t>
Replay attacks, whereby an attacker stores a valid message and replays it later
on, can have significant impacts, depending on the message type.
Two levels of impacts must be distinguished:
<list style='symbols'> 
	<t> within the TESLA protocol, and</t>
	<t> within the ALC or NORM protocol.</t>
</list>
</t>

<section title="Impacts of Replay Attacks on TESLA">
<!-- =================================== -->

<t>
Replay attacks can impact the TESLA component itself.
We review here the potential impacts of such an attack depending on the TESLA message type:
<list style='symbols'> 
	<t> bootstrap information:
		since most parameters contained in a bootstrap information message
		are static, replay attacks have no consequences.
		The fact that the "i" and "K_i" fields can be updated in subsequent
		bootstrap information messages does not create a problem either,
		since all "i" and "K_i" fields sent remain valid.
		Finally, a receiver that successfully initialized its TESLA component
		MUST ignore the following messages (see <xref target="sec:recv_process_bootstrap"/>
		for an exception to this rule),
		which voids replay attacks, unless he missed all the commitments to a new
		key chain (e.g., after a long disconnection) (<xref target="sec:bootstrap_info"/>).
	</t>
	<t> direct time synchronization request:
		If the Group MAC scheme is used, an attacker that is not a member of
		the group can replay a packet and oblige the sender to respond, which
		requires to digitally sign the response, a time-consuming process.
		If the Group MAC scheme is not used, an attacker can anyway easily
		forge a request.
		In both cases, the attack will not compromise the TESLA component, but might
		create a DoS.
		If this is a concern, it is RECOMMENDED, when the Group MAC scheme is used,
		that the sender verify the "t_r" NTP timestamp contained in the request
		and respond only if this value is strictly larger than the previous one
		received from this receiver.
		When the Group MAC scheme is not used, this attack can be mitigated
		by limiting the number of requests per second that will be processed.
	</t>
	<t> direct time synchronization response:
		Upon receiving a response, a receiver who has no pending request
		MUST immediately drop the packet.
		If this receiver has previously issued a request, he first checks
		the Group MAC (if applicable), then the "t_r" field, to be sure
		it is a response to his request, and finally the digital signature.
		A replayed packet will be dropped during these verifications, without
		compromising the TESLA component.
	</t>
	<t> other messages, containing an authentication tag:
		Replaying a packet containing a TESLA authentication tag will never
		compromise the TESLA component itself (but perhaps the underlying
		ALC or NORM component, see below).
	</t>
</list>
To conclude, TESLA itself is robust in front of replay attacks.
</t>

</section>

<section title="Impacts of Replay Attacks on NORM">
<!-- =================================== -->

<t>
We review here the potential impacts of a replay attack on the NORM component.
Note that we do not consider here the protocols that could be used along with
NORM, for instance the congestion control protocols.
</t>

<t>
First, let us consider replay attacks within a given NORM session.
NORM defines a "sequence" field that can be used to protect against replay
attacks <xref target="RMT-PI-NORM"/> within a given NORM session.
This "sequence" field is a 16-bit value that is set by the message
originator (sender or receiver) as a monotonically increasing number
incremented with each NORM message transmitted.
It is RECOMMENDED that a receiver check this sequence field and drop messages considered
as replayed.
Similarly, it is RECOMMENDED that a sender check this sequence, for each known receiver,
and drop messages considered as replayed.
In both cases, checking this sequence field SHOULD be done before
TESLA processing of the packet: if the sequence field has not been
corrupted, the replay attack will immediately be identified, and
otherwise the packet will fail the TESLA authentication test.
This analysis shows that NORM itself is robust in front of replay attacks
within the same session.
</t>

<t>
Now let us consider replay attacks across several NORM sessions.
Since the key chain used in each session MUST differ, a packet replayed in a
subsequent session will be identified as unauthentic.
Therefore NORM is robust in front of replay attacks across different sessions.
</t>

</section>

<section title="Impacts of Replay Attacks on ALC">
<!-- =================================== -->

<t>
We review here the potential impacts of a replay attack on the ALC component.
Note that we do not consider here the protocols that could be used along with
ALC, for instance the layered or wave based congestion control protocols.
</t>
<t>
First, let us consider replay attacks within a given ALC session:
<list style='symbols'> 
	<t>Regular packets containing an authentication tag: a replayed message
	containing an encoding symbol will be detected once authenticated, thanks to
	the object/block/symbol identifiers, and will be silently discarded.
	This kind of replay attack is only penalizing in terms of memory and
	processing load, but does not compromise the ALC behavior.
	</t>
	<t>Control packets containing an authentication tag:
	ALC control packets, by definition, do not include any encoding symbol
	and therefore do not include any object/block/symbol identifier that would
	enable a receiver to identify duplicates.
	However, a sender has a very limited number of reasons to send control packets.
	More precisely:
	<list style='symbols'> 
		<t>At the end of the session, a "close session" (A flag) packet is sent.
		Replaying this packet has no impact since the receivers already left.</t>
		<t>Similarly, replaying a packet containing a "close object" (B flag)
		has no impact since this object is probably already marked as closed
		by the receiver.</t>
	</list>
	</t>
</list>
This analysis shows that ALC itself is robust in front of replay attacks
within the same session.
</t>

<t>
Now let us consider replay attacks across several ALC sessions.
Since the key chain used in each session MUST differ, a packet replayed in a
subsequent session will be identified as unauthentic.
Therefore ALC is robust in front of replay attacks across different sessions.
</t>

</section>

</section>

<section title="Security of the Back Channel">
<!-- =================================== -->

<t>
As specified in <xref target="scope"/>, this specification does not consider
the packets that may be sent by receivers, for instance NORM's feedback packets.
When a back channel is used, its security is critical to the global security,
and an appropriate security mechanism MUST be used.
<xref target="RMT-SIMPLE-AUTH"/> describes several techniques that can be used 
to that purpose.
However, the authentication and integrity verification of the packets sent by receivers
on the back channel, if any, is out of the scope of this document.
</t>

</section>

</section>

<section title="IANA Considerations" anchor="sec:iana">
<!-- ==================================== -->

<t>This document requires a IANA registration for the following attributes.
The registries are provided by <xref target="RFC4442"/> under the "Timed Efficient Stream
Loss-tolerant Authentication (TESLA) Parameters" registry <xref target="TESLA-REG"/>.
Following the policies outlined in <xref target="RFC4442"/>, the values in the range
up to 240 (including 240) for the following attributes are assigned after
expert review by the MSEC working group or its designated successor.
The values in the range from 241 to 255 are reserved for private use.
</t>

<t>Cryptographic Pseudo-Random Function, TESLA-PRF:
	All implementations MUST support HMAC-SHA-256 (default).</t>

       <texttable>
           <preamble></preamble>
           <ttcol align='center'>PRF name</ttcol>
           <ttcol align='center'>Value</ttcol>
           <c>HMAC-SHA-1</c>		<c>0</c>
           <c>HMAC-SHA-224</c>		<c>1</c>
           <c>HMAC-SHA-256 (default)</c><c>2</c>
           <c>HMAC-SHA-384</c>		<c>3</c>
           <c>HMAC-SHA-512</c>		<c>4</c>
       </texttable>

<t>Cryptographic Message Authentication Code (MAC) Function, TESLA-MAC:
	All implementations MUST support HMAC-SHA-256 (default).
	These MAC schemes are used both for the computing of regular
	MAC and the Group MAC (if applicable).</t>

       <texttable>
           <preamble></preamble>
           <ttcol align='center'>MAC name</ttcol>
           <ttcol align='center'>Value</ttcol>
           <c>HMAC-SHA-1</c>		<c>0</c>
           <c>HMAC-SHA-224</c>		<c>1</c>
           <c>HMAC-SHA-256 (default)</c><c>2</c>
           <c>HMAC-SHA-384</c>		<c>3</c>
           <c>HMAC-SHA-512</c>		<c>4</c>
       </texttable>

<t>Furthermore, this document requires IANA to create two new registries.
Here also, the values in the range up to 240 (including 240) for the following
attributes are assigned after expert review by the MSEC working group or its
designated successor.
The values in the range from 241 to 255 are reserved for private use.
</t>

<t>Signature Encoding Algorithm, TESLA-SIG-ALGO:
	All implementations MUST support RSASSA-PKCS1-v1_5 (default).</t>

       <texttable>
           <preamble></preamble>
           <ttcol align='center'>Signature Algorithm Name</ttcol>
           <ttcol align='center'>Value</ttcol>
           <c>INVALID</c>			<c>0</c>
           <c>RSASSA-PKCS1-v1_5 (default)</c>	<c>1</c>
           <c>RSASSA-PSS</c>			<c>2</c>
       </texttable>

<t>Signature Cryptographic Function, TESLA-SIG-CRYPTO-FUNC:
	All implementations MUST support SHA-256 (default).</t>

       <texttable>
           <preamble></preamble>
           <ttcol align='center'>Cryptographic Function Name</ttcol>
           <ttcol align='center'>Value</ttcol>
           <c>INVALID		</c><c>0</c>
           <c>SHA-1		</c><c>1</c>
           <c>SHA-224		</c><c>2</c>
           <c>SHA-256 (default)	</c><c>3</c>
           <c>SHA-384		</c><c>4</c>
           <c>SHA-512		</c><c>5</c>
       </texttable>

</section>

<section title="Acknowledgments">
<!-- ==================================== -->

<t>
The authors are grateful to Yaron Sheffer, Brian Weis, Ramu Panayappan, Ran Canetti,
David L. Mills, Brian Adamson and Lionel Giraud for their valuable comments while
preparing this document.
The authors are also grateful to Brian Weis for the digital signature details.
</t>
</section>

    </middle>

    <back>

<references title="Normative References">
<!-- ==================================== -->

      <reference anchor="RFC2119">
	<front>
	  <title>Key words for use in RFCs to Indicate Requirement Levels</title>
	  <author initials="S." surname="Bradner">
	    <organization />
	  </author>
	  <date month="March" year="1997" />
	</front>
	<seriesInfo name="RFC" value="2119" />
	<seriesInfo name="BCP" value="14" />
      </reference>

      <reference anchor="RFC4082">
        <front>
          <title>Timed Efficient Stream Loss-Tolerant Authentication (TESLA):
          Multicast Source Authentication Transform Introduction
          </title>
          <author initials="A." surname="Perrig" fullname="A. Perrig">
            <organization/></author>
          <author initials="D." surname="Song" fullname="D. Song">
            <organization/></author>
          <author initials="R." surname="Canetti" fullname="R. Canetti">
            <organization/></author>
          <author initials="J.D." surname="Tygar" fullname="J.D. Tygar">
            <organization/></author>
          <author initials="B." surname="Briscoe" fullname="B. Briscoe">
            <organization/></author>
          <date year="2005" month="June"/>
        </front>
        <seriesInfo name="RFC" value="4082"/>
        <format type="TXT" octets="54316" target="ftp://ftp.isi.edu/in-notes/rfc4082.txt"/>
      </reference>

<!--
      <reference anchor='RFC3450'>
        <front>
          <title>Asynchronous Layered Coding (ALC) Protocol Instantiation</title>
          <author initials='M.' surname='Luby' fullname='M. Luby'>
            <organization /></author>
          <author initials='J.' surname='Gemmell' fullname='J. Gemmell'>
            <organization /></author>
          <author initials='L.' surname='Vicisano' fullname='L. Vicisano'>
            <organization /></author>
          <author initials='L.' surname='Rizzo' fullname='L. Rizzo'>
            <organization /></author>
          <author initials='J.' surname='Crowcroft' fullname='J. Crowcroft'>
            <organization /></author>
          <date year='2002' month='December' />
        </front>
        <seriesInfo name='RFC' value='3450' />
        <format type='TXT' octets='86022' target='ftp://ftp.isi.edu/in-notes/rfc3450.txt' />
      </reference>

      <reference anchor="RFC3451">
        <front>
          <title>Layered Coding Transport (LCT) Building Block</title>
          <author initials="M." surname="Luby" fullname="M. Luby">
            <organization/></author>
          <author initials="J." surname="Gemmell" fullname="J. Gemmell">
            <organization/></author>
          <author initials="L." surname="Vicisano" fullname="L. Vicisano">
            <organization/></author>
          <author initials="L." surname="Rizzo" fullname="L. Rizzo">
            <organization/></author>
          <author initials="M." surname="Handley" fullname="M. Handley">
            <organization/></author>
          <author initials="J." surname="Crowcroft" fullname="J. Crowcroft">
            <organization/></author>
          <date year="2002" month="December"/>
        </front>
        <seriesInfo name="RFC" value="3451"/>
        <format type="TXT" octets="72594" target="ftp://ftp.isi.edu/in-notes/rfc3451.txt"/>
      </reference>
-->

<reference anchor="RMT-PI-ALC">
	<front>
		<title>Asynchronous Layered Coding (ALC) Protocol Instantiation</title>
		<author initials='M.' surname='Luby'>
			<organization />
		</author>
		<author initials="M." surname="Watson">
			<organization/>
		</author>
		<author initials='L.' surname='Vicisano'>
			<organization />
		</author>
		<date month="September" year="2009"/>
	</front>
	<seriesInfo name="" value="draft-ietf-rmt-pi-alc-revised-08.txt (work in progress)"/>
</reference>

<reference anchor="RMT-BB-LCT">
	<front>
		<title>Layered Coding Transport (LCT) Building Block</title>
		<author initials='M.' surname='Luby'>
			<organization />
		</author>
		<author initials="M." surname="Watson">
			<organization/>
		</author>
		<author initials='L.' surname='Vicisano'>
			<organization />
		</author>
		<date month="August" year="2009"/>
	</front>
	<seriesInfo name="" value="draft-ietf-rmt-bb-lct-revised-11.txt (work in progress)"/>
</reference>

<!--
      <reference anchor="RFC3926">
        <front>
          <title>FLUTE - File Delivery over Unidirectional Transport</title>
          <author initials="T." surname="Paila" fullname="T. Paila">
            <organization/></author>
          <author initials="M." surname="Luby" fullname="M. Luby">
            <organization/></author>
          <author initials="R." surname="Lehtonen" fullname="R. Lehtonen">
            <organization/></author>
          <author initials="V." surname="Roca" fullname="V. Roca">
            <organization/></author>
          <author initials="R." surname="Walsh" fullname="R. Walsh">
            <organization/></author>
          <date year="2004" month="October"/>
        </front>
        <seriesInfo name="RFC" value="3926"/>
        <format type="TXT" octets="81224" target="ftp://ftp.isi.edu/in-notes/rfc3926.txt"/>
      </reference>

      <reference anchor="RFC3940">
        <front>
          <title>Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol</title>
          <author initials="B." surname="Adamson" fullname="B. Adamson">
            <organization/></author>
          <author initials="C." surname="Bormann" fullname="C. Bormann">
            <organization/></author>
          <author initials="M." surname="Handley" fullname="M. Handley">
            <organization/></author>
          <author initials="J." surname="Macker" fullname="J. Macker">
            <organization/></author>
          <date year="2004" month="November"/>
        </front>
        <seriesInfo name="RFC" value="3940"/>
        <format type="TXT" octets="220549" target="ftp://ftp.isi.edu/in-notes/rfc3940.txt"/>
      </reference>
-->

<reference anchor="RMT-PI-NORM">
	<front>
		<title>Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol</title>
		<author initials="B." surname="Adamson" fullname="B. Adamson">
			<organization/></author>
		<author initials="C." surname="Bormann" fullname="C. Bormann">
			<organization/></author>
		<author initials="M." surname="Handley" fullname="M. Handley">
			<organization/></author>
		<author initials="J." surname="Macker" fullname="J. Macker">
			<organization/></author>
		<date year="2009" month="June"/>
	</front>
	<seriesInfo name="" value="draft-ietf-rmt-pi-norm-revised-13.txt (work in progress)"/>
</reference>

<!--
      <reference anchor="RFC3941">
        <front>
          <title>Negative-Acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Building Blocks</title>
          <author initials="B." surname="Adamson" fullname="B. Adamson">
            <organization/></author>
          <author initials="C." surname="Bormann" fullname="C. Bormann">
            <organization/></author>
          <author initials="M." surname="Handley" fullname="M. Handley">
            <organization/></author>
          <author initials="J." surname="Macker" fullname="J. Macker">
            <organization/></author>
          <date year="2004" month="November"/>
        </front>
        <seriesInfo name="RFC" value="3941"/>
        <format type="TXT" octets="92785" target="ftp://ftp.isi.edu/in-notes/rfc3941.txt"/>
      </reference>

-->
<reference anchor="TESLA-REG">
	<front>
		<title>TESLA Parameters IANA Registry</title>
		<author><organization/></author>
		<date />
	</front>
	<seriesInfo name="" value="http://www.iana.org/assignments/tesla-parameters/"/>
</reference>

</references>

<references title="Informative References">
<!-- ==================================== -->

      <reference anchor="Perrig04">
	<front>
	  <title>Secure Broadcast Communication in Wired and Wireless Networks</title>
	  <author initials="A." surname="Perrig" fullname="A. Perrig">
	    <organization /></author>
          <author initials="J.D." surname="Tygar" fullname="J.D. Tygar">
            <organization/></author>
	  <date year="2004" />
	</front>
        <seriesInfo name="Kluwer Academic Publishers" value="ISBN 0-7923-7650-1"/>
      </reference>

      <reference anchor="RFC4442">
        <front>
          <title>Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication (TESLA)</title>
          <author initials="S." surname="Fries" fullname="S. Fries">
            <organization/>
          </author>
          <author initials="H." surname="Tschofenig" fullname="H. Tschofenig">
            <organization/>
          </author>
          <date month="March" year="2006"/>
        </front>
        <seriesInfo name="RFC" value="4442"/>
        <format type="TXT" octets="37345" target="ftp://ftp.isi.edu/in-notes/rfc4442.txt"/>
      </reference>

      <reference anchor="RFC4383">
        <front>
          <title>
          The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)
          </title>
          <author initials="M." surname="Baugher" fullname="M. Baugher"><organization/></author>
          <author initials="E." surname="Carrara" fullname="E. Carrara"><organization/></author>
          <date year="2006" month="February"/>
        </front>
        <seriesInfo name="RFC" value="4383"/>
        <format type="TXT" octets="41766" target="ftp://ftp.isi.edu/in-notes/rfc4383.txt"/>
      </reference>

      <reference anchor="RFC3711">
        <front>
          <title>The Secure Real-time Transport Protocol (SRTP)</title>
          <author initials="M." surname="Baugher" fullname="M. Baugher"><organization/></author>
          <author initials="D." surname="McGrew" fullname="D. McGrew"><organization/></author>
          <author initials="M." surname="Naslund" fullname="M. Naslund"><organization/></author>
          <author initials="E." surname="Carrara" fullname="E. Carrara"><organization/></author>
          <author initials="K." surname="Norrman" fullname="K. Norrman"><organization/></author>
          <date year="2004" month="March"/>
      </front>
      <seriesInfo name="RFC" value="3711"/>
      <format type="TXT" octets="134270" target="ftp://ftp.isi.edu/in-notes/rfc3711.txt"/>
      </reference>

      <reference anchor="RMT-SIMPLE-AUTH">
        <front>
          <title>Simple Authentication Schemes for the ALC and NORM Protocols</title>
          <author initials='V.' surname='Roca'> <organization /></author>
          <date month="March" year="2009"/>
        </front>
        <seriesInfo name="" value="draft-ietf-rmt-simple-auth-for-alc-norm-01.txt (work in progress)"/>
      </reference>

      <reference anchor="RMT-FLUTE">
        <front>
          <title>FLUTE - File Delivery over Unidirectional Transport</title>
          <author initials='T.' surname='Paila'> <organization /></author>
          <author initials="R." surname="Walsh"> <organization/></author>
          <author initials='M.' surname='Luby'> <organization /></author>
          <author initials='R.' surname='Lehtonen'> <organization /></author>
          <author initials='V.' surname='Roca'> <organization /></author>
          <date month="August" year="2009"/>
        </front>
        <seriesInfo name="" value="draft-ietf-rmt-flute-revised-07.txt (work in progress)"/>
      </reference>

      <reference anchor="RFC4359">
        <front>
          <title>
          The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH)
          </title>
          <author initials="B." surname="Weis" fullname="B. Weis"><organization/></author>
          <date year="2006" month="January"/>
        </front>
        <seriesInfo name="RFC" value="4359"/>
        <format type="TXT" octets="26989" target="ftp://ftp.isi.edu/in-notes/rfc4359.txt"/>
      </reference>

      <?rfc include='reference.RFC.3447'?>

      <reference anchor="NTP-NTPv4">
        <front>
          <title>The Network Time Protocol Version 4 Protocol Specification</title>
          <author initials="J." surname="Burbank" fullname="Jack Burbank"><organization/></author>
          <author initials="W." surname="Kasch" fullname="W. Kasch"><organization/></author>
          <author initials="J." surname="Martin" fullname="J. Martin"><organization/></author>
          <author initials="D." surname="Mills" fullname="David L. Mills"><organization/></author>
          <date month="September" year="2008"/>
        </front>
        <seriesInfo name="" value="draft-ietf-ntp-ntpv4-proto-11.txt (work in progress)"/>
      </reference>

      <reference anchor="RFC1305">
        <front>
          <title>Network Time Protocol (Version 3) Specification, Implementation</title>
          <author initials="D." surname="Mills" fullname="David L. Mills">
            <organization />
          </author>
          <date year="1992" month="March"/>
        </front>
        <seriesInfo name="RFC" value="1305"/>
        <format type="TXT" octets="307085" target="ftp://ftp.isi.edu/in-notes/rfc1305.txt"/>
        <format type="PDF" octets="442493" target="ftp://ftp.isi.edu/in-notes/rfc1305.pdf"/>
      </reference>

      <reference anchor="RFC4330">
        <front>
          <title>Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI</title>
          <author initials="D." surname="Mills" fullname="David L. Mills">
            <organization/>
          </author>
          <date year="2006" month="January"/>
        </front>
        <seriesInfo name="RFC" value="4330"/>
	<format type="TXT" octets="67930" target="ftp://ftp.isi.edu/in-notes/rfc4330.txt"/>
      </reference>

      <reference anchor="RFC2104">
        <front>
          <title abbrev="HMAC">HMAC: Keyed-Hashing for Message Authentication</title>
          <author initials="H." surname="Krawczyk" fullname="Hugo Krawczyk">
            <organization>IBM, T.J. Watson Research Center</organization>
          </author>
          <author initials="M." surname="Bellare" fullname="Mihir Bellare">
            <organization>University of California at San Diego, Dept of Computer Science and Engineering</organization>
          </author>
          <author initials="R." surname="Canetti" fullname="Ran Canetti">
            <organization>IBM T.J. Watson Research Center</organization>
          </author>
          <date year="1997" month="February"/>
        </front>
        <seriesInfo name="RFC" value="2104"/>
        <format type="TXT" octets="22297" target="ftp://ftp.isi.edu/in-notes/rfc2104.txt"/>
      </reference>

    </references>

    </back>

</rfc>