<pre>Internet Engineering Task Force (IETF)                           V. Roca
Request for Comments: 6584                                         INRIA
Category: Standards Track                                     April 2012
ISSN: 2070-1721


Simple Authentication Schemes for the Asynchronous Layered Coding (ALC)
         and NACK-Oriented Reliable Multicast (NORM) Protocols

Abstract

   This document introduces four schemes that provide per-packet
   authentication, integrity, and anti-replay services in the context of
   the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable
   Multicast (NORM) protocols.  The first scheme is based on RSA Digital
   Signatures.  The second scheme relies on the Elliptic Curve Digital
   Signature Algorithm (ECDSA).  The third scheme relies on a Group-
   keyed Message Authentication Code (MAC).  Finally, the fourth scheme
   merges the Digital Signature and group schemes.  These schemes have
   different target use cases, and they do not all provide the same
   service.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in <a href="./rfc5741#section-2">Section&nbsp;2 of RFC 5741</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="http://www.rfc-editor.org/info/rfc6584">http://www.rfc-editor.org/info/rfc6584</a>.
















<span class="grey">Roca                         Standards Track                    [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6584">RFC 6584</a>         Simple Authentication for ALC and NORM       April 2012</span>


Copyright Notice

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

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.





































<span class="grey">Roca                         Standards Track                    [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6584">RFC 6584</a>         Simple Authentication for ALC and NORM       April 2012</span>


Table of Contents

   <a href="#section-1">1</a>. Introduction ....................................................<a href="#page-4">4</a>
      <a href="#section-1.1">1.1</a>. Scope of This Document .....................................<a href="#page-6">6</a>
      <a href="#section-1.2">1.2</a>. Terminology, Notations, and Definitions ....................<a href="#page-6">6</a>
   <a href="#section-2">2</a>. Authentication Scheme Identification with the ASID Field ........<a href="#page-7">7</a>
   <a href="#section-3">3</a>. RSA Digital Signature Scheme ....................................<a href="#page-8">8</a>
      <a href="#section-3.1">3.1</a>. Authentication Header Extension Format .....................<a href="#page-8">8</a>
      <a href="#section-3.2">3.2</a>. Parameters ................................................<a href="#page-10">10</a>
      <a href="#section-3.3">3.3</a>. Processing ................................................<a href="#page-11">11</a>
           <a href="#section-3.3.1">3.3.1</a>. Signature Processing ...............................<a href="#page-11">11</a>
           <a href="#section-3.3.2">3.3.2</a>. Anti-Replay Processing .............................<a href="#page-12">12</a>
      <a href="#section-3.4">3.4</a>. In Practice ...............................................<a href="#page-13">13</a>
   <a href="#section-4">4</a>. Elliptic Curve Digital Signature Scheme ........................<a href="#page-14">14</a>
      <a href="#section-4.1">4.1</a>. Authentication Header Extension Format ....................<a href="#page-14">14</a>
      <a href="#section-4.2">4.2</a>. Parameters ................................................<a href="#page-15">15</a>
      <a href="#section-4.3">4.3</a>. Processing ................................................<a href="#page-15">15</a>
           <a href="#section-4.3.1">4.3.1</a>. Signature Processing ...............................<a href="#page-15">15</a>
           <a href="#section-4.3.2">4.3.2</a>. Anti-Replay Processing .............................<a href="#page-16">16</a>
      <a href="#section-4.4">4.4</a>. In Practice ...............................................<a href="#page-16">16</a>
   <a href="#section-5">5</a>. Group-Keyed Message Authentication Code (MAC) Scheme ...........<a href="#page-17">17</a>
      <a href="#section-5.1">5.1</a>. Authentication Header Extension Format ....................<a href="#page-17">17</a>
      <a href="#section-5.2">5.2</a>. Parameters ................................................<a href="#page-19">19</a>
      <a href="#section-5.3">5.3</a>. Processing ................................................<a href="#page-20">20</a>
           <a href="#section-5.3.1">5.3.1</a>. Signature Processing ...............................<a href="#page-20">20</a>
           <a href="#section-5.3.2">5.3.2</a>. Anti-Replay Processing .............................<a href="#page-20">20</a>
      <a href="#section-5.4">5.4</a>. In Practice ...............................................<a href="#page-20">20</a>
   6. Combined Use of the RSA/ECC Digital Signatures and
      Group-Keyed MAC Schemes ........................................<a href="#page-21">21</a>
      <a href="#section-6.1">6.1</a>. Authentication Header Extension Format ....................<a href="#page-21">21</a>
      <a href="#section-6.2">6.2</a>. Parameters ................................................<a href="#page-23">23</a>
      <a href="#section-6.3">6.3</a>. Processing ................................................<a href="#page-23">23</a>
           <a href="#section-6.3.1">6.3.1</a>. Signature Processing ...............................<a href="#page-23">23</a>
           <a href="#section-6.3.2">6.3.2</a>. Anti-Replay Processing .............................<a href="#page-24">24</a>
      <a href="#section-6.4">6.4</a>. In Practice ...............................................<a href="#page-24">24</a>
   <a href="#section-7">7</a>. Security Considerations ........................................<a href="#page-25">25</a>
      <a href="#section-7.1">7.1</a>. Dealing with DoS Attacks ..................................<a href="#page-25">25</a>
      <a href="#section-7.2">7.2</a>. Dealing with Replay Attacks ...............................<a href="#page-26">26</a>
           7.2.1. Impacts of Replay Attacks on the Simple
                  Authentication Schemes .............................<a href="#page-26">26</a>
           <a href="#section-7.2.2">7.2.2</a>. Impacts of Replay Attacks on NORM ..................<a href="#page-26">26</a>
           <a href="#section-7.2.3">7.2.3</a>. Impacts of Replay Attacks on ALC ...................<a href="#page-27">27</a>
      <a href="#section-7.3">7.3</a>. Dealing with Attacks on the Parameters Sent Out-of-Band ...<a href="#page-28">28</a>
   <a href="#section-8">8</a>. Acknowledgments ................................................<a href="#page-28">28</a>
   <a href="#section-9">9</a>. References .....................................................<a href="#page-28">28</a>
      <a href="#section-9.1">9.1</a>. Normative References ......................................<a href="#page-28">28</a>
      <a href="#section-9.2">9.2</a>. Informative References ....................................<a href="#page-29">29</a>




<span class="grey">Roca                         Standards Track                    [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6584">RFC 6584</a>         Simple Authentication for ALC and NORM       April 2012</span>


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   Many applications using multicast and broadcast communications
   require that each receiver be able to authenticate the source of any
   packet it receives, to check its integrity.  For instance, ALC
   [<a href="./rfc5775" title="&quot;Asynchronous Layered Coding (ALC) Protocol Instantiation&quot;">RFC5775</a>] and NORM [<a href="./rfc5740" title="&quot;NACK-Oriented Reliable Multicast (NORM) Transport Protocol&quot;">RFC5740</a>] are two Content Delivery Protocols
   (CDPs) designed to reliably transfer objects (e.g., files) between a
   session's sender and several receivers.

   The NORM protocol is based on bidirectional transmissions.  With
   NORM, each receiver acknowledges data received or, in the case of
   packet erasures, asks for retransmissions.  On the contrary, the ALC
   protocol defines unidirectional transmissions.  With ALC, reliability
   can be achieved by means of cyclic transmissions of the content
   within a carousel, or by the use of proactive Forward Error
   Correction (FEC) codes, or by the joint use of these mechanisms.
   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 the application level, on top of an erasure channel
   (e.g., the Internet) where packets can be lost (erased) during the
   transmission.

   With these CDPs, an attacker might impersonate the ALC or NORM
   session sender and inject forged packets to the receivers, thereby
   corrupting the objects reconstructed by the receivers.  An attacker
   might also impersonate a NORM session receiver and inject forged
   feedback packets to the NORM sender.

   In the case of group communications, several solutions exist to
   provide the receiver some guaranties on the integrity of the packets
   it receives and on the identity of the sender of these packets.
   These solutions have different features that make them more or less
   suited to a given use case:

   o  Digital Signatures [<a href="./rfc4359" title="&quot;The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH)&quot;">RFC4359</a>] (see Sections <a href="#section-3">3</a> and <a href="#section-4">4</a> of this
      document): This scheme is well suited to low data rate flows, when
      a packet sender authentication and packet integrity service is
      needed.  However, Digital Signatures based on RSA asymmetric
      cryptography are limited by high computational costs and high
      transmission overheads.  The use of ECC (Elliptic Curve
      Cryptography) [<a href="./rfc6090" title="&quot;Fundamental Elliptic Curve Cryptography Algorithms&quot;">RFC6090</a>] significantly relaxes these constraints.
      For instance, the following key lengths provide equivalent
      security: a 1024-bit RSA key versus a 160-bit ECC key, or a
      2048-bit RSA key versus a 224-bit ECC key.  However, RSA puts more
      load on the signer but much less load on the verifier, whereas ECC
      puts more similar load on both; hence, with many verifiers, more
      CPU is consumed overall.



<span class="grey">Roca                         Standards Track                    [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6584">RFC 6584</a>         Simple Authentication for ALC and NORM       April 2012</span>


   o  Group-keyed Message Authentication Codes (MACs) (see <a href="#section-5">Section 5</a>):
      This scheme is well suited to high data rate flows, when
      transmission overheads must be minimized.  However, this scheme
      cannot protect against attacks coming from inside the group, where
      a group member impersonates the sender and sends forged messages
      to other receivers.

   o  TESLA (Timed Efficient Stream Loss-tolerant Authentication)
      [<a href="./rfc4082" title="&quot;Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction&quot;">RFC4082</a>] [<a href="./rfc5776" title="&quot;Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols&quot;">RFC5776</a>]: This scheme is well suited to high data rate
      flows, when transmission overheads must be minimized, and when a
      packet sender authentication and packet integrity service is
      needed.  The price is an increased complexity -- in particular,
      the need to loosely synchronize the receivers and the sender -- as
      well as the need to wait for the key to be disclosed before being
      able to authenticate a packet (i.e., the authentication check is
      delayed).

   The following table summarizes the pros and cons of each
   authentication/integrity scheme used at the application/transport
   level (where "-" means con, "0" means neutral, and "+" means pro):

   +-----------------+-------------+-------------+-------------+-------+
   |                 | RSA Digital | ECC Digital | Group-Keyed | TESLA |
   |                 |  Signature  |  Signature  |     MAC     |       |
   +-----------------+-------------+-------------+-------------+-------+
   | Sender auth and |     Yes     |     Yes     |  No (group  |  Yes  |
   | packet          |             |             |  security)  |       |
   | integrity       |             |             |             |       |
   | Non-delayed     |     Yes     |     Yes     |     Yes     |   No  |
   | authentication  |             |             |             |       |
   | Anti-replay     |     Opt     |     Opt     |     Opt     |   No  |
   | protection      |             |             |             |       |
   | Processing load |      -      |  sender: -, |      +      |   +   |
   |                 |             |   recv: 0   |             |       |
   | Transmission    |      -      |      0      |      +      |   +   |
   | overhead        |             |             |             |       |
   | Complexity      |      +      |      +      |      +      |   -   |
   +-----------------+-------------+-------------+-------------+-------+

   Several authentication schemes MAY be used in the same ALC or NORM
   session, even on the same communication path.  This is made possible
   through a dedicated identifier, the "ASID" (Authentication Scheme
   IDentifier), that is present in each HET=1 (EXT_AUTH) header
   extension and that tells a receiver how to interpret this HET=1
   header extension.  This is discussed in <a href="#section-2">Section 2</a>.






<span class="grey">Roca                         Standards Track                    [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6584">RFC 6584</a>         Simple Authentication for ALC and NORM       April 2012</span>


   All the applications built on top of ALC and NORM directly benefit
   from the source authentication and packet integrity services defined
   in this document.  For instance, this is the case of the File
   Delivery over Unidirectional Transport (FLUTE) application
   [<a href="#ref-RMT-FLUTE" title="&quot;FLUTE - File Delivery over Unidirectional Transport&quot;">RMT-FLUTE</a>], which is built on top of ALC.

   The current specification assumes that several parameters (like
   keying material) are communicated out-of-band, sometimes securely,
   between the sender and the receivers.  This is detailed in
   Sections <a href="#section-3.2">3.2</a>, <a href="#section-4.2">4.2</a>, <a href="#section-5.2">5.2</a>, and <a href="#section-6.2">6.2</a>.

<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>.  Scope of This Document</span>

   [<a id="ref-RFC5776">RFC5776</a>] explains how to use TESLA in the context of the ALC and
   NORM protocols.

   The current document specifies the use of the Digital Signature based
   on RSA asymmetric cryptography, the Elliptic Curve Digital Signature
   Algorithm (ECDSA), and Group-keyed MAC schemes.  The current document
   also specifies the joint use of Digital Signature and Group-keyed MAC
   schemes.

   Unlike the TESLA scheme, this specification considers the
   authentication/integrity of the packets generated by the session's
   sender as well as those generated by the receivers (NORM).

<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>.  Terminology, Notations, and Definitions</span>

   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 [<a href="./rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>].

   The following notations and definitions are used throughout this
   document:

   o  MAC is the Message Authentication Code;

   o  HMAC is the Keyed-Hash Message Authentication Code;

   o  "sender" denotes the sender of a packet that needs the
      authentication/integrity check service.  It can be an ALC or NORM
      session sender, or a NORM session receiver in the case of feedback
      traffic;








<span class="grey">Roca                         Standards Track                    [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6584">RFC 6584</a>         Simple Authentication for ALC and NORM       April 2012</span>


   o  "receiver" denotes the receiver of a packet that needs the
      authentication/integrity check service.  It can be an ALC or NORM
      session receiver, or a NORM session sender in the case of feedback
      traffic;

   o  "ASID" is the Authentication Scheme IDentifier.

   Key definitions for Digital Signatures are as follows:

   o  The public key is used by a receiver to check a packet's
      signature.  This key MUST be communicated to all receivers before
      starting the session;

   o  The private key is used by a sender to generate a packet's
      signature;

   o  The private key and public key length are expressed in bits.  For
      security considerations [<a href="./rfc5751" title="&quot;Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification&quot;">RFC5751</a>], when using RSA, RSASSA-PSS, and
      Digital Signature Algorithm (DSA) signatures, key sizes of length
      strictly inferior to 1024 bits SHOULD NOT be used.  Key sizes of
      length between 1024 and 2048 bits inclusive SHOULD be used.  Key
      sizes of length strictly superior to 2048 bits MAY be used.

   Key definitions for Group-keyed MAC are as follows:

   o  The shared group key is used by the senders and the receivers.
      This key MUST be communicated to all group members,
      confidentially, before starting the session;

   o  The group key length is expressed in bits;

   o  n_m is the length of the truncated output of the MAC [<a href="./rfc2104" title="&quot;HMAC: Keyed- Hashing for Message Authentication&quot;">RFC2104</a>].
      Only the n_m leftmost bits (most significant bits) of the MAC
      output are kept.

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Authentication Scheme Identification with the ASID Field</span>

   As mentioned in <a href="#section-1">Section 1</a>, several authentication schemes MAY be used
   in the same ALC or NORM session, even on the same communication path
   (i.e., from a sender to a receiver, or vice versa).  All the schemes
   mentioned in <a href="#section-1">Section 1</a> (some of which are specified in this document)
   use the same HET=1 (EXT_AUTH) Authentication Header extension
   mechanism defined in [<a href="./rfc5651" title="&quot;Layered Coding Transport (LCT) Building Block&quot;">RFC5651</a>].  Therefore, the same 4-bit ASID field
   has been reserved in all the specifications (see Sections <a href="#section-3.1">3.1</a>, <a href="#section-4.1">4.1</a>,
   5.1, and 6.1, as well as <a href="./rfc5776#section-5.1">Section&nbsp;5.1 of [RFC5776]</a>).  For a given ALC
   or NORM session, the ASID value contained in an incoming packet
   enables a receiver to differentiate the actual use and format of the
   contents of the HET=1 (EXT_AUTH) header extension.



<span class="grey">Roca                         Standards Track                    [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6584">RFC 6584</a>         Simple Authentication for ALC and NORM       April 2012</span>


   The association between the ASID value and the actual authentication
   scheme of a given ALC or NORM session is defined at session startup
   and communicated to all the session members by an out-of-band
   mechanism.  This association is per ALC or NORM session, and
   different sessions MAY reuse the same ASID values for different
   authentication schemes.

   With ALC, the ASID value is scoped by the {sender IP address;
   Transport Session Identifier (TSI)} tuple [<a href="./rfc5651" title="&quot;Layered Coding Transport (LCT) Building Block&quot;">RFC5651</a>] that fully
   identifies an ALC session.  Since [<a href="./rfc5651" title="&quot;Layered Coding Transport (LCT) Building Block&quot;">RFC5651</a>] requires that "the TSI
   MUST be unique among all sessions served by the sender during the
   period when the session is active, and for a large period of time
   preceding and following when the session is active", there is no risk
   of confusion between different sessions.  This is in line with
   <a href="#section-7.2.3">Section 7.2.3</a>.

   With NORM, there is no session identifier within NORM packets.
   Therefore, depending on whether an Any Source Multicast (ASM) or
   Source Specific Multicast (SSM) group communication is used, the ASID
   value is scoped either by the {destination multicast address;
   destination port number} or {source IP address; destination multicast
   address; destination port number} tuple that fully identifies a NORM
   session [<a href="./rfc5740" title="&quot;NACK-Oriented Reliable Multicast (NORM) Transport Protocol&quot;">RFC5740</a>].  Care should be taken that the above tuples remain
   unique, within a given scope and for a sufficient period of time
   preceding, during, and following when the session is active, to avoid
   confusion between different sessions.  However, this is a
   recommendation for NORM sessions, rather than something specific to
   an authentication scheme.  Note also that the ASID value is not
   scoped by the {source_id; instance_id} tuple, which uniquely
   identifies a host's participation in a NORM session, rather than the
   session itself (<a href="#section-7.2.2">Section 7.2.2</a>).

   In any case, because this ASID field is 4 bits long, there is a
   maximum of 16 authentication schemes per ALC or NORM session.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  RSA Digital Signature Scheme</span>

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  Authentication Header Extension Format</span>

   The integration of Digital Signatures is similar in ALC and NORM and
   relies on the header extension mechanism defined in both protocols.
   More precisely, this document details the HET=1 (EXT_AUTH) header
   extension defined in [<a href="./rfc5651" title="&quot;Layered Coding Transport (LCT) Building Block&quot;">RFC5651</a>].








<span class="grey">Roca                         Standards Track                    [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6584">RFC 6584</a>         Simple Authentication for ALC and NORM       April 2012</span>


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

    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 | rsvd|A|               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R+               +
   ~                  anti-replay Sequence Number (SN)             ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                                                               ~
   |                           Signature                           |
   +                                               +-+-+-+-+-+-+-+-+
   |                                               |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 1: Format of the Digital Signature EXT_AUTH Header Extension

   The fields of the Digital Signature EXT_AUTH header extension are as
   follows:

   ASID (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.

   rsvd (Reserved) (3 bits):

      This is a reserved field that MUST be set to zero and ignored by
      receivers.

   AR (anti-replay) (1 bit):

      The AR field, when set to 0, indicates that the anti-replay
      service is not used.  When set to 1, it indicates that the
      anti-replay service is used.

   SN (Sequence Number) (8 or 40 bits):

      The SN field contains an optional Sequence Number.  When AR = 0,
      this is an 8-bit field that MUST be set to zero.  No anti-replay
      mechanism is used in that case.  When AR = 1, this is a 40-bit
      field (32 bits + 8 bits), and all of the 40 bits MUST be
      considered by the anti-replay mechanism.





<span class="grey">Roca                         Standards Track                    [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6584">RFC 6584</a>         Simple Authentication for ALC and NORM       April 2012</span>


   Signature (variable size, multiple of 32 bits):

      The Signature field contains a Digital Signature of the message.
      If need be, this field is padded (with 0) up to a multiple of
      32 bits.

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  Parameters</span>

   Several parameters MUST be initialized by an out-of-band mechanism.
   The sender or group controller

   o  MUST communicate its public key, for each receiver to be able to
      verify the signature of the packets received.  For security
      reasons [<a href="./rfc5751" title="&quot;Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification&quot;">RFC5751</a>], the use of key sizes between 1024 and 2048 bits
      inclusive is RECOMMENDED.  Key sizes inferior to 1024 bits SHOULD
      NOT be used.  Key sizes above 2048 bits MAY be used.  As a side
      effect, the receivers also know the key length and the signature
      length, the two parameters being equal;

   o  MAY communicate a certificate (which also means that a PKI has
      been set up), for each receiver to be able to check the sender's
      public key;

   o  MUST communicate the signature-encoding algorithm.  For instance,
      [<a href="./rfc3447" title="&quot;Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1&quot;">RFC3447</a>] defines the RSASSA-PKCS1-v1_5 and RSASSA-PSS algorithms
      that are usually used for that purpose;

   o  MUST communicate the One-way Hash Function -- for instance, SHA-1,
      SHA-224, SHA-256, SHA-384, or SHA-512.  Because of security
      threats on SHA-1, the use of SHA-256 is RECOMMENDED [<a href="./rfc6194" title="&quot;Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms&quot;">RFC6194</a>];

   o  MUST associate a value to the ASID field of the EXT_AUTH header
      extension (<a href="#section-3.1">Section 3.1</a>);

   o  MUST communicate whether or not the anti-replay service is used
      for this session.

   These parameters MUST be communicated to all receivers before they
   can authenticate the incoming packets.  For instance, it can be
   communicated in the session description, or initialized in a static
   way on the receivers, or communicated by means of an appropriate
   protocol.  The details of this out-of-band mechanism are beyond the
   scope of this document.








<span class="grey">Roca                         Standards Track                   [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6584">RFC 6584</a>         Simple Authentication for ALC and NORM       April 2012</span>


<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>.  Processing</span>

<span class="h4"><a class="selflink" id="section-3.3.1" href="#section-3.3.1">3.3.1</a>.  Signature Processing</span>

   The computation of the Digital Signature, using the private key, MUST
   include the ALC or NORM header (with the various header extensions)
   and the payload when applicable.  The UDP/IP/MAC headers MUST NOT be
   included.  During this computation, the Signature field MUST be set
   to 0.

   Several signature-encoding algorithms can be used, including
   RSASSA-PKCS1-v1_5 and RSASSA-PSS.  With these encodings, several
   one-way hash functions can be used, like SHA-256.

   First, let us consider a packet sender.  More specifically, as noted
   in [<a href="./rfc4359" title="&quot;The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH)&quot;">RFC4359</a>], Digital Signature generation is performed as described
   in <a href="./rfc3447#section-8.2.1">Section&nbsp;8.2.1 of [RFC3447]</a> (RSASSA-PKCS1-v1_5) and in
   <a href="./rfc3447#section-8.1.1">Section&nbsp;8.1.1 of [RFC3447]</a> (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 Digital Signature (also
   called the Integrity Check Value (ICV) in [<a href="./rfc4359" title="&quot;The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH)&quot;">RFC4359</a>]) MUST be
   prepended with between 1 and 7 bits set to zero such that the Digital
   Signature is a multiple of 8 bits [<a href="./rfc4359" title="&quot;The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH)&quot;">RFC4359</a>].  The key length, which
   in practice is also equal to the RSA modulus, has major security
   implications.  [<a href="./rfc4359" title="&quot;The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH)&quot;">RFC4359</a>] explains how to choose this value, depending
   on the maximum expected lifetime of the session.  This choice is
   beyond the scope of this document.

   Now, let us consider a receiver.  As noted in [<a href="./rfc4359" title="&quot;The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH)&quot;">RFC4359</a>], Digital
   Signature verification is performed as described in <a href="./rfc3447#section-8.2.2">Section&nbsp;8.2.2 of
   [RFC3447]</a> (RSASSA-PKCS1-v1_5) and <a href="./rfc3447#section-8.1.2">Section&nbsp;8.1.2 of [RFC3447]</a>
   (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 using the sender's public key, and




<span class="grey">Roca                         Standards Track                   [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6584">RFC 6584</a>         Simple Authentication for ALC and NORM       April 2012</span>


   validates that the appropriate encoding was applied.  The two SHA-256
   hashes are compared, and if they are identical, the validation is
   successful.

<span class="h4"><a class="selflink" id="section-3.3.2" href="#section-3.3.2">3.3.2</a>.  Anti-Replay Processing</span>

   Let us assume the anti-replay service is used.  The principles are
   similar to the Sequence Number mechanism described in [<a href="./rfc4303" title="&quot;IP Encapsulating Security Payload (ESP)&quot;">RFC4303</a>], with
   the exception that the present document uses a 40-bit field that
   contains all the bits of the Sequence Number counter.

   At the sender, the mechanism works as follows (<a href="./rfc4303#section-2.2">Section&nbsp;2.2 of
   [RFC4303]</a>).  The sender's Sequence Number counter is initialized to 0
   at session startup.  The sender increments the Sequence Number
   counter for this session and inserts the value into the SN field.
   Thus, the first packet sent will contain an SN of 1.  The SN value of
   the Authentication Header extension MUST be initialized before the
   signature generation process, in order to enable a receiver to check
   the SN value during the integrity verification process.

   The sender SHOULD ensure that the counter does not cycle before
   inserting the new value in the SN field.  Failing to follow this rule
   would enable an attacker to replay a packet sent during the previous
   cycle; i.e., it would limit the anti-replay service to a single SN
   cycle.  Since the Sequence Number is contained in a 40-bit field, it
   is expected that cycling will never happen in most situations.  For
   instance, on a 10-Gbps network, with small packets (i.e., 64 bytes
   long), cycling will happen after slightly more than 15 hours.

   At the receiver, the mechanism works as follows (<a href="#section-3.4.3">Section 3.4.3</a> and
   <a href="#appendix-A">Appendix A</a>2 of [<a href="./rfc4303" title="&quot;IP Encapsulating Security Payload (ESP)&quot;">RFC4303</a>]).  For each received packet, the receiver
   MUST verify that the packet contains a Sequence Number that does not
   duplicate the Sequence Number of any other packets received during
   the session.  If this preliminary check fails, the packet is
   discarded, thus avoiding the need for any cryptographic operations by
   the receiver.  If the preliminary check is successful, the receiver
   cannot yet modify its local counter, because the integrity of the
   Sequence Number has not been verified at this point.

   Duplicates are rejected through the use of a sliding receive window.
   The "right" edge of the window represents the highest, validated
   Sequence Number value received on this session.  Packets that contain
   Sequence Numbers lower than the "left" edge of the window are
   rejected.  Packets falling within the window are checked against a
   list of received packets within the window (how this list is managed
   is a local, implementation-based decision).  This window limits how
   far out of order a packet can be, relative to the packet with the
   highest Sequence Number that has been authenticated so far.



<span class="grey">Roca                         Standards Track                   [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc6584">RFC 6584</a>         Simple Authentication for ALC and NORM       April 2012</span>


   If the received packet falls within the window and is not a
   duplicate, or if the packet is to the right of the window, then the
   receiver proceeds to integrity verification.  If the integrity check
   fails, the receiver MUST discard the received packet as invalid;
   otherwise, the receive window is updated and packet processing
   continues.

<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>.  In Practice</span>

   Each packet sent MUST contain exactly one Digital Signature EXT_AUTH
   header extension.  A receiver MUST drop all the packets that do not
   contain a Digital Signature EXT_AUTH header extension.

   All receivers MUST recognize EXT_AUTH but might not be able to parse
   its content, for instance, because they do not support Digital
   Signatures.  In that case, the Digital Signature EXT_AUTH header
   extension is ignored.

   If the anti-replay mechanism is used, each packet sent MUST contain a
   valid Sequence Number.  All the packets that fail to contain a valid
   Sequence Number MUST be immediately dropped.

   For instance, Figure 2 shows the Digital Signature EXT_AUTH header
   extension when using 128-byte (1024-bit) key Digital Signatures
   (which also means that the Signature field is 128 bytes long).  The
   Digital Signature EXT_AUTH header extension is then 132 bytes long.

    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 (=33)   |  ASID |  0  |0|      0        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
   |                                                               | ^ 1
   +                                                               + | 2
   |                                                               | | 8
   .                                                               . |
   .                      Signature (128 bytes)                    . | b
   .                                                               . | y
   |                                                               | | t
   +                                                               + | e
   |                                                               | v s
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---

        Figure 2: Example: Format of the Digital Signature EXT_AUTH
                Header Extension Using 1024-Bit Signatures,
                    without Any Anti-Replay Protection





<span class="grey">Roca                         Standards Track                   [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc6584">RFC 6584</a>         Simple Authentication for ALC and NORM       April 2012</span>


<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Elliptic Curve Digital Signature Scheme</span>

   This document focuses on the Elliptic Curve Digital Signature
   Algorithm (ECDSA).  However, [<a href="./rfc6090" title="&quot;Fundamental Elliptic Curve Cryptography Algorithms&quot;">RFC6090</a>] describes alternative elliptic
   curve techniques, like KT-I signatures.  The use of such alternatives
   is not considered in this document, but may be added in the future.

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  Authentication Header Extension Format</span>

   The integration of ECC Digital Signatures is similar to that of RSA
   Digital Signatures.  Several fields are added, in addition to the HET
   and HEL fields, as illustrated in Figure 1.

   The fields of the Digital Signature EXT_AUTH header extension are as
   follows:

   ASID (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.

   rsvd (3 bits):

      This is a reserved field that MUST be set to zero and ignored by
      receivers.

   AR (1 bit):

      The AR field, when set to 0, indicates that the anti-replay
      service is not used.  When set to 1, it indicates that the
      anti-replay service is used.

   SN (8 or 40 bits):

      The SN field contains an optional Sequence Number.  When AR = 0,
      this is an 8-bit field that MUST be set to zero.  No anti-replay
      mechanism is used in that case.  When AR = 1, this is a 40-bit
      field (32 bits + 8 bits), and all of the 40 bits MUST be
      considered by the anti-replay mechanism.

   Signature (variable size, multiple of 32 bits):

      The Signature field contains a Digital Signature of the message.
      If need be, this field is padded (with 0) up to a multiple of
      32 bits.





<span class="grey">Roca                         Standards Track                   [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc6584">RFC 6584</a>         Simple Authentication for ALC and NORM       April 2012</span>


<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  Parameters</span>

   Several parameters MUST be initialized by an out-of-band mechanism.
   The sender or group controller

   o  MUST communicate its public key, for each receiver to be able to
      verify the signature of the packets received.  As a side effect,
      the receivers also know the key length and the signature length,
      the two parameters being equal;

   o  MAY communicate a certificate (which also means that a PKI has
      been set up), for each receiver to be able to check the sender's
      public key;

   o  MUST communicate the message digest algorithm;

   o  MUST communicate the elliptic curve;

   o  MUST associate a value to the ASID field of the EXT_AUTH header
      extension (<a href="#section-3.1">Section 3.1</a>);

   o  MUST communicate whether or not the anti-replay service is used
      for this session.

   These parameters MUST be communicated to all receivers before they
   can authenticate the incoming packets.  For instance, it can be
   communicated in the session description, or initialized in a static
   way on the receivers, or communicated by means of an appropriate
   protocol.  The details of this out-of-band mechanism are beyond the
   scope of this document.

<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>.  Processing</span>

<span class="h4"><a class="selflink" id="section-4.3.1" href="#section-4.3.1">4.3.1</a>.  Signature Processing</span>

   The computation of the ECC Digital Signature, using the private key,
   MUST include the ALC or NORM header (with the various header
   extensions) and the payload when applicable.  The UDP/IP/MAC headers
   MUST NOT be included.  During this computation, the Signature field
   MUST be set to 0.

   Several elliptic curve groups can be used, as well as several hash
   algorithms.  In practice, both choices are related, and there is a
   minimum hash algorithm size for any key length.  Using a larger hash
   algorithm and then truncating the output is also feasible; however,






<span class="grey">Roca                         Standards Track                   [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc6584">RFC 6584</a>         Simple Authentication for ALC and NORM       April 2012</span>


   it consumes more processing power than is necessary.  In order to
   promote interoperability, [<a href="./rfc4754" title="&quot;IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA)&quot;">RFC4754</a>] and [<a href="./rfc5480" title="&quot;Elliptic Curve Cryptography Subject Public Key Information&quot;">RFC5480</a>] list several
   possible choices (see table below).

   +---------------------------+--------+------------------+-----------+
   |     Digital Signature     |   Key  |  Message Digest  |  Elliptic |
   |  Algorithm Name [<a href="./rfc4754" title="&quot;IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA)&quot;">RFC4754</a>] |  Size  |     Algorithm    |   Curve   |
   +---------------------------+--------+------------------+-----------+
   |    ECDSA-256 (default)    |   256  |      SHA-256     | secp256r1 |
   |         ECDSA-384         |   384  |      SHA-384     | secp384r1 |
   |         ECDSA-521         |   512  |      SHA-512     | secp521r1 |
   +---------------------------+--------+------------------+-----------+

   ECDSA-256, ECDSA-384, and ECDSA-521 are designed to offer security
   comparable with AES-128, AES-192, and AES-256, respectively
   [<a href="./rfc4754" title="&quot;IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA)&quot;">RFC4754</a>].  Among them, the use of ECDSA-256/secp256r1 is
   RECOMMENDED.

<span class="h4"><a class="selflink" id="section-4.3.2" href="#section-4.3.2">4.3.2</a>.  Anti-Replay Processing</span>

   The anti-replay processing follows the principles described in
   <a href="#section-3.3.2">Section 3.3.2</a>.

<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>.  In Practice</span>

   Each packet sent MUST contain exactly one ECC Digital Signature
   EXT_AUTH header extension.  A receiver MUST drop all the packets that
   do not contain an ECC Digital Signature EXT_AUTH header extension.

   All receivers MUST recognize EXT_AUTH but might not be able to parse
   its content, for instance, because they do not support ECC Digital
   Signatures.  In that case, the Digital Signature EXT_AUTH header
   extension is ignored.

   If the anti-replay mechanism is used, each packet sent MUST contain a
   valid Sequence Number.  All the packets that fail to contain a valid
   Sequence Number MUST be immediately dropped.














<span class="grey">Roca                         Standards Track                   [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc6584">RFC 6584</a>         Simple Authentication for ALC and NORM       April 2012</span>


   For instance, Figure 3 shows the Digital Signature EXT_AUTH header
   extension when using ECDSA-256 (256-bit) ECC Digital Signatures.
   The ECC Digital Signature EXT_AUTH header extension is then 36 bytes
   long.

    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 (=9)    |  ASID |  0  |0|      0        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
   |                                                               | ^ 3
   +                                                               + | 2
   .                                                               . |
   .                      Signature (32 bytes)                     . | b
   .                                                               . | y
   |                                                               | | t
   +                                                               + | e
   |                                                               | v s
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---

      Figure 3: Example: Format of the ECC Digital Signature EXT_AUTH
               Header Extension Using ECDSA-256 Signatures,
                    without Any Anti-Replay Protection

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Group-Keyed Message Authentication Code (MAC) Scheme</span>

<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>.  Authentication Header Extension Format</span>

   The integration of Group-keyed MAC is similar in ALC and NORM and
   relies on the header extension mechanism defined in both protocols.
   More precisely, this document details the HET=1 (EXT_AUTH) header
   extension defined in [<a href="./rfc5651" title="&quot;Layered Coding Transport (LCT) Building Block&quot;">RFC5651</a>].



















<span class="grey">Roca                         Standards Track                   [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc6584">RFC 6584</a>         Simple Authentication for ALC and NORM       April 2012</span>


   Several fields are added, in addition to the HET and HEL fields
   (Figure 4).

    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 | rsvd|A|               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R+               +
   ~                  anti-replay Sequence Number (SN)             ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                                                               ~
   |                        Group-keyed MAC                        |
   +                                               +-+-+-+-+-+-+-+-+
   |                                               |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 4: Format of the Group-Keyed MAC EXT_AUTH Header Extension

   The fields of the Group-keyed MAC EXT_AUTH header extension are as
   follows:

   ASID (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.

   rsvd (3 bits):

      This is a reserved field that MUST be set to zero and ignored by
      receivers.

   AR (1 bit):

      The AR field, when set to 0, indicates that the anti-replay
      service is not used.  When set to 1, it indicates that the
      anti-replay service is used.

   SN (8 or 40 bits):

      The SN field contains an optional Sequence Number.  When AR = 0,
      this is an 8-bit field that MUST be set to zero.  No anti-replay
      mechanism is used in that case.  When AR = 1, this is a 40-bit
      field (32 bits + 8 bits), and all of the 40 bits MUST be
      considered by the anti-replay mechanism.





<span class="grey">Roca                         Standards Track                   [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc6584">RFC 6584</a>         Simple Authentication for ALC and NORM       April 2012</span>


   Group-keyed MAC (variable size, multiple of 32 bits):

      The Group-keyed MAC field contains a truncated Group-keyed MAC of
      the message.  If need be, this field is padded (with 0) up to a
      multiple of 32 bits.

<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>.  Parameters</span>

   Several parameters MUST be initialized by an out-of-band mechanism.
   The sender or group controller

   o  MUST communicate the Cryptographic MAC Function -- for instance,
      HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, or
      HMAC-SHA-512.  As a side effect, with these functions, the
      receivers also know the key length and the non-truncated MAC
      output length.  Because of security threats on SHA-1, the use of
      HMAC-SHA-256 is RECOMMENDED [<a href="./rfc6194" title="&quot;Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms&quot;">RFC6194</a>];

   o  MUST communicate the length of the truncated output of the MAC,
      n_m, which depends on the Cryptographic MAC Function chosen.  Only
      the n_m leftmost bits (most significant bits) of the MAC output
      are kept.  Of course, n_m MUST be less than or equal to the key
      length;

   o  MUST communicate the group key to the receivers, confidentially,
      before starting the session.  This key might have to be
      periodically refreshed for improved robustness;

   o  MUST associate a value to the ASID field of the EXT_AUTH header
      extension (<a href="#section-5.1">Section 5.1</a>);

   o  MUST communicate whether or not the anti-replay service is used
      for this session.

   These parameters MUST be communicated to all receivers before they
   can authenticate the incoming packets.  For instance, it can be
   communicated in the session description, or initialized in a static
   way on the receivers, or communicated by means of an appropriate
   protocol (this will often be the case when periodic re-keying is
   required).  The details of this out-of-band mechanism are beyond the
   scope of this document.










<span class="grey">Roca                         Standards Track                   [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc6584">RFC 6584</a>         Simple Authentication for ALC and NORM       April 2012</span>


<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>.  Processing</span>

<span class="h4"><a class="selflink" id="section-5.3.1" href="#section-5.3.1">5.3.1</a>.  Signature Processing</span>

   The computation of the Group-keyed MAC, using the group key, includes
   the ALC or NORM header (with the various header extensions) and the
   payload when applicable.  The UDP/IP/MAC headers are not included.
   During this computation, the weak Group-keyed MAC field MUST be set
   to 0.  Then, the sender truncates the MAC output to keep the n_m most
   significant bits and stores the result in the Group-keyed MAC
   Authentication Header.

   Upon receiving this packet, the receiver computes the Group-keyed
   MAC, using the group key, and compares it to the value carried in the
   packet.  During this computation, the Group-keyed MAC field MUST also
   be set to 0.  If the check fails, the packet MUST be immediately
   dropped.

   [<a id="ref-RFC2104">RFC2104</a>] explains that it is current practice to truncate the MAC
   output, on condition that the truncated output length, n_m, be not
   less than half the length of the hash and not less than 80 bits.
   However, this choice is beyond the scope of this document.

<span class="h4"><a class="selflink" id="section-5.3.2" href="#section-5.3.2">5.3.2</a>.  Anti-Replay Processing</span>

   The anti-replay processing follows the principles described in
   <a href="#section-3.3.2">Section 3.3.2</a>.

<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>.  In Practice</span>

   Each packet sent MUST contain exactly one Group-keyed MAC EXT_AUTH
   header extension.  A receiver MUST drop packets that do not contain a
   Group-keyed MAC EXT_AUTH header extension.

   All receivers MUST recognize EXT_AUTH but might not be able to parse
   its content, for instance, because they do not support Group-keyed
   MAC.  In that case, the Group-keyed MAC EXT_AUTH extension is
   ignored.

   If the anti-replay mechanism is used, each packet sent MUST contain a
   valid Sequence Number.  All the packets that fail to contain a valid
   Sequence Number MUST be immediately dropped.









<span class="grey">Roca                         Standards Track                   [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc6584">RFC 6584</a>         Simple Authentication for ALC and NORM       April 2012</span>


   For instance, Figure 5 shows the Group-keyed MAC EXT_AUTH header
   extension when using HMAC-SHA-256.  The Group-keyed MAC EXT_AUTH
   header extension is then 16 bytes long.

    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 (=4)   |  ASID |  0  |0|      0        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                   Group-keyed MAC (16 bytes)                  |
   +                                                               +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 5: Example: Format of the Group-Keyed MAC EXT_AUTH Header
     Extension Using HMAC-SHA-256, without Any Anti-Replay Protection

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Combined Use of the RSA/ECC Digital Signatures and Group-Keyed MAC</span>
<span class="h2">    Schemes</span>

<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>.  Authentication Header Extension Format</span>

   The integration of combined RSA/ECC Digital Signatures and
   Group-keyed MAC schemes is similar in ALC and NORM and relies on the
   header extension mechanism defined in both protocols.  More
   precisely, this document details the HET=1 (EXT_AUTH) header
   extension defined in [<a href="./rfc5651" title="&quot;Layered Coding Transport (LCT) Building Block&quot;">RFC5651</a>].




















<span class="grey">Roca                         Standards Track                   [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc6584">RFC 6584</a>         Simple Authentication for ALC and NORM       April 2012</span>


   Several fields are added, in addition to the HET and HEL fields
   (Figure 6).

    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 | rsvd|A|               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R+               +
   |                  anti-replay Sequence Number (SN)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                                                               ~
   |                           Signature                           |
   +                                               +-+-+-+-+-+-+-+-+
   |                                               |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Group-keyed MAC                        |
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 6: Format of the Group-Keyed MAC EXT_AUTH Header Extension

   The fields of the Group-keyed MAC EXT_AUTH header extension are as
   follows:

   ASID (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.

   rsvd (3 bits):

      This is a reserved field that MUST be set to zero and ignored by
      receivers.

   AR (1 bit):

      The AR field MUST be set to 1, indicating that the anti-replay
      service is used (see <a href="#section-6.3">Section 6.3</a>).

   SN (8 or 40 bits):

      The SN field contains a Sequence Number.  Since AR = 1, this is a
      40-bit field (32 bits + 8 bits), and all of the 40 bits MUST be
      considered by the anti-replay mechanism.





<span class="grey">Roca                         Standards Track                   [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc6584">RFC 6584</a>         Simple Authentication for ALC and NORM       April 2012</span>


   Signature (variable size, multiple of 32 bits):

      The Signature field contains a Digital Signature of the message.
      If need be, this field is padded (with 0) up to a multiple of
      32 bits.

   Group-keyed MAC (variable size, multiple of 32 bits, by default
   32 bits):

      The Group-keyed MAC field contains a truncated Group-keyed MAC of
      the message.

<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>.  Parameters</span>

   Several parameters MUST be initialized by an out-of-band mechanism,
   as defined in Sections <a href="#section-3.2">3.2</a>, <a href="#section-4.2">4.2</a>, and <a href="#section-5.2">5.2</a>.

<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>.  Processing</span>

   In some situations, it can be interesting to use both authentication
   schemes.  The goal of the Group-keyed MAC is to mitigate denial-of-
   service (DoS) attacks coming from attackers that are not group
   members [<a href="./rfc4082" title="&quot;Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction&quot;">RFC4082</a>], by adding a light authentication scheme as a
   front-end.

<span class="h4"><a class="selflink" id="section-6.3.1" href="#section-6.3.1">6.3.1</a>.  Signature Processing</span>

   Before sending a message, the sender sets the Signature field and
   Group-keyed MAC field to zero.  Then, the sender computes the
   signature as detailed in <a href="#section-3.3">Section 3.3</a> or in <a href="#section-4.3">Section 4.3</a> and stores the
   value in the Signature field.  Then, the sender computes the
   Group-keyed MAC as detailed in <a href="#section-5.3">Section 5.3</a> and stores the value in
   the Group-keyed MAC field.  The (RSA or ECC) Digital Signature value
   is therefore protected by the Group-keyed MAC, which avoids DoS
   attacks where the attacker corrupts the Digital Signature itself.

   Upon receiving the packet, the receiver first checks the Group-keyed
   MAC, as detailed in <a href="#section-5.3">Section 5.3</a>.  If the check fails, the packet MUST
   be immediately dropped.  Otherwise, the receiver checks the Digital
   Signature, as detailed in <a href="#section-3.3">Section 3.3</a>.  If the check fails, the
   packet MUST be immediately dropped.










<span class="grey">Roca                         Standards Track                   [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc6584">RFC 6584</a>         Simple Authentication for ALC and NORM       April 2012</span>


   This scheme features a few limits:

   o  The Group-keyed MAC is of no help if a group member (who knows the
      group key) impersonates the sender and sends forged messages to
      other receivers.  DoS attacks are still feasible;

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

   o  It increases the size of the Authentication Headers.  In order to
      limit this problem, the length of the truncated output of the MAC,
      n_m, SHOULD be kept small (see <a href="./rfc3711#section-9.5">Section&nbsp;9.5 of [RFC3711]</a>).  In the
      current specification, n_m MUST be a multiple of 32 bits, and the
      default value is 32 bits.  As a side effect, with n_m = 32 bits,
      the authentication service is significantly weakened, since the
      probability that any packet would be successfully forged is one in
      2^32.  Since the Group-keyed MAC check is only a pre-check that is
      followed by the standard signature authentication check, this is
      not considered to be an issue.

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

<span class="h4"><a class="selflink" id="section-6.3.2" href="#section-6.3.2">6.3.2</a>.  Anti-Replay Processing</span>

   The anti-replay processing follows the principles described in
   <a href="#section-3.3.2">Section 3.3.2</a>.  Here, an anti-replay service MUST be used.  Indeed,
   failing to enable anti-replay protection would facilitate DoS
   attacks, since all replayed (but otherwise valid) packets would pass
   the light authentication scheme and oblige a receiver to perform a
   complex signature verification.

<span class="h3"><a class="selflink" id="section-6.4" href="#section-6.4">6.4</a>.  In Practice</span>

   Each packet sent MUST contain exactly one combined Digital Signature/
   Group-keyed MAC EXT_AUTH header extension.  A receiver MUST drop
   packets that do not contain a combined Digital Signature/Group-keyed
   MAC EXT_AUTH header extension.

   All receivers MUST recognize EXT_AUTH but might not be able to parse
   its content, for instance, because they do not support combined
   Digital Signature/Group-keyed MAC.  In that case, the combined
   Digital Signature/Group-keyed MAC EXT_AUTH extension is ignored.

   Since the anti-replay mechanism MUST be used, each packet sent MUST
   contain a valid Sequence Number.  All the packets that fail to
   contain a valid Sequence Number MUST be immediately dropped.




<span class="grey">Roca                         Standards Track                   [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc6584">RFC 6584</a>         Simple Authentication for ALC and NORM       April 2012</span>


   It is RECOMMENDED that the n_m parameter of the group authentication
   scheme be small, and by default equal to 32 bits (<a href="#section-6.3">Section 6.3</a>).

   For instance, Figure 7 shows the combined Digital Signature/
   Group-keyed MAC EXT_AUTH header extension when using 128-byte
   (1024-bit) key RSA Digital Signatures (which also means that the
   Signature field is 128 bytes long).  The EXT_AUTH header extension is
   then 140 bytes long.

    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 (=35)   |  ASID |  0  |1|               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
   |                  anti-replay Sequence Number (SN)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
   |                                                               | ^ 1
   +                                                               + | 2
   |                                                               | | 8
   .                                                               . |
   .                      Signature (128 bytes)                    . | b
   .                                                               . | y
   |                                                               | | t
   +                                                               + | e
   |                                                               | v s
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
   |                    Group-keyed MAC (32 bits)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---

     Figure 7: Example: Format of the Combined RSA Digital Signature/
   Group-Keyed MAC EXT_AUTH Header Extension Using 1024-Bit Signatures,
                        with Anti-Replay Protection

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Security Considerations</span>

<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>.  Dealing with DoS Attacks</span>

   Let us consider packets secured through the use of a Digital
   Signature scheme first.  Because faked packets are easy to create but
   checking them requires computation of a costly Digital Signature,
   this scheme introduces new opportunities for an attacker to mount DoS
   attacks.  More precisely, an attacker can easily saturate the
   processing capabilities of the receiver.

   In order to mitigate these attacks, it is RECOMMENDED that the
   combined Digital Signature/Group-keyed MAC scheme (<a href="#section-6.3">Section 6.3</a>) be
   used.  However, no mitigation is possible if a group member acts as
   an attacker.  Additionally, even if checking a Group-keyed MAC is



<span class="grey">Roca                         Standards Track                   [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc6584">RFC 6584</a>         Simple Authentication for ALC and NORM       April 2012</span>


   significantly faster than checking a Digital Signature, there are
   practical limits on how many Group-keyed MACs can be checked per time
   unit.  Therefore, it is RECOMMENDED that limiting the number of
   authentication checks per time unit be done when the number of
   incoming packets that fail the authentication check exceeds a given
   threshold (i.e., in the case of a DoS attack).

   The RECOMMENDED action of limiting the number of checks per time unit
   under (presumed) attack situations can be extended to the other
   authentication schemes.

<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>.  Dealing with Replay Attacks</span>

   Replay attacks involve an attacker storing a valid message and
   replaying it later.  It is RECOMMENDED that the anti-replay service
   defined in this document be used with the signature and Group-keyed
   MAC solutions, and this anti-replay service MUST be used in the case
   of a combined use of signatures and Group-keyed MAC schemes (see
   <a href="#section-6.3.2">Section 6.3.2</a>).

   The following section details some of the potential consequences of
   not using anti-replay protection.

<span class="h4"><a class="selflink" id="section-7.2.1" href="#section-7.2.1">7.2.1</a>.  Impacts of Replay Attacks on the Simple Authentication Schemes</span>

   Since all the above authentication schemes are stateless, replay
   attacks have no impact on these schemes.

<span class="h4"><a class="selflink" id="section-7.2.2" href="#section-7.2.2">7.2.2</a>.  Impacts of Replay Attacks on NORM</span>

   In this subsection, we review 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,
   congestion control protocols.

   First, let us consider replay attacks within a given NORM session.
   As NORM is a stateful protocol, replaying a packet may have
   consequences.

   NORM defines a "sequence" field that may be used to protect against
   replay attacks [<a href="./rfc5740" title="&quot;NACK-Oriented Reliable Multicast (NORM) Transport Protocol&quot;">RFC5740</a>] 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.  Using this field for anti-replay
   protection would be possible if there is no wrapping to zero, i.e.,
   would only be possible if at most 65535 packets are sent; this may be
   true for some use cases but not for the general case.  Using this




<span class="grey">Roca                         Standards Track                   [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc6584">RFC 6584</a>         Simple Authentication for ALC and NORM       April 2012</span>


   field for anti-replay protection would also be possible if the keying
   material is updated before wrapping to zero happens; this may be true
   for some use cases but not for the general case.

   Now, let us consider replay attacks across several NORM sessions.  A
   host participating in a NORM session is uniquely identified by the
   {source_id; instance_id} tuple.  Therefore, when a given host
   participates in several NORM sessions, it is RECOMMENDED that
   instance_id be changed for each NORM instance.  It is also
   RECOMMENDED, when the Group-keyed MAC authentication/integrity check
   scheme is used, that the shared group key be changed across sessions.
   Therefore, NORM can be made robust when confronted with replay
   attacks across different sessions.

<span class="h4"><a class="selflink" id="section-7.2.3" href="#section-7.2.3">7.2.3</a>.  Impacts of Replay Attacks on ALC</span>

   In this subsection, we review 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, layered
   or wave-based congestion control protocols.

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

   o  Replayed encoding symbol: A replayed encoding symbol (coming from
      a replayed data packet) is detected, thanks to the object/block/
      symbol identifiers, and is silently discarded.

   o  Replayed control information:

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

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

      *  Timing information sent as part of a Layered Coding Transport
         (LCT) EXT_TIME header extension [<a href="./rfc5651" title="&quot;Layered Coding Transport (LCT) Building Block&quot;">RFC5651</a>] may be more sensitive
         to replay attacks.  For instance, replaying a packet containing
         an ERT (Expected Residual Time) may mislead a receiver to
         believe an object transmission will continue for some time
         whereas the transmission of symbols for this object is about to
         stop.  Replaying a packet containing a Sender Current Time
         (SCT) is easily identified if the receiver verifies that time
         progresses upon receiving such EXT_TIME header extensions.





<span class="grey">Roca                         Standards Track                   [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc6584">RFC 6584</a>         Simple Authentication for ALC and NORM       April 2012</span>


         Replaying a packet containing a Session Last Changed (SLC) is
         easily identified if the receiver verifies the chronology upon
         receiving such EXT_TIME header extensions.

   This analysis shows that ALC might be, to a limited extent, sensitive
   to replay attacks within the same session if timing information is
   used.  Otherwise, ALC is robust when confronted with replay attacks
   within the same session.

   Now, let us consider replay attacks across several ALC sessions.  An
   ALC session is uniquely identified by the {sender IP address; TSI}
   tuple.  Therefore, when a given sender creates several sessions, the
   TSI MUST be changed for each ALC session, so that each TSI is unique
   among all active sessions of this sender and for a long period of
   time preceding and following when the session is active [<a href="./rfc5651" title="&quot;Layered Coding Transport (LCT) Building Block&quot;">RFC5651</a>].
   Therefore, ALC can be made robust when confronted with replay attacks
   across different sessions.  Of course, when the Group-keyed MAC
   authentication/integrity check scheme is used, the shared group key
   SHOULD be changed across sessions if the set of receivers changes.

<span class="h3"><a class="selflink" id="section-7.3" href="#section-7.3">7.3</a>.  Dealing with Attacks on the Parameters Sent Out-of-Band</span>

   This specification requires that several parameters be communicated
   to the receiver(s) via an out-of-band mechanism that is beyond the
   scope of this document.  This is in particular the case for the
   mapping between an ASID value and the associated authentication
   scheme (<a href="#section-1">Section 1</a>).  Since this mapping is critical, this information
   SHOULD be carried in a secure way from the sender to the receiver(s).

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  Acknowledgments</span>

   The author is grateful to the authors of [<a href="./rfc4303" title="&quot;IP Encapsulating Security Payload (ESP)&quot;">RFC4303</a>], [<a href="./rfc4359" title="&quot;The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH)&quot;">RFC4359</a>],
   [<a href="./rfc4754" title="&quot;IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA)&quot;">RFC4754</a>], and [<a href="./rfc5480" title="&quot;Elliptic Curve Cryptography Subject Public Key Information&quot;">RFC5480</a>]; their documents inspired several sections
   of the present document.  The author is also grateful to all the IESG
   members, and in particular to David Harrington, Stephen Farrell, and
   Sean Turner for their very detailed reviews.

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  References</span>

<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>.  Normative References</span>

   [<a id="ref-RFC2104">RFC2104</a>]    Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
                Hashing for Message Authentication", <a href="./rfc2104">RFC 2104</a>,
                February 1997.

   [<a id="ref-RFC2119">RFC2119</a>]    Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.




<span class="grey">Roca                         Standards Track                   [Page 28]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-29" ></span>
<span class="grey"><a href="./rfc6584">RFC 6584</a>         Simple Authentication for ALC and NORM       April 2012</span>


   [<a id="ref-RFC5651">RFC5651</a>]    Luby, M., Watson, M., and L. Vicisano, "Layered Coding
                Transport (LCT) Building Block", <a href="./rfc5651">RFC 5651</a>, October 2009.

   [<a id="ref-RFC5740">RFC5740</a>]    Adamson, B., Bormann, C., Handley, M., and J. Macker,
                "NACK-Oriented Reliable Multicast (NORM) Transport
                Protocol", <a href="./rfc5740">RFC 5740</a>, November 2009.

   [<a id="ref-RFC5775">RFC5775</a>]    Luby, M., Watson, M., and L. Vicisano, "Asynchronous
                Layered Coding (ALC) Protocol Instantiation", <a href="./rfc5775">RFC 5775</a>,
                April 2010.

<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>.  Informative References</span>

   [<a id="ref-RFC3447">RFC3447</a>]    Jonsson, J. and B. Kaliski, "Public-Key Cryptography
                Standards (PKCS) #1: RSA Cryptography Specifications
                Version 2.1", <a href="./rfc3447">RFC 3447</a>, February 2003.

   [<a id="ref-RFC3711">RFC3711</a>]    Baugher, M., McGrew, D., Naslund, M., Carrara, E., and
                K. Norrman, "The Secure Real-time Transport Protocol
                (SRTP)", <a href="./rfc3711">RFC 3711</a>, March 2004.

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

   [<a id="ref-RFC4303">RFC4303</a>]    Kent, S., "IP Encapsulating Security Payload (ESP)",
                <a href="./rfc4303">RFC 4303</a>, December 2005.

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

   [<a id="ref-RFC4754">RFC4754</a>]    Fu, D. and J. Solinas, "IKE and IKEv2 Authentication
                Using the Elliptic Curve Digital Signature Algorithm
                (ECDSA)", <a href="./rfc4754">RFC 4754</a>, January 2007.

   [<a id="ref-RFC5480">RFC5480</a>]    Turner, S., Brown, D., Yiu, K., Housley, R., and T.
                Polk, "Elliptic Curve Cryptography Subject Public Key
                Information", <a href="./rfc5480">RFC 5480</a>, March 2009.

   [<a id="ref-RFC5751">RFC5751</a>]    Ramsdell, B. and S. Turner, "Secure/Multipurpose
                Internet Mail Extensions (S/MIME) Version 3.2 Message
                Specification", <a href="./rfc5751">RFC 5751</a>, January 2010.







<span class="grey">Roca                         Standards Track                   [Page 29]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-30" ></span>
<span class="grey"><a href="./rfc6584">RFC 6584</a>         Simple Authentication for ALC and NORM       April 2012</span>


   [<a id="ref-RFC5776">RFC5776</a>]    Roca, V., Francillon, A., and S. Faurite, "Use of Timed
                Efficient Stream Loss-Tolerant Authentication (TESLA) in
                the Asynchronous Layered Coding (ALC) and NACK-Oriented
                Reliable Multicast (NORM) Protocols", <a href="./rfc5776">RFC 5776</a>,
                April 2010.

   [<a id="ref-RFC6090">RFC6090</a>]    McGrew, D., Igoe, K., and M. Salter, "Fundamental
                Elliptic Curve Cryptography Algorithms", <a href="./rfc6090">RFC 6090</a>,
                February 2011.

   [<a id="ref-RFC6194">RFC6194</a>]    Polk, T., Chen, L., Turner, S., and P. Hoffman,
                "Security Considerations for the SHA-0 and SHA-1
                Message-Digest Algorithms", <a href="./rfc6194">RFC 6194</a>, March 2011.

   [<a id="ref-RMT-FLUTE">RMT-FLUTE</a>]  Paila, T., Walsh, R., Luby, M., Roca, V., and R.
                Lehtonen, "FLUTE - File Delivery over Unidirectional
                Transport", Work in Progress, March 2012.

Author's Address

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

   EMail: vincent.roca@inria.fr
   URI:   <a href="http://planete.inrialpes.fr/people/roca/">http://planete.inrialpes.fr/people/roca/</a>






















Roca                         Standards Track                   [Page 30]
</pre>