RMT                                                              V. Roca
Internet-Draft                                                     INRIA
Intended status: Experimental                         September 30, 2011
Expires: April 2, 2012


      Simple Authentication Schemes for the ALC and NORM Protocols
               draft-ietf-rmt-simple-auth-for-alc-norm-05

Abstract

   This document introduces four schemes that provide per-packet
   authentication, integrity and anti-replay services in the context of
   the ALC and NORM protocols.  The first scheme is based on digital
   signatures.  The second scheme relies on the Elliptic Curve Digital
   Signature Algorithm (ECDSA).  The third scheme relies on a group
   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 Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 2, 2012.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect



Roca                      Expires April 2, 2012                 [Page 1]


Internet-Draft   Simple authentication for ALC and NORM   September 2011


   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.















































Roca                      Expires April 2, 2012                 [Page 2]


Internet-Draft   Simple authentication for ALC and NORM   September 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Scope of this Document . . . . . . . . . . . . . . . . . .  6
     1.2.  Terminology, Notations and Definitions . . . . . . . . . .  6
   2.  RSA Digital Signature Scheme . . . . . . . . . . . . . . . . .  8
     2.1.  Authentication Header Extension Format . . . . . . . . . .  8
     2.2.  Parameters . . . . . . . . . . . . . . . . . . . . . . . .  9
     2.3.  Processing . . . . . . . . . . . . . . . . . . . . . . . . 10
       2.3.1.  Signature Processing . . . . . . . . . . . . . . . . . 10
       2.3.2.  Anti-Replay Processing . . . . . . . . . . . . . . . . 11
     2.4.  In Practice  . . . . . . . . . . . . . . . . . . . . . . . 12
   3.  Elliptic Curve Digital Signature Scheme  . . . . . . . . . . . 13
     3.1.  Authentication Header Extension Format . . . . . . . . . . 13
     3.2.  Parameters . . . . . . . . . . . . . . . . . . . . . . . . 14
     3.3.  Processing . . . . . . . . . . . . . . . . . . . . . . . . 15
       3.3.1.  Signature Processing . . . . . . . . . . . . . . . . . 15
       3.3.2.  Anti-Replay Processing . . . . . . . . . . . . . . . . 15
     3.4.  In Practice  . . . . . . . . . . . . . . . . . . . . . . . 15
   4.  Group Message Authentication Code (MAC) Scheme . . . . . . . . 17
     4.1.  Authentication Header Extension Format . . . . . . . . . . 17
     4.2.  Parameters . . . . . . . . . . . . . . . . . . . . . . . . 18
     4.3.  Processing . . . . . . . . . . . . . . . . . . . . . . . . 19
       4.3.1.  Signature Processing . . . . . . . . . . . . . . . . . 19
       4.3.2.  Anti-Replay Processing . . . . . . . . . . . . . . . . 19
     4.4.  In Practice  . . . . . . . . . . . . . . . . . . . . . . . 19
   5.  Combined Use of the RSA/ECC Digital Signatures and Group
       MAC Schemes  . . . . . . . . . . . . . . . . . . . . . . . . . 21
     5.1.  Authentication Header Extension Format . . . . . . . . . . 21
     5.2.  Parameters . . . . . . . . . . . . . . . . . . . . . . . . 22
     5.3.  Processing . . . . . . . . . . . . . . . . . . . . . . . . 22
       5.3.1.  Signature Processing . . . . . . . . . . . . . . . . . 22
       5.3.2.  Anti-Replay Processing . . . . . . . . . . . . . . . . 23
     5.4.  In Practice  . . . . . . . . . . . . . . . . . . . . . . . 23
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 26
     7.1.  Dealing With DoS Attacks . . . . . . . . . . . . . . . . . 26
     7.2.  Dealing With Replay Attacks  . . . . . . . . . . . . . . . 26
       7.2.1.  Impacts of Replay Attacks on the Simple
               Authentication Schemes . . . . . . . . . . . . . . . . 26
       7.2.2.  Impacts of Replay Attacks on NORM  . . . . . . . . . . 26
       7.2.3.  Impacts of Replay Attacks on ALC . . . . . . . . . . . 27
     7.3.  Dealing With Attacks on the Parameters Sent Out-of-Band  . 28
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 29
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 30
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 30
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32



