One document matched: draft-ietf-rmt-simple-auth-for-alc-norm-04.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>
<rfc category="exp" ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev='Simple authentication for ALC and NORM'>
Simple Authentication Schemes for the ALC and NORM Protocols
</title>
<author initials='V.R.' surname="Roca" fullname='Vincent Roca'>
<organization>INRIA</organization>
<address>
<postal>
<street>655, av. de l'Europe</street>
<street>Inovallee; Montbonnot</street>
<city>ST ISMIER cedex</city>
<code>38334</code>
<country>France</country>
</postal>
<email>vincent.roca@inria.fr</email>
<uri>http://planete.inrialpes.fr/people/roca/</uri>
</address>
</author>
<date day="8" month="July" year="2011"/>
<area>Transport</area>
<workgroup>RMT</workgroup>
<keyword>TESLA</keyword>
<keyword>FLUTE</keyword>
<keyword>ALC</keyword>
<keyword>NORM</keyword>
<abstract>
<t>
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 group schemes.
These schemes have different target use cases and they do not all provide the same
service.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<!-- ==================================== -->
<t>
Many applications using multicast and broadcast communications
require that each receiver be able to authenticate the source of any
packet it receives to check its integrity.
For instance, ALC <xref target="RFC5775"/> and NORM <xref target="RFC5740"/>
are two Content Delivery Protocols (CDP) designed to transfer reliably
objects (e.g. files) between a session's sender and several receivers.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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:
<list style='symbols'>
<t>digital signatures <xref target="RFC4359"/>
(see <xref target="sec_dig_rsa_sig"/> and <xref target="sec_dig_ecc_sig"/>):
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.
<!--
For instance, the following key length provide equivalent
security:
<texttable>
<ttcol align="center">Symmetric Key Size</ttcol>
<ttcol align="center">RSA Key Size</ttcol>
<ttcol align="center">ECC Key Size</ttcol>
<c>80 bits</c>
<c>1024 bits</c>
<c>160 bits</c>
<c>112 bits</c>
<c>2048 bits</c>
<c>224 bits</c>
</texttable>
-->
</t>
<t>group Message Authentication Codes (MAC)
(see <xref target="sec_group_mac"/>):
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.
</t>
<t>TESLA (Timed Efficient Stream Loss-tolerant Authentication)
<xref target="RFC4082"/><xref target="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)
</t>
</list>
</t>
<t>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):</t>
<texttable>
<ttcol align="left"></ttcol>
<ttcol align="center">RSA Digital Signature</ttcol>
<ttcol align="center">ECC Digital Signature</ttcol>
<ttcol align="center">Group MAC</ttcol>
<ttcol align="center">TESLA</ttcol>
<c>Sender auth and packet integrity</c>
<c>Yes</c>
<c>Yes</c>
<c>No (group security)</c>
<c>Yes</c>
<c>Non delayed authentication</c>
<c>Yes</c>
<c>Yes</c>
<c>Yes</c>
<c>No</c>
<c>Anti-replay protection</c>
<c>Opt</c>
<c>Opt</c>
<c>Opt</c>
<c>No</c>
<c>Processing load</c>
<c>-</c>
<c>0</c>
<c>+</c>
<c>+</c>
<c>Transmission overhead</c>
<c>-</c>
<c>0</c>
<c>+</c>
<c>+</c>
<c>Complexity</c>
<c>+</c>
<c>+</c>
<c>+</c>
<c>-</c>
</texttable>
<t>
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
(<xref target="sec:signature_auth_he_format"/>, <xref target="sec:group_mac_auth_he_format"/>,
<xref target="sec:combined_auth_he_format"/>) and <xref target="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 group members
by an out-of-band mechanism.
</t>
<t>
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
<xref target="RMT-FLUTE"/> built on top of ALC.
</t>
<t>
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 <xref target="signature_params"/> and
<xref target="group_mac_params"/>.
</t>
<section title="Scope of this Document">
<!-- ------------------------------------ -->
<t>
<xref target="RFC5776"/> explains how to
use TESLA in the context of ALC and NORM protocols.
</t>
<t>
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.
</t>
<t>
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).
</t>
</section>
<section title="Terminology, Notations and Definitions">
<!-- ------------------------------------ -->
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in <xref target="RFC2119"/>.
</t>
<t>
The following notations and definitions are used throughout this document:
<list style='symbols'>
<t>MAC is the Message Authentication Code;</t>
<t>HMAC is the Keyed-Hash Message Authentication Code;</t>
<t>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;</t>
<t>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;</t>
</list>
</t>
<t>
Digital signature related definitions:
<list style='symbols'>
<t>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;</t>
<t>the private key used by a sender to generate a packet's signature;</t>
<t>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;</t>
</list>
</t>
<t>
Group MAC related definitions:
<list style='symbols'>
<t>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;</t>
<t>the group key length is expressed in bits;</t>
<t>n_m is the length of the truncated output of the MAC <xref target="RFC2104"/>.
Only the n_m left-most bits (most significant bits) of the MAC
output are kept;</t>
</list>
</t>
</section>
</section><!-- =Introduction= -->
<!-- ======================================================================= -->
<section title="RSA Digital Signature Scheme" anchor="sec_dig_rsa_sig">
<!-- ==================================== -->
<section title="Authentication Header Extension Format" anchor="sec:signature_auth_he_format">
<!-- ------------------------------------ -->
<t>
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 <xref target="RFC5651"/>.
</t>
<!--
<t>
<list><t>----- Editor's note:
All authentication schemes using the EXT_AUTH header extension MUST
reserve the same 4 bit "ASID" field after the HET/HEL fields.
This way, several authentication schemes can be used in the same ALC
or NORM session, even on the same communication path.
-----</t>
</list>
</t>
-->
<t>
Several fields are added in addition to the HET (Header Extension Type) and HEL
(Header Extension Length) fields (<xref target="fig:signature_lct_integration"/>).
</t>
<t>
<figure title="Format of the Digital Signature EXT_AUTH header extension."
anchor="fig:signature_lct_integration">
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (=1) | HEL | ASID | rsvd|A| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ anti-replay Sequence Number (SN) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| Signature |
+ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</t>
<t>
The fields of the Digital Signature EXT_AUTH header extension are:</t>
<t>"ASID" (Authentication Scheme Identifier) field (4 bits):</t>
<t><list><t>
The "ASID" identifies the source authentication scheme or protocol
in use.
The association between the "ASID" value and the actual authentication
scheme is defined out-of-band, at session startup.
</t></list></t>
<t>"Reserved" field (3 bits):</t>
<t><list><t>
This is a reserved field that MUST be set to zero in this specification.
</t></list></t>
<t>"A" (Anti-replay) field (1 bit):</t>
<t><list><t>
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.
</t></list></t>
<t>"SN" (Sequence Number) field (8 or 40 bits):</t>
<t><list><t>
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.
</t></list></t>
<t>"Signature" field (variable size, multiple of 32 bits):</t>
<t><list><t>
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.
</t></list></t>
</section>
<section title="Parameters" anchor="signature_params">
<!-- ------------------------------------ -->
<t>
Several parameters MUST be initialized by an out-of-band mechanism.
The sender or group controller:
<list style='symbols'>
<t> 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;</t>
<t> 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;</t>
<t> MUST communicate the Signature Encoding Algorithm.
For instance, <xref target="RFC3447"/> defines the
RSASSA-PKCS1-v1_5 and RSASSA-PSS algorithms that are usually
used to that purpose;</t>
<t> 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;</t>
<t> MUST associate a value to the "ASID" field
(Authentication Scheme Identifier) of the EXT_AUTH header extension
(<xref target="sec:signature_auth_he_format"/>);</t>
<t> MUST communicate whether the anti-replay service is used
or not for this session;</t>
</list>
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.
</t>
</section>
<section title="Processing" anchor="sec:signature_principles">
<!-- ------------------------------------ -->
<section title="Signature Processing" anchor="sec:signature_processing_principles">
<!-- ------------------------------------ -->
<t>
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.
</t>
<t>
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.
</t>
<t>
First, let us consider a packet sender.
More specifically, from <xref target="RFC4359"/>:
digital signature generation is performed as described in
<xref target="RFC3447"/>, Section 8.2.1 for RSASSA-PKCS1-v1_5 and
Section 8.1.1 for RSASSA-PSS.
The authenticated portion of the packet is used as the message M,
which is passed to the signature generation function.
The signer's RSA private key is passed as K.
In summary (when SHA-256 is used), the signature generation process computes
a SHA-256 hash of the authenticated packet bytes, signs the SHA-256 hash using
the private key, and encodes the result with the specified RSA encoding type.
This process results in a value S, which is the digital signature to
be included in the packet.
</t>
<t>
With RSASSA-PKCS1-v1_5 and RSASSA-PSS signatures,
the size of the signature is equal to the "RSA modulus", unless the "RSA modulus"
is not a multiple of 8 bits. In that case, the signature MUST be prepended with
between 1 and 7 bits set to zero such that the signature is a multiple of 8 bits
<xref target="RFC4359"/>.
The key length, which in practice is also equal to the "RSA modulus", has major security
implications.
<xref target="RFC4359"/> explains how to choose this value depending on the maximum
expected lifetime of the session.
This choice is out of the scope of this document.
</t>
<t>
Now let us consider a receiver.
From <xref target="RFC4359"/>:
Digital signature verification is performed as described in
<xref target="RFC3447"/>, Section 8.2.2 (RSASSA-PKCS1-v1_5) and
<xref target="RFC3447"/>, Section 8.1.2 (RSASSA-PSS).
Upon receipt, the digital signature is passed to the
verification function as S.
The authenticated portion of the packet is used as the message M,
and the RSA public key is passed as (n, e).
In summary (when SHA-256 is used), the verification function computes a SHA-256
hash of the authenticated packet bytes, decrypts the SHA-256 hash in
the packet 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.
</t>
</section>
<section title="Anti-Replay Processing" anchor="sec:signature_anti_replay_processing_principles">
<!-- ------------------------------------ -->
<t>
Let us assume the anti-replay service is used.
The principles are similar to the Sequence Number mechanism described
in <xref target="RFC4303"/>, with the exception that the present document
uses a 40 bit field that contains all the bits of the sequence number counter.
</t>
<t>
At the sender, the mechanism works as follows (<xref target="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.
</t>
<t>
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.
</t>
<t>
At the receiver, the mechanism works as follows (<xref target="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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
</section>
<section title="In Practice"
anchor="sec:signature_auth_he_use">
<!-- ------------------------------------ -->
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
<figure anchor="fig:signature_auth_he_with_1024b_sig"
title="Example: Format of the Digital Signature EXT_AUTH header extension
using 1024 bit signatures, without any anti-replay protection.">
<preamble></preamble>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (=1) | HEL (=33) | ASID | 0 |0| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| | ^ 1
+ + | 2
| | | 8
. . |
. Signature (128 bytes) . | b
. . | y
| | | t
+ + | e
| | v s
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
</artwork>
</figure>
</t>
<t>
For instance <xref target="fig:signature_auth_he_with_1024b_sig"/> 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.
</t>
</section>
</section><!-- =Digital Signature Scheme= -->
<!-- ======================================================================= -->
<section title="Elliptic Curve Digital Signature Scheme" anchor="sec_dig_ecc_sig">
<!-- ==================================== -->
<section title="Authentication Header Extension Format" anchor="sec:ecc_signature_auth_he_format">
<!-- ------------------------------------ -->
<t>
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 <xref target="RFC5651"/>.
</t>
<!--
<t>
<list><t>----- Editor's note:
All authentication schemes using the EXT_AUTH header extension MUST
reserve the same 4 bit "ASID" field after the HET/HEL fields.
This way, several authentication schemes can be used in the same ALC
or NORM session, even on the same communication path.
-----</t>
</list>
</t>
-->
<t>
Several fields are added in addition to the HET (Header Extension Type) and HEL
(Header Extension Length) fields (<xref target="fig:signature_lct_integration"/>).
</t>
<t>
<figure title="Format of the Digital Signature EXT_AUTH header extension."
anchor="fig:ecc_signature_lct_integration">
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (=1) | HEL | ASID | rsvd|A| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ anti-replay Sequence Number (SN) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| Signature |
+ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</t>
<t>
The fields of the Digital Signature EXT_AUTH header extension are:</t>
<t>"ASID" (Authentication Scheme Identifier) field (4 bits):</t>
<t><list><t>
The "ASID" identifies the source authentication scheme or protocol
in use.
The association between the "ASID" value and the actual authentication
scheme is defined out-of-band, at session startup.
</t></list></t>
<t>"Reserved" field (3 bits):</t>
<t><list><t>
This is a reserved field that MUST be set to zero in this specification.
</t></list></t>
<t>"A" (Anti-replay) field (1 bit):</t>
<t><list><t>
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.
</t></list></t>
<t>"SN" (Sequence Number) field (8 or 40 bits):</t>
<t><list><t>
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.
</t></list></t>
<t>"Signature" field (variable size, multiple of 32 bits):</t>
<t><list><t>
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.
</t></list></t>
</section>
<section title="Parameters" anchor="ecc_signature_params">
<!-- ------------------------------------ -->
<t>
Several parameters MUST be initialized by an out-of-band mechanism.
The sender or group controller:
<list style='symbols'>
<t> 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;</t>
<t> 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;</t>
<t> MUST communicate the Message Digest Algorithm;</t>
<t> MUST communicate the Elliptic Curve;</t>
<t> MUST associate a value to the "ASID" field
(Authentication Scheme Identifier) of the EXT_AUTH header extension
(<xref target="sec:signature_auth_he_format"/>);</t>
<t> MUST communicate whether the anti-replay service is used
or not for this session;</t>
</list>
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.
</t>
</section>
<section title="Processing" anchor="sec:ecc_signature_principles">
<!-- ------------------------------------ -->
<section title="Signature Processing" anchor="sec:ecc_signature_processing_principles">
<!-- ------------------------------------ -->
<t>
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.
</t>
<t>
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 <xref target="RFC4754"/>
<xref target="RFC5480"/>.
</t>
<texttable>
<ttcol align="center">Digital Signature Algorithm name [RFC4754]</ttcol>
<ttcol align="center">Key Size</ttcol>
<ttcol align="center">Message Digest Algorithm</ttcol>
<ttcol align="center">Elliptic Curve</ttcol>
<c>
ECDSA-256
</c>
<c>
256
</c>
<c>
SHA-256
</c>
<c>
secp256r1
</c>
<c>
ECDSA-384
</c>
<c>
384
</c>
<c>
SHA-384
</c>
<c>
secp384r1
</c>
<c>
ECDSA-521
</c>
<c>
512
</c>
<c>
SHA-512
</c>
<c>
secp521r1
</c>
</texttable>
<t>
The ECDSA-256, ECDSA-384 and ECDSA-521 are designed to offer security
comparable with AES-128, AES-192 and AES-256 respectively <xref target="RFC4754"/>.
</t>
</section>
<section title="Anti-Replay Processing" anchor="sec:ecc_signature_anti_replay_processing_principles">
<!-- ------------------------------------ -->
<t>
The anti-replay processing follows the principles described in <xref target="sec:signature_anti_replay_processing_principles"/>.
</t>
</section>
</section>
<section title="In Practice"
anchor="sec:ecc_signature_auth_he_use">
<!-- ------------------------------------ -->
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
<figure anchor="fig:ecc_signature_auth_he_with_256b_sig"
title="Example: Format of the ECC Digital Signature EXT_AUTH header extension
using ECDSA-256 signatures, without any anti-replay protection.">
<preamble></preamble>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (=1) | HEL (=9) | ASID | 0 |0| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| | ^ 3
+ + | 2
. . |
. Signature (32 bytes) . | b
. . | y
| | | t
+ + | e
| | v s
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
</artwork>
</figure>
</t>
<t>
For instance <xref target="fig:ecc_signature_auth_he_with_256b_sig"/> 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.
</t>
</section>
</section><!-- Elliptic Curve Digital Signature Scheme= -->
<!-- ======================================================================= -->
<section title="Group Message Authentication Code (MAC) Scheme" anchor="sec_group_mac">
<!-- ==================================== -->
<section title="Authentication Header Extension Format" anchor="sec:group_mac_auth_he_format">
<!-- ------------------------------------ -->
<t>
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 <xref target="RFC5651"/>.
</t>
<!--
<t>
<list><t>----- Editor's note:
All authentication schemes using the EXT_AUTH header extension MUST
reserve the same 4 bit "ASID" field after the HET/HEL fields.
This way, several authentication schemes can be used in the same ALC
or NORM session, even on the same communication path.
-----</t>
</list>
</t>
-->
<t>
Several fields are added in addition to the HET (Header Extension Type) and HEL
(Header Extension Length) fields (<xref target="fig:group_mac_lct_integration"/>).
</t>
<t>
<figure title="Format of the Group MAC EXT_AUTH header extension."
anchor="fig:group_mac_lct_integration">
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (=1) | HEL | ASID | rsvd|A| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ anti-replay Sequence Number (SN) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| Group MAC |
+ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</t>
<t>
The fields of the Group MAC EXT_AUTH header extension are:</t>
<t>"ASID" (Authentication Scheme Identifier) field (4 bits):</t>
<t><list><t>
The "ASID" identifies the source authentication scheme or protocol
in use.
The association between the "ASID" value and the actual authentication
scheme is defined out-of-band, at session startup.
</t></list></t>
<t>"Reserved" field (3 bits):</t>
<t><list><t>
This is a reserved field that MUST be set to zero in this specification.
</t></list></t>
<t>"A" (Anti-replay) field (1 bit):</t>
<t><list><t>
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.
</t></list></t>
<t>"SN" (Sequence Number) field (8 or 40 bits):</t>
<t><list><t>
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.
</t></list></t>
<t>"Group MAC" field (variable size, multiple of 32 bits):</t>
<t><list><t>
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.
</t></list></t>
</section>
<section title="Parameters" anchor="group_mac_params">
<!-- ------------------------------------ -->
<t>
Several parameters MUST be initialized by an out-of-band mechanism.
The sender or group controller:
<list style='symbols'>
<t> 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;
</t>
<t> 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;</t>
<t> MUST communicate the group key to the receivers, confidentially, before
starting the session.
This key might have to be periodically refreshed for improved robustness;
</t>
<t> MUST associate a value to the "ASID" field
(Authentication Scheme Identifier) of the EXT_AUTH header extension
(<xref target="sec:group_mac_auth_he_format"/>);</t>
<t> MUST communicate whether the anti-replay service is used
or not for this session;</t>
</list>
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.
</t>
</section>
<section title="Processing" anchor="sec:group_mac_principles">
<!-- ------------------------------------ -->
<section title="Signature Processing" anchor="sec:group_mac_processing_principles">
<!-- ------------------------------------ -->
<t>
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.
</t>
<t>
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.
</t>
<t>
<xref target="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.
</t>
</section>
<section title="Anti-Replay Processing" anchor="sec:group_mac_anti_replay_processing_principles">
<!-- ------------------------------------ -->
<t>
The anti-replay processing follows the principles described in <xref target="sec:signature_anti_replay_processing_principles"/>.
</t>
</section>
</section>
<section title="In Practice"
anchor="sec:group_mac_auth_he_use">
<!-- ------------------------------------ -->
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
<figure anchor="fig:group_mac_auth_he_with_1024b_sig"
title="Example: Format of the Group MAC EXT_AUTH header extension
using HMAC-SHA-1, without any anti-replay protection.">
<preamble></preamble>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (=1) | HEL (=4) | ASID | 0 |0| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Group MAC (10 bytes) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</t>
<t>
For instance <xref target="fig:group_mac_auth_he_with_1024b_sig"/> 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.
</t>
</section>
</section><!-- =Group MAC Scheme= -->
<!-- ======================================================================= -->
<section title="Combined Use of the RSA/ECC Digital Signatures and Group MAC Schemes">
<!-- ==================================== -->
<section title="Authentication Header Extension Format" anchor="sec:combined_auth_he_format">
<!-- ------------------------------------ -->
<t>
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 <xref target="RFC5651"/>.
</t>
<!--
<t>
<list><t>----- Editor's note:
All authentication schemes using the EXT_AUTH header extension MUST
reserve the same 4 bit "ASID" field after the HET/HEL fields.
This way, several authentication schemes can be used in the same ALC
or NORM session, even on the same communication path.
-----</t>
</list>
</t>
-->
<t>
Several fields are added in addition to the HET (Header Extension Type) and HEL
(Header Extension Length) fields (<xref target="fig:combined_lct_integration"/>).
</t>
<t>
<figure title="Format of the Group MAC EXT_AUTH header extension."
anchor="fig:combined_lct_integration">
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (=1) | HEL | ASID | rsvd|A| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| anti-replay Sequence Number (SN) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| Signature |
+ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group MAC |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</t>
<t>
The fields of the Group MAC EXT_AUTH header extension are:</t>
<t>"ASID" (Authentication Scheme Identifier) field (4 bits):</t>
<t><list><t>
The "ASID" identifies the source authentication scheme or protocol
in use.
The association between the "ASID" value and the actual authentication
scheme is defined out-of-band, at session startup.
</t></list></t>
<t>"Reserved" field (3 bits):</t>
<t><list><t>
This is a reserved field that MUST be set to zero in this specification.
</t></list></t>
<t>"A" (Anti-replay) field (1 bit):</t>
<t><list><t>
The "AR" field MUST be set to 1 and it indicates that the anti-replay service is used
(see <xref target="sec:combined_use_principles"/>).
</t></list></t>
<t>"SN" (Sequence Number) field (8 or 40 bits):</t>
<t><list><t>
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.
</t></list></t>
<t>"Signature" field (variable size, multiple of 32 bits):</t>
<t><list><t>
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.
</t></list></t>
<t>"Group MAC" field (variable size, multiple of 32 bits, by default 32 bits):</t>
<t><list><t>
The "Group MAC" field contains a truncated Group MAC of the message.
</t></list></t>
</section>
<section title="Parameters" anchor="combined_params">
<!-- ------------------------------------ -->
<t>
Several parameters MUST be initialized by an out-of-band mechanism, as
defined in <xref target="signature_params"/>,
<xref target="ecc_signature_params"/> and <xref target="group_mac_params"/>.
</t>
</section>
<section title="Processing" anchor="sec:combined_use_principles">
<!-- ------------------------------------ -->
<t>
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 <xref target="RFC4082"/> by adding a light authentication
scheme as a front-end.
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.
</t>
<section title="Signature Processing" anchor="sec:combined_processing_principles">
<!-- ------------------------------------ -->
<t>
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 <xref target="sec:signature_principles"/>
or in <xref target="sec:ecc_signature_principles"/> and stores the value in the Signature field.
Then the sender computes the Group MAC as detailed in <xref target="sec:group_mac_principles"/>
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.
</t>
<t>
Upon receiving the packet, the receiver first checks the Group MAC, as
detailed in <xref target="sec:group_mac_principles"/>.
If the check fails, the packet MUST be immediately dropped.
Otherwise the receiver checks the Digital Signature, as detailed
in <xref target="sec:signature_principles"/>.
If the check fails, the packet MUST be immediately dropped.
</t>
<t>
This scheme features a few limits:
<list style='symbols'>
<t>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;</t>
<t>it requires an additional MAC computing for each packet,
both at the sender and receiver sides;</t>
<t>it increases the size of the authentication headers.
In order to limit this problem, the length of the truncated output of the
MAC, n_m, SHOULD be kept small (see <xref target="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.</t>
</list>
For a given use-case, the benefits brought by the Group MAC must be balanced
against these limitations.
</t>
</section>
<section title="Anti-Replay Processing" anchor="sec:combined_anti_replay_processing_principles">
<!-- ------------------------------------ -->
<t>
The anti-replay processing follows the principles described in <xref target="sec:signature_anti_replay_processing_principles"/>.
</t>
</section>
</section>
<section title="In Practice"
anchor="sec:combined_use_auth_he_use">
<!-- ------------------------------------ -->
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
It is RECOMMENDED that the n_m parameter of the group authentication
scheme be small, and by default equal to 32 bits
(<xref target="sec:combined_use_principles"/>).
</t>
<t>
<figure anchor="fig:combined_auth_he_with_1024b_sig"
title="Example: Format of the combined RSA Digital Signature/Group MAC EXT_AUTH header extension
using 1024 bit signatures, with anti-replay protection.">
<preamble></preamble>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (=1) | HEL (=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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
</artwork>
</figure>
</t>
<t>
For instance <xref target="fig:combined_auth_he_with_1024b_sig"/> 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.
</t>
</section>
</section>
<!-- ======================================================================= -->
<section title="IANA Considerations" anchor="sec:iana">
<!-- ==================================== -->
<t>This document does not require any IANA registration.</t>
</section>
<section title="Security Considerations">
<!-- ==================================== -->
<section title="Dealing With DoS Attacks">
<!-- =================================== -->
<t>
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.
</t>
<t>
In order to mitigate these attacks, it is RECOMMENDED to use the combined
Digital Signature/Group MAC scheme (<xref target="sec:combined_use_principles"/>).
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).
</t>
<t>
The RECOMMENDATION to limit the number of checks per time unit under (presumed) attack
situations can be extended to the other authentication schemes.
</t>
</section>
<section title="Dealing With Replay Attacks">
<!-- =================================== -->
<t>
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.
</t>
<t>
The following section details some of the potential consequences of not using the
anti-replay protection.
</t>
<section title="Impacts of Replay Attacks on the Simple Authentication Schemes">
<!-- =================================== -->
<t>
Since all the above authentication schemes are stateless, replay attacks
have no impact on these schemes.
</t>
</section>
<section title="Impacts of Replay Attacks on NORM">
<!-- =================================== -->
<t>
We review here the potential impacts of a replay attack on the NORM component.
Note that we do not consider here the protocols that could be used along with
NORM, for instance the congestion control protocols.
</t>
<t>
First, let us consider replay attacks within a given NORM session.
NORM being a stateful protocol, replaying a packet may have consequences.
</t>
<t>
NORM defines a "sequence" field that may be used to protect against
replay attacks <xref target="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.
</t>
<t>
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.
</t>
</section>
<section title="Impacts of Replay Attacks on ALC">
<!-- =================================== -->
<t>
We review here the potential impacts of a replay attack on the ALC component.
Note that we do not consider here the protocols that could be used along with
ALC, for instance the layered or wave based congestion control protocols.
</t>
<t>
First, let us consider replay attacks within a given ALC session:
<list style='symbols'>
<t>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.
</t>
<t>replayed control information:
more precisely:
<list style='symbols'>
<t>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.</t>
<t>Similarly, replaying a packet containing a "close object" (B flag)
has no impact since this object is probably already marked as closed
by the receiver.</t>
<t>
Timing information sent as part of an LCT EXT_TIME header extension
<xref target="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.
</t>
</list>
</t>
</list>
This analysis shows that ALC MAY 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.
</t>
<t>
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)} <xref target="RFC5651"/>.
Therefore, when a given sender creates several sessions, it is
RECOMMENDED that the TSI be changed for each ALC 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, ALC can be made robust in front of replay attacks across different
sessions.
</t>
</section>
</section>
<section title="Dealing With Attacks on the Parameters Sent Out-of-Band">
<!-- =================================== -->
<t>
This specification requires several parameters to be communicated to
the receiver(s)
<xref target="signature_params"/>
<xref target="ecc_signature_params"/>
<xref target="group_mac_params"/>
<xref target="combined_params"/>
<xref target="RFC5776"/>
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 <xref target="intro"/>.
Since this mapping is critical, it is REQUIRED that this information be carried in a secure
way from the sender to the receiver(s).
</t>
</section>
</section>
<section title="Acknowledgments">
<!-- ==================================== -->
<t>
The author is grateful to the authors of <xref target="RFC4303"/>, <xref target="RFC4359"/>,
<xref target="RFC4754"/> and <xref target="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.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<!-- ==================================== -->
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner">
<organization />
</author>
<date month="March" year="1997" />
</front>
<seriesInfo name="RFC" value="2119" />
<seriesInfo name="BCP" value="14" />
</reference>
<?rfc include='reference.RFC.5775'?>
<reference anchor="RFC5651">
<front>
<title>Layered Coding Transport (LCT) Building Block</title>
<author initials='M.' surname='Luby'>
<organization />
</author>
<author initials="M." surname="Watson">
<organization/>
</author>
<author initials='L.' surname='Vicisano'>
<organization />
</author>
<date month="October" year="2009"/>
</front>
<seriesInfo name="RFC" value="5651" />
</reference>
<?rfc include='reference.RFC.5740'?>
<reference anchor="RFC2104">
<front>
<title abbrev="HMAC">HMAC: Keyed-Hashing for Message Authentication</title>
<author initials="H." surname="Krawczyk" fullname="Hugo Krawczyk">
<organization>IBM, T.J. Watson Research Center</organization>
</author>
<author initials="M." surname="Bellare" fullname="Mihir Bellare">
<organization>University of California at San Diego, Dept of Computer Science and Engineering</organization>
</author>
<author initials="R." surname="Canetti" fullname="Ran Canetti">
<organization>IBM T.J. Watson Research Center</organization>
</author>
<date year="1997" month="February"/>
</front>
<seriesInfo name="RFC" value="2104"/>
<format type="TXT" octets="22297" target="ftp://ftp.isi.edu/in-notes/rfc2104.txt"/>
</reference>
</references>
<references title="Informative References">
<!-- ==================================== -->
<?rfc include='reference.RFC.4303'?>
<reference anchor="RFC4082">
<front>
<title>Timed Efficient Stream Loss-Tolerant Authentication (TESLA):
Multicast Source Authentication Transform Introduction
</title>
<author initials="A." surname="Perrig" fullname="A. Perrig">
<organization/></author>
<author initials="D." surname="Song" fullname="D. Song">
<organization/></author>
<author initials="R." surname="Canetti" fullname="R. Canetti">
<organization/></author>
<author initials="J.D." surname="Tygar" fullname="J.D. Tygar">
<organization/></author>
<author initials="B." surname="Briscoe" fullname="B. Briscoe">
<organization/></author>
<date year="2005" month="June"/>
</front>
<seriesInfo name="RFC" value="4082"/>
<format type="TXT" octets="54316" target="ftp://ftp.isi.edu/in-notes/rfc4082.txt"/>
</reference>
<?rfc include='reference.RFC.5776'?>
<reference anchor="RMT-FLUTE">
<front>
<title>FLUTE - File Delivery over Unidirectional Transport</title>
<author initials="T." surname="Paila" fullname="T. Paila">
<organization/></author>
<author initials="R." surname="Walsh" fullname="R. Walsh">
<organization/></author>
<author initials="M." surname="Luby" fullname="M. Luby">
<organization/></author>
<author initials="R." surname="Lehtonen" fullname="R. Lehtonen">
<organization/></author>
<author initials="V." surname="Roca" fullname="V. Roca">
<organization/></author>
<date year="2010" month="March"/>
</front>
<seriesInfo name="Work in" value="Progress"/>
</reference>
<reference anchor="RFC3711">
<front>
<title>The Secure Real-time Transport Protocol (SRTP)</title>
<author initials="M." surname="Baugher" fullname="M. Baugher"><organization/></author>
<author initials="D." surname="McGrew" fullname="D. McGrew"><organization/></author>
<author initials="M." surname="Naslund" fullname="M. Naslund"><organization/></author>
<author initials="E." surname="Carrara" fullname="E. Carrara"><organization/></author>
<author initials="K." surname="Norrman" fullname="K. Norrman"><organization/></author>
<date year="2004" month="March"/>
</front>
<seriesInfo name="RFC" value="3711"/>
<format type="TXT" octets="134270" target="ftp://ftp.isi.edu/in-notes/rfc3711.txt"/>
</reference>
<reference anchor="RFC4359">
<front>
<title>
The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH)
</title>
<author initials="B." surname="Weis" fullname="B. Weis"><organization/></author>
<date year="2006" month="January"/>
</front>
<seriesInfo name="RFC" value="4359"/>
<format type="TXT" octets="26989" target="ftp://ftp.isi.edu/in-notes/rfc4359.txt"/>
</reference>
<reference anchor="RFC3447">
<front>
<title>Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1</title>
<author initials="J." surname="Jonsson" fullname="J. Jonsson"> <organization/> </author>
<author initials="B." surname="Kaliski" fullname="B. Kaliski"> <organization/> </author>
<date year="2003" month="February"/>
</front>
<seriesInfo name="RFC" value="3447"/>
<format type="TXT" octets="143173" target="ftp://ftp.isi.edu/in-notes/rfc3447.txt"/>
</reference>
<reference anchor='RFC4754'>
<front>
<title>IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA)</title>
<author initials='D.' surname='Fu' fullname='D. Fu'> <organization /></author>
<author initials='J.' surname='Solinas' fullname='J. Solinas'> <organization /></author>
<date year='2007' month='January' />
</front>
<seriesInfo name='RFC' value='4754' />
<format type='TXT' octets='27948' target='ftp://ftp.isi.edu/in-notes/rfc4754.txt' />
</reference>
<reference anchor="RFC5480">
<front>
<title>Elliptic Curve Cryptography Subject Public Key Information</title>
<author initials='S.' surname='Turner' fullname='S. Turner'> <organization /></author>
<author initials='D.' surname='Brown' fullname='D. Brown'> <organization /></author>
<author initials='K.' surname='Yiu' fullname='K. Yiu'> <organization /></author>
<author initials='R.' surname='Housley' fullname='R. Housley'> <organization /></author>
<author initials='T.' surname='Polk' fullname='T. Polk'> <organization /></author>
<date year='2009' month='March' />
</front>
<seriesInfo name='RFC' value='5480' />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 05:30:01 |