RMT V. Roca
Internet-Draft INRIA
Intended status: Experimental October 27, 2008
Expires: April 30, 2009
Simple Authentication Schemes for the ALC and NORM Protocols
draft-ietf-rmt-simple-auth-for-alc-norm-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 30, 2009.
Roca Expires April 30, 2009 [Page 1]
Internet-Draft TESLA in ALC and NORM October 2008
Abstract
This document introduces two schemes that provide a per-packet
authentication and integrity service in the context of the ALC and
NORM protocols. The first scheme is based on digital signatures.
Because it relies on asymmetric cryptography, this scheme generates a
high processing load at the sender and to a lesser extent at a
receiver, as well as a significant transmission overhead. It is
therefore well suited to low data rate sessions. The second scheme
relies on a group Message Authentication Code (MAC). Because this
scheme relies symmetric cryptography, MAC calculation and
verification are fast operations, which makes it suited to high data
rate sessions. However it only provides a group authentication and
integrity service, which means that it only protects against
attackers that are not group members.
Roca Expires April 30, 2009 [Page 2]
Internet-Draft TESLA in ALC and NORM October 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 5
1.2. Conventions Used in this Document . . . . . . . . . . . . 6
1.3. Terminology and Notations . . . . . . . . . . . . . . . . 6
2. RSA-Based Digital Signature Scheme . . . . . . . . . . . . . . 8
2.1. Principles . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3. Authentication Header Extension Format . . . . . . . . . . 9
2.4. In Practice . . . . . . . . . . . . . . . . . . . . . . . 10
3. Group Message Authentication Code (MAC) Scheme . . . . . . . . 12
3.1. Principles . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3. Authentication Header Extension Format . . . . . . . . . . 13
3.4. In Practice . . . . . . . . . . . . . . . . . . . . . . . 14
4. Combined Use of the Digital Signatures and Group MAC
Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Principles . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3. Authentication Header Extension Format . . . . . . . . . . 16
4.4. In Practice . . . . . . . . . . . . . . . . . . . . . . . 17
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6.1. Dealing With DoS Attacks . . . . . . . . . . . . . . . . . 20
6.2. Dealing With Replay Attacks . . . . . . . . . . . . . . . 20
6.2.1. Impacts of Replay Attacks on the Simple
Authentication Schemes . . . . . . . . . . . . . . . . 20
6.2.2. Impacts of Replay Attacks on NORM . . . . . . . . . . 20
6.2.3. Impacts of Replay Attacks on ALC . . . . . . . . . . . 21
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.1. Normative References . . . . . . . . . . . . . . . . . . . 24
8.2. Informative References . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . . . 27
Roca Expires April 30, 2009 [Page 3]
Internet-Draft TESLA in ALC and NORM October 2008
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 check its integrity. For instance, ALC
[RMT-PI-ALC] and NORM [RMT-PI-NORM] 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. Each
receiver acknowledges data received or, in case of packet erasures,
asks for retransmissions. On the opposite, the ALC protocol defines
unidirectional transmissions. 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]: this scheme is well suited to low
data rate flows, when a true packet sender authentication and
packet integrity service is needed. However, digital signatures
based on RSA asymmetric cryptography is limited by high
computational costs and high transmission overheads. The use of
ECC ("Elliptic Curve Cryptography") significantly relaxes these
constraints, especially when seeking for higher security levels.
For instance, the following key sizes 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): this scheme is well
suited to high data rate flows, when transmission overheads must
be minimized. However this scheme cannot protect against attacks
Roca Expires April 30, 2009 [Page 4]
Internet-Draft TESLA in ALC and NORM October 2008
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][MSEC-TESLA]: this scheme is well suited to high data
rate flows, when transmission overheads must be minimized, and
when a true 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.
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 | | |
+----------------+-------------+--------------+-------------+-------+
| True auth and | Yes | Yes | No (group | Yes |
| integrity | | | security) | |
| | | | | |
| Immediate auth | Yes | Yes | Yes | No |
| | | | | |
| Processing | - | 0 | + | + |
| load | | | | |
| | | | | |
| 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.3, Section 3.3, Section 4.3) and [MSEC-TESLA],
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.
1.1. Scope of this Document
[MSEC-TESLA] explains how to use TESLA in the context of ALC and NORM
protocols.
Roca Expires April 30, 2009 [Page 5]
Internet-Draft TESLA in ALC and NORM October 2008
The current document specifies the use of the first two schemes,
namely the Digital Signature based on RSA asymmetric cryptography 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).
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 [RFC3926] 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 3.2.
1.2. Conventions Used in this Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1.3. Terminology and Notations
The following notations and definitions are used throughout this
document:
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;
Digital signature related notations and definitions:
o K_pub is 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;
Roca Expires April 30, 2009 [Page 6]
Internet-Draft TESLA in ALC and NORM October 2008
o K_priv is the private key used by a sender to generate a packet's
signature;
o n_k is the private key and public key length, in bits. n_k is also
the signature length, since both values are equal with digital
signatures;
Group MAC related notations and definitions:
o K_g is a 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 n_k is the group key length, 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 30, 2009 [Page 7]
Internet-Draft TESLA in ALC and NORM October 2008
2. RSA-Based Digital Signature Scheme
2.1. Principles
The computation of the digital signature, using K_priv, 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.
Upon receiving this packet, the receiver recomputes the Group MAC,
using K_pub, and compares it to the value carried in the packet.
During this computation, the Weak Group MAC field MUST also be set to
0. If the check fails, the packet MUST be immediately dropped.
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 size, which in
practice is also equal to the "RSA modulus", has major security
implications. [RFC4359] explains how to choose this value depending
on the maximum expected lifetime of the session. This choice is out
of the scope of this document.
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
Roca Expires April 30, 2009 [Page 8]
Internet-Draft TESLA in ALC and NORM October 2008
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.
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, n_k, 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.3);
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.
2.3. 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 [RMT-BB-LCT].
Several fields are added in addition to the HET (Header Extension
Type) and HEL (Header Extension Length) fields (Figure 1).
Roca Expires April 30, 2009 [Page 9]
Internet-Draft TESLA in ALC and NORM October 2008
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| 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 (12 bits):
This is a reserved field that MUST be set to zero in this
specification.
"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.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.
Roca Expires April 30, 2009 [Page 10]
Internet-Draft TESLA in ALC and NORM October 2008
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| | ^ 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.
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 30, 2009 [Page 11]
Internet-Draft TESLA in ALC and NORM October 2008
3. Group Message Authentication Code (MAC) Scheme
3.1. Principles
The computation of the Group MAC, using K_g, 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 recomputes the Group MAC,
using K_g, 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.
3.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, n_k, 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 n_k;
o MUST communicate the K_g 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 3.3);
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
Roca Expires April 30, 2009 [Page 12]
Internet-Draft TESLA in ALC and NORM October 2008
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.
3.3. 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 [RMT-BB-LCT].
Several fields are added in addition to the HET (Header Extension
Type) and HEL (Header Extension Length) fields (Figure 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 | ASID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| Group MAC |
+ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: 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 (12 bits):
This is a reserved field that MUST be set to zero in this
specification.
"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.
Roca Expires April 30, 2009 [Page 13]
Internet-Draft TESLA in ALC and NORM October 2008
3.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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Group MAC (10 bytes) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Example: Format of the Group MAC EXT_AUTH header extension
using HMAC-SHA-1.
For instance Figure 4 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 30, 2009 [Page 14]
Internet-Draft TESLA in ALC and NORM October 2008
4. Combined Use of the Digital Signatures and Group MAC Schemes
4.1. Principles
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.
More specifically, 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.1 and stores the
value in the Signature field. Then the sender computes the Group MAC
as detailed in Section 3.1 and stores the value in the Group MAC
field. The 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 3.1. If the check fails, the packet MUST be
immediately dropped. Otherwise the receiver checks the Digital
Signature, as detailed in Section 2.1. If the check fails, the
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 K_g)
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.
Roca Expires April 30, 2009 [Page 15]
Internet-Draft TESLA in ALC and NORM October 2008
4.2. Parameters
Several parameters MUST be initialized by an out-of-band mechanism,
as defined in Section 2.2 and Section 3.2.
4.3. Authentication Header Extension Format
The integration of Combined Digital Signature/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 [RMT-BB-LCT].
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| Signature |
+ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group MAC |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 (12 bits):
This is a reserved field that MUST be set to zero in this
specification.
"Signature" field (variable size, multiple of 32 bits):
Roca Expires April 30, 2009 [Page 16]
Internet-Draft TESLA in ALC and NORM October 2008
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.
4.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.
It is RECOMMENDED that the n_m parameter of the group authentication
scheme be small, and by default equal to 32 bits (Section 4.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 (=34) | ASID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| | ^ 1
+ + | 2
| | | 8
. . |
. Signature (128 bytes) . | b
. . | y
| | | t
+ + | e
| | v s
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| Group MAC (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
Figure 6: Example: Format of the Combined Digital Signature/Group MAC
EXT_AUTH header extension using 1024 bit signatures.
For instance Figure 6 shows the combined Digital Signature/Group MAC
Roca Expires April 30, 2009 [Page 17]
Internet-Draft TESLA in ALC and NORM October 2008
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 EXT_AUTH header extension is then 136 byte long.
Roca Expires April 30, 2009 [Page 18]
Internet-Draft TESLA in ALC and NORM October 2008
5. IANA Considerations
This document does not require any IANA registration.
Roca Expires April 30, 2009 [Page 19]
Internet-Draft TESLA in ALC and NORM October 2008
6. Security Considerations
6.1. Dealing With DoS Attacks
Digital signatures introduces new opportunities for an attacker to
mount DoS attacks. For instance an attacker can try to saturate the
processing capabilities of the receiver (faked packets are easy to
create but checking them requires to compute a costly digital
signature).
In order to mitigate these attacks, it is RECOMMENDED to use the
Combined Digital Signature/Group MAC scheme (Section 4.1). However,
no mitigation is possible if a group member acts as an attacker.
6.2. Dealing With Replay Attacks
Replay attacks, consist for an attacker to store a valid message and
to replay it later on.
6.2.1. Impacts of Replay Attacks on the Simple Authentication Schemes
Since all the above authentication schemes are memoryless, replay
attacks have no impact.
6.2.2. Impacts of Replay Attacks on NORM
We review here the potential impacts of a replay attack on the NORM
component. Note that we do not consider here the protocols that
could be used along with NORM, for instance the congestion control
protocols.
First, let us consider replay attacks within a given NORM session.
NORM defines a "sequence" field that can be used to protect against
replay attacks [RMT-PI-NORM] within a given NORM session. This
"sequence" field is a 16-bit value that is set by the message
originator (sender or receiver) as a monotonically increasing number
incremented with each NORM message transmitted. It is RECOMMENDED
that a receiver check this sequence field and drop messages
considered as replayed. Similarly, it is RECOMMENDED that a sender
check this sequence, for each known receiver, and drop messages
considered as replayed. In both cases, checking this sequence field
SHOULD be done before authenticating the packet: if the sequence
field has not been corrupted, the replay attack will immediately be
identified, and otherwise the packet will fail the authentication
test. This analysis shows that NORM itself is robust in front of
replay attacks within the same session.
Now let us consider replay attacks across several NORM sessions. A
Roca Expires April 30, 2009 [Page 20]
Internet-Draft TESLA in ALC and NORM October 2008
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, K_g, be changed across sessions.
Therefore, NORM can be made robust in front of replay attacks across
different sessions.
6.2.3. Impacts of Replay Attacks on ALC
We review here the potential impacts of a replay attack on the ALC
component. Note that we do not consider here the protocols that
could be used along with ALC, for instance the layered or wave based
congestion control protocols.
First, let us consider replay attacks within a given ALC session:
o Regular packets containing an authentication tag: a replayed
message containing an encoding symbol will be detected once
authenticated, thanks to the object/block/symbol identifiers, and
will be silently discarded. This kind of replay attack is only
penalizing in terms of memory and processing load, but does not
compromise the ALC behavior.
o Control packets containing an authentication tag: ALC control
packets, by definition, do not include any encoding symbol and
therefore do not include any object/block/symbol identifier that
would enable a receiver to identify duplicates. However, a sender
has a very limited number of reasons to send control packets.
More precisely:
* At the end of the session, a "close session" (A flag) packet is
sent. Replaying this packet has no impact since the receivers
already left.
* Similarly, replaying a packet containing a "close object" (B
flag) has no impact since this object is probably already
marked as closed by the receiver.
This analysis shows that ALC itself is robust in front of replay
attacks within the same session.
Now let us consider replay attacks across several ALC sessions. An
ALC session is uniquely identified by the {sender's IP address;
Transport Session Identifier (TSI)} [RMT-BB-LCT]. 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
Roca Expires April 30, 2009 [Page 21]
Internet-Draft TESLA in ALC and NORM October 2008
Group MAC authentication/integrity check scheme is used, that the
shared group key, K_g, be changed across sessions. Therefore, ALC
can be made robust in front of replay attacks across different
sessions.
Roca Expires April 30, 2009 [Page 22]
Internet-Draft TESLA in ALC and NORM October 2008
7. Acknowledgments
TBD
Roca Expires April 30, 2009 [Page 23]
Internet-Draft TESLA in ALC and NORM October 2008
8. References
8.1. Normative References
[MSEC-TESLA]
Adamson, B., Bormann, C., Handley, M., and J. Macker, "Use
of TESLA in the ALC and NORM Protocols",
draft-ietf-msec-tesla-for-alc-norm-06.txt (work in
progress), October 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B.
Briscoe, "Timed Efficient Stream Loss-Tolerant
Authentication (TESLA): Multicast Source Authentication
Transform Introduction", RFC 4082, June 2005.
[RMT-BB-LCT]
Luby, M., Watson, M., and L. Vicisano, "Layered Coding
Transport (LCT) Building Block",
draft-ietf-rmt-bb-lct-revised-07.txt (work in progress),
July 2008.
[RMT-PI-ALC]
Luby, M., Watson, M., and L. Vicisano, "Asynchronous
Layered Coding (ALC) Protocol Instantiation",
draft-ietf-rmt-pi-alc-revised-05.txt (work in progress),
November 2007.
[RMT-PI-NORM]
Adamson, B., Bormann, C., Handley, M., and J. Macker,
"Negative-acknowledgment (NACK)-Oriented Reliable
Multicast (NORM) Protocol",
draft-ietf-rmt-pi-norm-revised-07.txt (work in progress),
October 2008.
8.2. Informative References
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Roca Expires April 30, 2009 [Page 24]
Internet-Draft TESLA in ALC and NORM October 2008
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC3926] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh,
"FLUTE - File Delivery over Unidirectional Transport",
RFC 3926, October 2004.
[RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within
Encapsulating Security Payload (ESP) and Authentication
Header (AH)", RFC 4359, January 2006.
Roca Expires April 30, 2009 [Page 25]
Internet-Draft TESLA in ALC and NORM October 2008
Author's Address
Vincent Roca
INRIA
655, av. de l'Europe
Zirst; Montbonnot
ST ISMIER cedex 38334
France
Email: vincent.roca@inria.fr
URI: http://planete.inrialpes.fr/~roca/
Roca Expires April 30, 2009 [Page 26]
Internet-Draft TESLA in ALC and NORM October 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Roca Expires April 30, 2009 [Page 27]