Roca                      Expires April 2, 2012                 [Page 3]


Internet-Draft   Simple authentication for ALC and NORM   September 2011


1.  Introduction

   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
   [RFC5775] and NORM [RFC5740] are 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.  With NORM
   each receiver acknowledges data received or, in case of packet
   erasures, asks for retransmissions.  On the opposite, 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 codes (FEC), 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 application level, on top of an erasure channel (e.g.
   the Internet) where packets can be lost (erased) during the
   transmission.

   With these CDP, 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 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 [RFC4359] (see Section 2 and Section 3): 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")
      significantly relaxes these constraints.  For instance, the
      following key lengths provide equivalent security: 1024 bit RSA
      key versus 160 bit ECC key, or 2048 bit RSA key versus 224 bit ECC
      key.

   o  group Message Authentication Codes (MAC) (see Section 4): this
      scheme is well suited to high data rate flows, when transmission



Roca                      Expires April 2, 2012                 [Page 4]


Internet-Draft   Simple authentication for ALC and NORM   September 2011


      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)
      [RFC4082][RFC5776]: 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 to pay 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/cons of each authentication/
   integrity scheme used at application/transport level (where "-" means
   bad, "0" means neutral, and "+" means good):

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

   Several authentication schemes MAY be used in the same ALC or NORM
   session, even on the same communication path.  Since all the above
   schemes make use of the same authentication header extension
   mechanism (Section 2.1, Section 4.1, Section 5.1) and [RFC5776],
   section 5.1), the same 4-bit "ASID" (Authentication Scheme
   IDentifier) has been reserved in all the specifications.  The
   association between the "ASID" value and the actual authentication
   scheme is defined at session startup and communicated to all the



Roca                      Expires April 2, 2012                 [Page 5]


Internet-Draft   Simple authentication for ALC and NORM   September 2011


   group members by an out-of-band mechanism.

   All the applications build 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 FLUTE
   application [RMT-FLUTE] 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
   Section 2.2 and Section 4.2.

1.1.  Scope of this Document

   [RFC5776] explains how to use TESLA in the context of 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 MAC schemes.  The current document also
   specifies the joint use of Digital Signature and Group 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).

1.2.  Terminology, Notations and Definitions

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

   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 case of feedback
      traffic;

   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 case of feedback
      traffic;



Roca                      Expires April 2, 2012                 [Page 6]


Internet-Draft   Simple authentication for ALC and NORM   September 2011


   Digital signature related definitions:

   o  the public key 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 used by a sender to generate a packet's signature;

   o  the private key and public key length are expressed in bits.  This
      is also the signature length, since those values are equal with
      digital signatures;

   Group MAC related definitions:

   o  the shared group key 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 [RFC2104].
      Only the n_m left-most bits (most significant bits) of the MAC
      output are kept;




























Roca                      Expires April 2, 2012                 [Page 7]


Internet-Draft   Simple authentication for ALC and NORM   September 2011


2.  RSA Digital Signature Scheme

2.1.  Authentication Header Extension Format

   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 EXT_AUTH==1 header extension
   defined in [RFC5651].

   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|               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
   ~                  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:

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

   "Reserved" field (3 bits):

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

   "A" (Anti-replay) field (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.




Roca                      Expires April 2, 2012                 [Page 8]


Internet-Draft   Simple authentication for ALC and NORM   September 2011


   "SN" (Sequence Number) field (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 32+8=40 bit
      field and all of the 40 bits MUST be considered by the anti-replay
      mechanism.

   "Signature" field (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.

2.2.  Parameters

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

   o  MUST communicate his 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 setup), for each receiver to be able to check the sender's
      public key;

   o  MUST communicate the Signature Encoding Algorithm.  For instance,
      [RFC3447] defines the RSASSA-PKCS1-v1_5 and RSASSA-PSS algorithms
      that are usually used to that purpose;

   o  MUST communicate the Signature Cryptographic 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;

   o  MUST associate a value to the "ASID" field (Authentication Scheme
      Identifier) of the EXT_AUTH header extension (Section 2.1);

   o  MUST communicate whether the anti-replay service is used or not
      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 out of the
   scope of this document.



Roca                      Expires April 2, 2012                 [Page 9]


Internet-Draft   Simple authentication for ALC and NORM   September 2011


2.3.  Processing

2.3.1.  Signature Processing

   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
   "Signature Cryptographic Function" can be used, like SHA-256.

   First, let us consider a packet sender.  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 length, 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.

   Now let us consider a receiver.  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 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 validates that the
   appropriate encoding was applied.  The two SHA-256 hashes are
   compared and if they are identical the validation is successful.




Roca                      Expires April 2, 2012                [Page 10]


Internet-Draft   Simple authentication for ALC and NORM   September 2011


2.3.2.  Anti-Replay Processing

   Let us assume the anti-replay service is used.  The principles are
   similar to the Sequence Number mechanism described in [RFC4303], 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 ([RFC4303], section
   2.2).  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 a 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 (i.e., 64 byte long)
   packets, cycling will happen after slightly more than 15 hours.

   At the receiver, the mechanism works as follows ([RFC4303], sections
   3.4.3 and A2).  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.

   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



Roca                      Expires April 2, 2012                [Page 11]


Internet-Draft   Simple authentication for ALC and NORM   September 2011


   fails, the receiver MUST discard the received packet as invalid,
   otherwise the receive window is updated and packet processing
   continues.

2.4.  In Practice

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


    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.

   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 byte long).  The
   Digital Signature EXT_AUTH header extension is then 132 byte long.







Roca                      Expires April 2, 2012                [Page 12]


Internet-Draft   Simple authentication for ALC and NORM   September 2011


3.  Elliptic Curve Digital Signature Scheme

3.1.  Authentication Header Extension Format

   The integration of ECC 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 EXT_AUTH==1
   header extension defined in [RFC5651].

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

   Figure 3: Format of the Digital Signature EXT_AUTH header extension.

   The fields of the Digital Signature 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.

   "Reserved" field (3 bits):

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

   "A" (Anti-replay) field (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.




Roca                      Expires April 2, 2012                [Page 13]


Internet-Draft   Simple authentication for ALC and NORM   September 2011


   "SN" (Sequence Number) field (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 32+8=40 bit
      field and all of the 40 bits MUST be considered by the anti-replay
      mechanism.

   "Signature" field (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.

3.2.  Parameters

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

   o  MUST communicate his 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 setup), 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 (Authentication Scheme
      Identifier) of the EXT_AUTH header extension (Section 2.1);

   o  MUST communicate whether the anti-replay service is used or not
      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 out of the
   scope of this document.







Roca                      Expires April 2, 2012                [Page 14]


Internet-Draft   Simple authentication for ALC and NORM   September 2011


3.3.  Processing

3.3.1.  Signature Processing

   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 Curves" 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 truncated the output is also feasible,
   however it consumes more processing power than is necessary.  The
   following table lists the RECOMMENDED choices [RFC4754] [RFC5480].

   +---------------------------+--------+------------------+-----------+
   |     Digital Signature     |   Key  |  Message Digest  |  Elliptic |
   |  Algorithm name [RFC4754] |  Size  |     Algorithm    |   Curve   |
   +---------------------------+--------+------------------+-----------+
   |         ECDSA-256         |   256  |      SHA-256     | secp256r1 |
   |                           |        |                  |           |
   |         ECDSA-384         |   384  |      SHA-384     | secp384r1 |
   |                           |        |                  |           |
   |         ECDSA-521         |   512  |      SHA-512     | secp521r1 |
   +---------------------------+--------+------------------+-----------+

   The ECDSA-256, ECDSA-384 and ECDSA-521 are designed to offer security
   comparable with AES-128, AES-192 and AES-256 respectively [RFC4754].

3.3.2.  Anti-Replay Processing

   The anti-replay processing follows the principles described in
   Section 2.3.2.

3.4.  In Practice

   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 MAY 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



Roca                      Expires April 2, 2012                [Page 15]


Internet-Draft   Simple authentication for ALC and NORM   September 2011


   valid sequence number.  All the packets that fail to contain a valid
   sequence number MUST be immediately dropped.


    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 4: Example: Format of the ECC Digital Signature EXT_AUTH
   header extension using ECDSA-256 signatures, without any anti-replay
                                protection.

   For instance Figure 4 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 byte long.

























Roca                      Expires April 2, 2012                [Page 16]


Internet-Draft   Simple authentication for ALC and NORM   September 2011


4.  Group Message Authentication Code (MAC) Scheme

4.1.  Authentication Header Extension Format

   The integration of Group MAC is similar in ALC and NORM and relies on
   the header extension mechanism defined in both protocols.  More
   precisely this document details the EXT_AUTH==1 header extension
   defined in [RFC5651].

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


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

       Figure 5: Format of the Group MAC EXT_AUTH header extension.

   The fields of the Group MAC 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.

   "Reserved" field (3 bits):

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

   "A" (Anti-replay) field (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.




Roca                      Expires April 2, 2012                [Page 17]


Internet-Draft   Simple authentication for ALC and NORM   September 2011


   "SN" (Sequence Number) field (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 32+8=40 bit
      field and all of the 40 bits MUST be considered by the anti-replay
      mechanism.

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

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

4.2.  Parameters

   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.  Because of security threats on SHA-1, the use of HMAC-SHA-
      256 is RECOMMENDED.  As a side effect, the receivers also know the
      key length and the non truncated MAC output length;

   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 left-most bits (most significant bits) of the MAC output
      are kept.  Of course, n_m MUST be lower 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 (Authentication Scheme
      Identifier) of the EXT_AUTH header extension (Section 4.1);

   o  MUST communicate whether the anti-replay service is used or not
      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 be often the case when periodic re-keying is
   required).  The details of this out-of-band mechanism are out of the
   scope of this document.



Roca                      Expires April 2, 2012                [Page 18]


Internet-Draft   Simple authentication for ALC and NORM   September 2011


4.3.  Processing

4.3.1.  Signature Processing

   The computation of the Group 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 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 MAC
   Authentication header.

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

   [RFC2104] 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 out of the scope of this document.

4.3.2.  Anti-Replay Processing

   The anti-replay processing follows the principles described in
   Section 2.3.2.

4.4.  In Practice

   Each packet sent MUST contain exactly one Group MAC EXT_AUTH header
   extension.  A receiver MUST drop packets that do not contain a Group
   MAC 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 Group MAC.  In
   that case the Group 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.










Roca                      Expires April 2, 2012                [Page 19]


Internet-Draft   Simple authentication for ALC and NORM   September 2011


    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 MAC (10 bytes)                     |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |            Padding            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 6: Example: Format of the Group MAC EXT_AUTH header extension
           using HMAC-SHA-1, without any anti-replay protection.

   For instance Figure 6 shows the Group MAC EXT_AUTH header extension
   when using HMAC-SHA-1.  The Group MAC EXT_AUTH header extension is
   then 16 byte long.

































Roca                      Expires April 2, 2012                [Page 20]


Internet-Draft   Simple authentication for ALC and NORM   September 2011


5.  Combined Use of the RSA/ECC Digital Signatures and Group MAC Schemes

5.1.  Authentication Header Extension Format

   The integration of combined RSA/ECC Digital Signature and Group MAC
   is similar in ALC and NORM and relies on the header extension
   mechanism defined in both protocols.  More precisely this document
   details the EXT_AUTH==1 header extension defined in [RFC5651].

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


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

       Figure 7: Format of the Group MAC EXT_AUTH header extension.

   The fields of the Group MAC 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.

   "Reserved" field (3 bits):

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

   "A" (Anti-replay) field (1 bit):





Roca                      Expires April 2, 2012                [Page 21]


Internet-Draft   Simple authentication for ALC and NORM   September 2011


      The "AR" field MUST be set to 1 and it indicates that the anti-
      replay service is used (see Section 5.3).

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

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

   "Signature" field (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 MAC" field (variable size, multiple of 32 bits, by default 32
   bits):

      The "Group MAC" field contains a truncated Group MAC of the
      message.

5.2.  Parameters

   Several parameters MUST be initialized by an out-of-band mechanism,
   as defined in Section 2.2, Section 3.2 and Section 4.2.

5.3.  Processing

   In some situations, it can be interesting to use both authentication
   schemes.  The goal of the Group MAC is to mitigate DoS attacks coming
   from attackers that are not group members [RFC4082] by adding a light
   authentication scheme as a front-end.

5.3.1.  Signature Processing

   Before sending a message, the sender sets the Signature field and
   Group MAC field to zero.  Then the sender computes the Signature as
   detailed in Section 2.3 or in Section 3.3 and stores the value in the
   Signature field.  Then the sender computes the Group MAC as detailed
   in Section 4.3 and stores the value in the Group MAC field.  The (RSA
   or ECC) digital signature value is therefore protected by the Group
   MAC, which avoids DoS attacks where the attacker corrupts the digital
   signature itself.

   Upon receiving the packet, the receiver first checks the Group MAC,
   as detailed in Section 4.3.  If the check fails, the packet MUST be
   immediately dropped.  Otherwise the receiver checks the Digital
   Signature, as detailed in Section 2.3.  If the check fails, the



Roca                      Expires April 2, 2012                [Page 22]


Internet-Draft   Simple authentication for ALC and NORM   September 2011


   packet MUST be immediately dropped.

   This scheme features a few limits:

   o  the Group 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 [RFC3711] section 9.5).  In the
      current specification, n_m MUST be a multiple of 32 bits, and
      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 be successfully forged is one in 2^32.
      Since the Group 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 MAC must be
   balanced against these limitations.

5.3.2.  Anti-Replay Processing

   The anti-replay processing follows the principles described in
   Section 2.3.2.  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.

5.4.  In Practice

   Each packet sent MUST contain exactly one combined Digital Signature/
   Group MAC EXT_AUTH header extension.  A receiver MUST drop packets
   that do not contain a combined Digital Signature/Group MAC 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 combined
   Digital Signature/Group MAC.  In that case the combined Digital
   Signature/Group 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



Roca                      Expires April 2, 2012                [Page 23]


Internet-Draft   Simple authentication for ALC and NORM   September 2011


   contain a valid sequence number MUST be immediately dropped.

   It is RECOMMENDED that the n_m parameter of the group authentication
   scheme be small, and by default equal to 32 bits (Section 5.3).


    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 MAC (32 bits)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---

   Figure 8: Example: Format of the combined RSA Digital Signature/Group
    MAC EXT_AUTH header extension using 1024 bit signatures, with anti-
                            replay protection.

   For instance Figure 8 shows the combined Digital Signature/Group MAC
   EXT_AUTH header extension when using 128 byte (1024 bit) key RSA
   digital signatures (which also means that the signature field is 128
   byte long).  The EXT_AUTH header extension is then 140 byte long.

















Roca                      Expires April 2, 2012                [Page 24]


Internet-Draft   Simple authentication for ALC and NORM   September 2011


6.  IANA Considerations

   This document does not require any IANA registration.
















































Roca                      Expires April 2, 2012                [Page 25]


Internet-Draft   Simple authentication for ALC and NORM   September 2011


7.  Security Considerations

7.1.  Dealing With DoS Attacks

   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 to compute 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 to use the
   combined Digital Signature/Group MAC scheme (Section 5.3).  However,
   no mitigation is possible if a group member acts as an attacker.
   Additionally, even if checking a Group MAC is significantly faster
   than checking a digital signature, there are practical limits on how
   many Group MAC can be checked per time unit.  Therefore it is
   RECOMMENDED to limit the number of authentication checks per time
   unit when the number of incoming packets that fail the authentication
   check exceeds a given threshold (i.e., in case of a DoS attack).

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

7.2.  Dealing With Replay Attacks

   Replay attacks consist for an attacker to store a valid message and
   to replay it later on.  It is RECOMMENDED to use the anti-replay
   service defined in this document with the signature and group MAC
   solutions, and this anti-replay service MUST be used in case of a
   combined use of signature and group MAC (see Section 5.3.2).

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

7.2.1.  Impacts of Replay Attacks on the Simple Authentication Schemes

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

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




Roca                      Expires April 2, 2012                [Page 26]


Internet-Draft   Simple authentication for ALC and NORM   September 2011


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

   NORM defines a "sequence" field that may be used to protect against
   replay attacks [RFC5740] 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 as
   an 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 field as an 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 participation 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 the
   "instance_id" be changed for each NORM instance.  It is also
   RECOMMENDED, when the Group MAC authentication/integrity check scheme
   is used, that the shared group key be changed across sessions.
   Therefore, NORM can be made robust in front of replay attacks across
   different sessions.

7.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  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: more precisely:

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

      *  Similarly, replaying a packet containing a "close object" (B
         flag) has no impact since this object is probably already



Roca                      Expires April 2, 2012                [Page 27]


Internet-Draft   Simple authentication for ALC and NORM   September 2011


         marked as closed by the receiver.

      *  Timing information sent as part of an LCT EXT_TIME header
         extension [RFC5651] 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 SCT (Sender Current Time) is
         easily identified if the receiver verifies that time progresses
         upon receiving such EXT_TIME header extensions.  Replaying a
         packet containing a SLC (Session Last Changed) 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 in front of 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's IP address;
   Transport Session Identifier (TSI)}.  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 large period of time preceding and following when
   the session is active [RFC5651].  Therefore, ALC can be made robust
   in front of replay attacks across different sessions.  Of course,
   when the Group MAC authentication/integrity check scheme is used, the
   shared group key SHOULD be changed across sessions if the set of
   receivers changes.

7.3.  Dealing With Attacks on the Parameters Sent Out-of-Band

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











Roca                      Expires April 2, 2012                [Page 28]


Internet-Draft   Simple authentication for ALC and NORM   September 2011


8.  Acknowledgments

   The author is grateful to the authors of [RFC4303], [RFC4359],
   [RFC4754] and [RFC5480] that inspired several sections of the present
   document.  The author is also grateful to David Harrington for his
   detailed IESG review of this document.













































Roca                      Expires April 2, 2012                [Page 29]


Internet-Draft   Simple authentication for ALC and NORM   September 2011


9.  References

9.1.  Normative References

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

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

   [RFC5651]  Luby, M., Watson, M., and L. Vicisano, "Layered Coding
              Transport (LCT) Building Block", RFC 5651, October 2009.

   [RFC5740]  Adamson, B., Bormann, C., Handley, M., and J. Macker,
              "NACK-Oriented Reliable Multicast (NORM) Transport
              Protocol", RFC 5740, November 2009.

   [RFC5775]  Luby, M., Watson, M., and L. Vicisano, "Asynchronous
              Layered Coding (ALC) Protocol Instantiation", RFC 5775,
              April 2010.

9.2.  Informative References

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

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

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, December 2005.

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

   [RFC4754]  Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using
              the Elliptic Curve Digital Signature Algorithm (ECDSA)",
              RFC 4754, January 2007.




Roca                      Expires April 2, 2012                [Page 30]


Internet-Draft   Simple authentication for ALC and NORM   September 2011


   [RFC5480]  Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
              "Elliptic Curve Cryptography Subject Public Key
              Information", RFC 5480, March 2009.

   [RFC5776]  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", RFC 5776,
              April 2010.

   [RMT-FLUTE]
              Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen,
              "FLUTE - File Delivery over Unidirectional Transport",
              Work in Progress, February 2011.





































Roca                      Expires April 2, 2012                [Page 31]


Internet-Draft   Simple authentication for ALC and NORM   September 2011


Author's Address

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

   Email: vincent.roca@inria.fr
   URI:   http://planete.inrialpes.fr/people/roca/








































Roca                      Expires April 2, 2012                [Page 32]