RMT V. Roca Internet-Draft INRIA Intended status: Standards Track December 9, 2011 Expires: June 11, 2012 Simple Authentication Schemes for the ALC and NORM Protocols draft-ietf-rmt-simple-auth-for-alc-norm-06 Abstract This document introduces four schemes that provide per-packet authentication, integrity and anti-replay services in the context of the ALC and NORM protocols. The first scheme is based on RSA digital signatures. The second scheme relies on the Elliptic Curve Digital Signature Algorithm (ECDSA). The third scheme relies on a group- keyed Message Authentication Code (MAC). Finally, the fourth scheme merges the digital signature and group schemes. These schemes have different target use cases and they do not all provide the same service. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 11, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Roca Expires June 11, 2012 [Page 1] Internet-Draft Simple authentication for ALC and NORM December 2011 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Roca Expires June 11, 2012 [Page 2] Internet-Draft Simple authentication for ALC and NORM December 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 7 1.2. Terminology, Notations and Definitions . . . . . . . . . . 7 2. Authentication Scheme Identification with the ASID Field . . . 9 3. RSA Digital Signature Scheme . . . . . . . . . . . . . . . . . 10 3.1. Authentication Header Extension Format . . . . . . . . . . 10 3.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3. Processing . . . . . . . . . . . . . . . . . . . . . . . . 12 3.3.1. Signature Processing . . . . . . . . . . . . . . . . . 12 3.3.2. Anti-Replay Processing . . . . . . . . . . . . . . . . 13 3.4. In Practice . . . . . . . . . . . . . . . . . . . . . . . 14 4. Elliptic Curve Digital Signature Scheme . . . . . . . . . . . 15 4.1. Authentication Header Extension Format . . . . . . . . . . 15 4.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . . 16 4.3. Processing . . . . . . . . . . . . . . . . . . . . . . . . 16 4.3.1. Signature Processing . . . . . . . . . . . . . . . . . 16 4.3.2. Anti-Replay Processing . . . . . . . . . . . . . . . . 17 4.4. In Practice . . . . . . . . . . . . . . . . . . . . . . . 17 5. Group-Keyed Message Authentication Code (MAC) Scheme . . . . . 19 5.1. Authentication Header Extension Format . . . . . . . . . . 19 5.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . . 20 5.3. Processing . . . . . . . . . . . . . . . . . . . . . . . . 21 5.3.1. Signature Processing . . . . . . . . . . . . . . . . . 21 5.3.2. Anti-Replay Processing . . . . . . . . . . . . . . . . 21 5.4. In Practice . . . . . . . . . . . . . . . . . . . . . . . 21 6. Combined Use of the RSA/ECC Digital Signatures and group-keyed MAC Schemes . . . . . . . . . . . . . . . . . . . 23 6.1. Authentication Header Extension Format . . . . . . . . . . 23 6.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . . 24 6.3. Processing . . . . . . . . . . . . . . . . . . . . . . . . 24 6.3.1. Signature Processing . . . . . . . . . . . . . . . . . 24 6.3.2. Anti-Replay Processing . . . . . . . . . . . . . . . . 25 6.4. In Practice . . . . . . . . . . . . . . . . . . . . . . . 25 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 8.1. Dealing With DoS Attacks . . . . . . . . . . . . . . . . . 28 8.2. Dealing With Replay Attacks . . . . . . . . . . . . . . . 28 8.2.1. Impacts of Replay Attacks on the Simple Authentication Schemes . . . . . . . . . . . . . . . . 28 8.2.2. Impacts of Replay Attacks on NORM . . . . . . . . . . 28 8.2.3. Impacts of Replay Attacks on ALC . . . . . . . . . . . 29 8.3. Dealing With Attacks on the Parameters Sent Out-of-Band . 30 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 10.1. Normative References . . . . . . . . . . . . . . . . . . . 32 10.2. Informative References . . . . . . . . . . . . . . . . . . 32 Roca Expires June 11, 2012 [Page 3] Internet-Draft Simple authentication for ALC and NORM December 2011 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 34 Roca Expires June 11, 2012 [Page 4] Internet-Draft Simple authentication for ALC and NORM December 2011 1. Introduction Many applications using multicast and broadcast communications require that each receiver be able to authenticate the source of any packet it receives to check its integrity. For instance, ALC [RFC5775] and NORM [RFC5740] are two Content Delivery Protocols (CDP) designed to reliably transfer objects (e.g. files) between a session's sender and several receivers. The NORM protocol is based on bidirectional transmissions. With NORM each receiver acknowledges data received or, in case of packet erasures, asks for retransmissions. On the opposite, the ALC protocol defines unidirectional transmissions. With ALC, reliability can be achieved by means of cyclic transmissions of the content within a carousel, or by the use of proactive Forward Error Correction codes (FEC), or by the joint use of these mechanisms. Being purely unidirectional, ALC is massively scalable, while NORM is intrinsically limited in terms of the number of receivers that can be handled in a session. Both protocols have in common the fact that they operate at application level, on top of an erasure channel (e.g. the Internet) where packets can be lost (erased) during the transmission. With these CDP, an attacker might impersonate the ALC or NORM session sender and inject forged packets to the receivers, thereby corrupting the objects reconstructed by the receivers. An attacker might also impersonate a NORM session receiver and inject forged feedback packets to the NORM sender. In case of group communications, several solutions exist to provide the receiver some guaranties on the integrity of the packets it receives and on the identity of the sender of these packets. These solutions have different features that make them more or less suited to a given use case: o digital signatures [RFC4359] (see Section 3 and Section 4): 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") [RFC6090] 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. However RSA puts more load on the signer but much much less on the verifier, whereas ECC puts more similar load on both and hence with many verifiers more CPU is consumed overall. Roca Expires June 11, 2012 [Page 5] Internet-Draft Simple authentication for ALC and NORM December 2011 o group-keyed Message Authentication Codes (MAC) (see Section 5): this scheme is well suited to high data rate flows, when transmission overheads must be minimized. However this scheme cannot protect against attacks coming from inside the group, where a group member impersonates the sender and sends forged messages to other receivers. o TESLA (Timed Efficient Stream Loss-tolerant Authentication) [RFC4082][RFC5776]: this scheme is well suited to high data rate flows, when transmission overheads must be minimized, and when a packet sender authentication and packet integrity service is needed. The price to pay is an increased complexity, in particular the need to loosely synchronize the receivers and the sender, as well as the need to wait for the key to be disclosed before being able to authenticate a packet (i.e. the authentication check is delayed) The following table summarizes the pros/cons of each authentication/ integrity scheme used at application/transport level (where "-" means bad, "0" means neutral, and "+" means good): +-----------------+-------------+-------------+-------------+-------+ | | RSA Digital | ECC Digital | Group-Keyed | TESLA | | | Signature | Signature | MAC | | +-----------------+-------------+-------------+-------------+-------+ | Sender auth and | Yes | Yes | No (group | Yes | | packet | | | security) | | | integrity | | | | | | | | | | | | Non delayed | Yes | Yes | Yes | No | | authentication | | | | | | | | | | | | Anti-replay | Opt | Opt | Opt | No | | protection | | | | | | | | | | | | Processing load | - | sender: -, | + | + | | | | recv: 0 | | | | | | | | | | Transmission | - | 0 | + | + | | overhead | | | | | | | | | | | | Complexity | + | + | + | - | +-----------------+-------------+-------------+-------------+-------+ Several authentication schemes MAY be used in the same ALC or NORM session, even on the same communication path. This is made possible through a dedicated identifier, "ASID" (Authentication Scheme IDentifier), that is present in each HET=1 (EXT_AUTH) header Roca Expires June 11, 2012 [Page 6] Internet-Draft Simple authentication for ALC and NORM December 2011 extension and that tells a receiver how to interpret this HET=1 header extension. This is discussed in Section 2. All the applications built on top of ALC and NORM directly benefit from the source authentication and packet integrity services defined in this document. For instance this is the case of the FLUTE application [RMT-FLUTE] built on top of ALC. The current specification assumes that several parameters (like keying material) are communicated out-of-band, sometimes securely, between the sender and the receivers. This is detailed in Section 3.2, Section 4.2, Section 5.2, and Section 6.2. 1.1. Scope of this Document [RFC5776] explains how to use TESLA in the context of ALC and NORM protocols. The current document specifies the use of the Digital Signature based on RSA asymmetric cryptography, the Elliptic Curve Digital Signature Algorithm (ECDSA) and group-keyed MAC schemes. The current document also specifies the joint use of Digital Signature and group-keyed MAC schemes. Unlike the TESLA scheme, this specification considers the authentication/integrity of the packets generated by the session's sender as well as those generated by the receivers (NORM). 1.2. Terminology, Notations and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The following notations and definitions are used throughout this document: o MAC is the Message Authentication Code; o HMAC is the Keyed-Hash Message Authentication Code; o sender denotes the sender of a packet that needs the authentication/integrity check service. It can be an ALC or NORM session sender, or a NORM session receiver in case of feedback traffic; o receiver denotes the receiver of a packet that needs the authentication/integrity check service. It can be an ALC or NORM Roca Expires June 11, 2012 [Page 7] Internet-Draft Simple authentication for ALC and NORM December 2011 session receiver, or a NORM session sender in case of feedback traffic; o ASID is the Authentication Scheme IDentifier; Key definitions for Digital signatures: o the public key is used by a receiver to check a packet's signature. This key MUST be communicated to all receivers, before starting the session; o the private key is used by a sender to generate a packet's signature; o the private key and public key length are expressed in bits. For security considerations [RFC5751], when using RSA, RSASSA-PSS, and DSA signatures, key sizes of length strictly inferior to 1024 bits SHOULD NOT be used. Key sizes of length between 1024 and 2048 bits, inclusive, SHOULD be used. Key sizes of length strictly superior to 2048 MAY be used. Keys definitions for Group-keyed MAC: o the shared group key is used by the senders and the receivers. This key MUST be communicated to all group members, confidentially, before starting the session; o the group key length is expressed in bits; o n_m is the length of the truncated output of the MAC [RFC2104]. Only the n_m left-most bits (most significant bits) of the MAC output are kept; Roca Expires June 11, 2012 [Page 8] Internet-Draft Simple authentication for ALC and NORM December 2011 2. Authentication Scheme Identification with the ASID Field As mentioned in Section 1, several authentication schemes MAY be used in the same ALC or NORM session, even on the same communication path (i.e., from a sender to a receiver, or vice-versa). All the schemes mentioned in Section 1 (some of them being specified in this document) use the same HET=1 (EXT_AUTH) authentication header extension mechanism defined in [RFC5651]. Therefore, the same 4-bit ASID (Authentication Scheme IDentifier) field has been reserved in all the specifications (see Section 3.1, Section 5.1, Section 6.1 and [RFC5776], section 5.1). For a given ALC or NORM session, the ASID value contained in an incoming packet enables a receiver to differentiate the actual use and format of the contents of the HET=1 (EXT_AUTH) header extension. The association between the ASID value and the actual authentication scheme of a given ALC or NORM session is defined at session startup and communicated to all the session members by an out-of-band mechanism. This association is per ALC or NORM session, and different sessions MAY reuse the same ASID values for different authentication schemes. With ALC, the ASID value is scoped by the {sender IP address; TSI} tuple [RFC5651] that fully identifies an ALC session. Since [RFC5651] requires that "the TSI MUST be unique among all sessions served by the sender during the period when the session is active, and for a large period of time preceding and following when the session is active", there is no risk of confusion between different sessions. This is in line with Section 8.2.3. With NORM, there is no session identifier within NORM packets. Therefore, depending on whether an Any Source Multicast (ASM) or Source Specific Multicast (SSM) group communication is used, the ASID value is scoped either by the {destination multicast address; destination port number} or {source IP address; destination multicast address; destination port number} tuple that fully identifies a NORM session [RFC5740]. Care should be taken that the above tuples remain unique, within a given scope and for a sufficient period of time preceding, during and following when the session is active, to avoid confusion between different sessions. However, this is a recommendation for NORM sessions, rather than something specific to an authentication scheme. Note also that the ASID value is not scoped by the {"source_id"; "instance_id"} tuple, which uniquely identifies a host participation in a NORM session, rather than the session itself Section 8.2.2. In any case, because this ASID field is 4-bit long, there is a maximum of 16 authentication schemes per ALC or NORM session. Roca Expires June 11, 2012 [Page 9] Internet-Draft Simple authentication for ALC and NORM December 2011 3. RSA Digital Signature Scheme 3.1. Authentication Header Extension Format The integration of Digital Signatures is similar in ALC and NORM and relies on the header extension mechanism defined in both protocols. More precisely this document details the HET=1 (EXT_AUTH) header extension defined in [RFC5651]. Several fields are added in addition to the HET (Header Extension Type) and HEL (Header Extension Length) fields (Figure 1). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HET (=1) | HEL | ASID | rsvd|A| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ anti-replay Sequence Number (SN) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | Signature | + +-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Format of the Digital Signature EXT_AUTH header extension. The fields of the Digital Signature EXT_AUTH header extension are: "ASID" (Authentication Scheme IDentifier) field (4 bits): The "ASID" identifies the source authentication scheme or protocol in use. The association between the "ASID" value and the actual authentication scheme is defined out-of-band, at session startup. "Reserved" field (3 bits): This is a reserved field that MUST be set to zero and ignored by receivers. "A" (Anti-replay) field (1 bit): The "AR" field, when set to 0, indicates that the anti-replay service is not used. When set to 1, it indicates that the anti- replay service is used. Roca Expires June 11, 2012 [Page 10] Internet-Draft Simple authentication for ALC and NORM December 2011 "SN" (Sequence Number) field (8 or 40 bits): The "SN" field contains an optional sequence number. When AR=0, this is an 8 bit field that MUST be set to zero. No anti-replay mechanism is used in that case. When AR=1, this is a 32+8=40 bit field and all of the 40 bits MUST be considered by the anti-replay mechanism. "Signature" field (variable size, multiple of 32 bits): The "Signature" field contains a digital signature of the message. If need be, this field is padded (with 0) up to a multiple of 32 bits. 3.2. Parameters Several parameters MUST be initialized by an out-of-band mechanism. The sender or group controller: o MUST communicate his public key, for each receiver to be able to verify the signature of the packets received. For security reasons [RFC5751], the use of key sizes between 1024 and 2048 inclusive is RECOMMENDED. Key sizes inferior to 1024 SHOULD NOT be used. Key sizes above 2048 MAY be used. As a side effect, the receivers also know the key length and the signature length, the two parameters being equal; o MAY communicate a certificate (which also means that a PKI has been 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 One-way Hash Function, for instance SHA-1, SHA-224, SHA-256, SHA-384, or SHA-512. Because of security threats on SHA-1, the use of SHA-256 is RECOMMENDED [RFC6194]; o MUST associate a value to the "ASID" field (Authentication Scheme IDentifier) of the EXT_AUTH header extension (Section 3.1); o MUST communicate whether the anti-replay service is used or not for this session; These parameters MUST be communicated to all receivers before they can authenticate the incoming packets. For instance it can be communicated in the session description, or initialized in a static Roca Expires June 11, 2012 [Page 11] Internet-Draft Simple authentication for ALC and NORM December 2011 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. 3.3. Processing 3.3.1. Signature Processing The computation of the digital signature, using the private key, MUST include the ALC or NORM header (with the various header extensions) and the payload when applicable. The UDP/IP/MAC headers MUST NOT be included. During this computation, the "Signature" field MUST be set to 0. Several "Signature Encoding Algorithms" can be used, including RSASSA-PKCS1-v1_5 and RSASSA-PSS. With these encodings, several "One-way Hash Function" can be used, like SHA-256. First, let us consider a packet sender. More specifically, from [RFC4359]: digital signature generation is performed as described in [RFC3447], Section 8.2.1 for RSASSA-PKCS1-v1_5 and Section 8.1.1 for RSASSA-PSS. The authenticated portion of the packet is used as the message M, which is passed to the signature generation function. The signer's RSA private key is passed as K. In summary (when SHA-256 is used), the signature generation process computes a SHA-256 hash of the authenticated packet bytes, signs the SHA-256 hash using the private key, and encodes the result with the specified RSA encoding type. This process results in a value S, which is the digital signature to be included in the packet. With RSASSA-PKCS1-v1_5 and RSASSA-PSS signatures, the size of the signature is equal to the "RSA modulus", unless the "RSA modulus" is not a multiple of 8 bits. In that case, the signature MUST be prepended with between 1 and 7 bits set to zero such that the signature is a multiple of 8 bits [RFC4359]. The key length, which in practice is also equal to the "RSA modulus", has major security implications. [RFC4359] explains how to choose this value depending on the maximum expected lifetime of the session. This choice is out of the scope of this document. Now let us consider a receiver. From [RFC4359]: Digital signature verification is performed as described in [RFC3447], Section 8.2.2 (RSASSA-PKCS1-v1_5) and [RFC3447], Section 8.1.2 (RSASSA-PSS). Upon receipt, the digital signature is passed to the verification function as S. The authenticated portion of the packet is used as the message M, and the RSA public key is passed as (n, e). In summary (when SHA- 256 is used), the verification function computes a SHA-256 hash of the authenticated packet bytes, decrypts the SHA-256 hash in the Roca Expires June 11, 2012 [Page 12] Internet-Draft Simple authentication for ALC and NORM December 2011 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. 3.3.2. Anti-Replay Processing Let us assume the anti-replay service is used. The principles are similar to the Sequence Number mechanism described in [RFC4303], with the exception that the present document uses a 40 bit field that contains all the bits of the sequence number counter. At the sender, the mechanism works as follows ([RFC4303], section 2.2). The sender's sequence number counter is initialized to 0 at session startup. The sender increments the Sequence Number counter for this session and inserts the value into the SN field. Thus, the first packet sent will contain a SN of 1. The SN value of the Authentication Header Extension MUST be initialized before the signature generation process, in order to enable a receiver to check the SN value during the integrity verification process. The sender SHOULD ensure that the counter does not cycle before inserting the new value in the SN field. Failing to follow this rule would enable an attacker to replay a packet sent during the previous cycle, i.e., it would limit the anti-replay service to a single SN cycle. Since the sequence number is contained in a 40 bit field, it is expected that cycling will never happen in most situations. For instance, on a 10 Gbps network, with small (i.e., 64 byte long) packets, cycling will happen after slightly more than 15 hours. At the receiver, the mechanism works as follows ([RFC4303], sections 3.4.3 and A2). For each received packet, the receiver MUST verify that the packet contains a Sequence Number that does not duplicate the Sequence Number of any other packets received during the session. If this preliminary check fails, the packet is discarded, thus avoiding the need for any cryptographic operations by the receiver. If the preliminary check is successful, the receiver cannot yet modify its local counter, because the integrity of the Sequence Number has not been verified at this point. Duplicates are rejected through the use of a sliding receive window. The "right" edge of the window represents the highest, validated Sequence Number value received on this session. Packets that contain sequence numbers lower than the "left" edge of the window are rejected. Packets falling within the window are checked against a list of received packets within the window (how this list is managed is a local, implementation based decision). This window limits how far out of order a packet can be, relative to the packet with the highest sequence number that has been authenticated so far. Roca Expires June 11, 2012 [Page 13] Internet-Draft Simple authentication for ALC and NORM December 2011 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. 3.4. In Practice Each packet sent MUST contain exactly one Digital Signature EXT_AUTH header extension. A receiver MUST drop all the packets that do not contain a Digital Signature EXT_AUTH header extension. All receivers MUST recognize EXT_AUTH but MAY not be able to parse its content, for instance because they do not support digital signatures. In that case the Digital Signature EXT_AUTH header extension is ignored. If the anti-replay mechanism is used, each packet sent MUST contain a valid sequence number. All the packets that fail to contain a valid sequence number MUST be immediately dropped. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HET (=1) | HEL (=33) | ASID | 0 |0| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- | | ^ 1 + + | 2 | | | 8 . . | . Signature (128 bytes) . | b . . | y | | | t + + | e | | v s +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- Figure 2: Example: Format of the Digital Signature EXT_AUTH header extension using 1024 bit signatures, without any anti-replay protection. For instance Figure 2 shows the digital signature EXT_AUTH header extension when using 128 byte (1024 bit) key digital signatures (which also means that the signature field is 128 byte long). The Digital Signature EXT_AUTH header extension is then 132 byte long. Roca Expires June 11, 2012 [Page 14] Internet-Draft Simple authentication for ALC and NORM December 2011 4. Elliptic Curve Digital Signature Scheme This document focuses on the Elliptic Curve Digital Signature Algorithm (ECDSA). However [RFC6090] describes alternative Elliptic Curve techniques, like KT-I Signatures. The use of such alternatives is not considered in this document, but may be added in the future. 4.1. Authentication Header Extension Format The integration of ECC Digital Signatures is similar to that of RSA Digital Signatures. Several fields are added in addition to the HET (Header Extension Type) and HEL (Header Extension Length) fields, as illustrated in Figure 1. The fields of the Digital Signature EXT_AUTH header extension are: "ASID" (Authentication Scheme IDentifier) field (4 bits): The "ASID" identifies the source authentication scheme or protocol in use. The association between the "ASID" value and the actual authentication scheme is defined out-of-band, at session startup. "Reserved" field (3 bits): This is a reserved field that MUST be set to zero and ignored by receivers. "A" (Anti-replay) field (1 bit): The "AR" field, when set to 0, indicates that the anti-replay service is not used. When set to 1, it indicates that the anti- replay service is used. "SN" (Sequence Number) field (8 or 40 bits): The "SN" field contains an optional sequence number. When AR=0, this is an 8 bit field that MUST be set to zero. No anti-replay mechanism is used in that case. When AR=1, this is a 32+8=40 bit field and all of the 40 bits MUST be considered by the anti-replay mechanism. "Signature" field (variable size, multiple of 32 bits): The "Signature" field contains a digital signature of the message. If need be, this field is padded (with 0) up to a multiple of 32 bits. Roca Expires June 11, 2012 [Page 15] Internet-Draft Simple authentication for ALC and NORM December 2011 4.2. Parameters Several parameters MUST be initialized by an out-of-band mechanism. The sender or group controller: o MUST communicate his public key, for each receiver to be able to verify the signature of the packets received. As a side effect, the receivers also know the key length and the signature length, the two parameters being equal; o MAY communicate a certificate (which also means that a PKI has been setup), for each receiver to be able to check the sender's public key; o MUST communicate the Message Digest Algorithm; o MUST communicate the Elliptic Curve; o MUST associate a value to the "ASID" field (Authentication Scheme IDentifier) of the EXT_AUTH header extension (Section 3.1); o MUST communicate whether the anti-replay service is used or not for this session; These parameters MUST be communicated to all receivers before they can authenticate the incoming packets. For instance it can be communicated in the session description, or initialized in a static way on the receivers, or communicated by means of an appropriate protocol. The details of this out-of-band mechanism are out of the scope of this document. 4.3. Processing 4.3.1. Signature Processing The computation of the ECC digital signature, using the private key, MUST include the ALC or NORM header (with the various header extensions) and the payload when applicable. The UDP/IP/MAC headers MUST NOT be included. During this computation, the "Signature" field MUST be set to 0. Several "Elliptic Curves" groups can be used, as well as several "Hash Algorithms". In practice both choices are related and there is a minimum hash algorithm size for any key length. Using a larger hash algorithm and then truncated the output is also feasible, however it consumes more processing power than is necessary. In order to promote interoperability, [RFC4754] [RFC5480] list several possible choices (see table below). Roca Expires June 11, 2012 [Page 16] Internet-Draft Simple authentication for ALC and NORM December 2011 +---------------------------+--------+------------------+-----------+ | Digital Signature | Key | Message Digest | Elliptic | | Algorithm name [RFC4754] | Size | Algorithm | Curve | +---------------------------+--------+------------------+-----------+ | ECDSA-256 (default) | 256 | SHA-256 | secp256r1 | | | | | | | ECDSA-384 | 384 | SHA-384 | secp384r1 | | | | | | | ECDSA-521 | 512 | SHA-512 | secp521r1 | +---------------------------+--------+------------------+-----------+ The ECDSA-256, ECDSA-384 and ECDSA-521 are designed to offer security comparable with AES-128, AES-192 and AES-256 respectively [RFC4754]. Among them, the use of ECDSA-256/secp256r1 is RECOMMENDED. 4.3.2. Anti-Replay Processing The anti-replay processing follows the principles described in Section 3.3.2. 4.4. In Practice Each packet sent MUST contain exactly one ECC Digital Signature EXT_AUTH header extension. A receiver MUST drop all the packets that do not contain an ECC Digital Signature EXT_AUTH header extension. All receivers MUST recognize EXT_AUTH but MAY not be able to parse its content, for instance because they do not support ECC digital signatures. In that case the Digital Signature EXT_AUTH header extension is ignored. If the anti-replay mechanism is used, each packet sent MUST contain a valid sequence number. All the packets that fail to contain a valid sequence number MUST be immediately dropped. Roca Expires June 11, 2012 [Page 17] Internet-Draft Simple authentication for ALC and NORM December 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HET (=1) | HEL (=9) | ASID | 0 |0| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- | | ^ 3 + + | 2 . . | . Signature (32 bytes) . | b . . | y | | | t + + | e | | v s +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- Figure 3: Example: Format of the ECC Digital Signature EXT_AUTH header extension using ECDSA-256 signatures, without any anti-replay protection. For instance Figure 3 shows the digital signature EXT_AUTH header extension when using ECDSA-256 (256 bit) ECC digital signatures. The ECC Digital Signature EXT_AUTH header extension is then 36 byte long. Roca Expires June 11, 2012 [Page 18] Internet-Draft Simple authentication for ALC and NORM December 2011 5. Group-Keyed Message Authentication Code (MAC) Scheme 5.1. Authentication Header Extension Format The integration of group-keyed MAC is similar in ALC and NORM and relies on the header extension mechanism defined in both protocols. More precisely this document details the HET=1 (EXT_AUTH) header extension defined in [RFC5651]. Several fields are added in addition to the HET (Header Extension Type) and HEL (Header Extension Length) fields (Figure 4). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HET (=1) | HEL | ASID | rsvd|A| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ anti-replay Sequence Number (SN) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | Group-keyed MAC | + +-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Format of the group-keyed MAC EXT_AUTH header extension. The fields of the group-keyed MAC EXT_AUTH header extension are: "ASID" (Authentication Scheme IDentifier) field (4 bits): The "ASID" identifies the source authentication scheme or protocol in use. The association between the "ASID" value and the actual authentication scheme is defined out-of-band, at session startup. "Reserved" field (3 bits): This is a reserved field that MUST be set to zero and ignored by receivers. "A" (Anti-replay) field (1 bit): The "AR" field, when set to 0, indicates that the anti-replay service is not used. When set to 1, it indicates that the anti- replay service is used. Roca Expires June 11, 2012 [Page 19] Internet-Draft Simple authentication for ALC and NORM December 2011 "SN" (Sequence Number) field (8 or 40 bits): The "SN" field contains an optional sequence number. When AR=0, this is an 8 bit field that MUST be set to zero. No anti-replay mechanism is used in that case. When AR=1, this is a 32+8=40 bit field and all of the 40 bits MUST be considered by the anti-replay mechanism. "Group-keyed MAC" field (variable size, multiple of 32 bits): The "Group-keyed MAC" field contains a truncated Group-keyed MAC of the message. If need be, this field is padded (with 0) up to a multiple of 32 bits. 5.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. As a side effect, with these functions, the receivers also know the key length and the non truncated MAC output length. Because of security threats on SHA-1, the use of HMAC-SHA-256 is RECOMMENDED [RFC6194]; o MUST communicate the length of the truncated output of the MAC, n_m, which depends on the Cryptographic MAC Function chosen. Only the n_m left-most bits (most significant bits) of the MAC output are kept. Of course, n_m MUST be lower or equal to the key length; o MUST communicate the group key to the receivers, confidentially, before starting the session. This key might have to be periodically refreshed for improved robustness; o MUST associate a value to the "ASID" field (Authentication Scheme IDentifier) of the EXT_AUTH header extension (Section 5.1); o MUST communicate whether the anti-replay service is used or not for this session; These parameters MUST be communicated to all receivers before they can authenticate the incoming packets. For instance it can be communicated in the session description, or initialized in a static way on the receivers, or communicated by means of an appropriate protocol (this will be often the case when periodic re-keying is required). The details of this out-of-band mechanism are out of the Roca Expires June 11, 2012 [Page 20] Internet-Draft Simple authentication for ALC and NORM December 2011 scope of this document. 5.3. Processing 5.3.1. Signature Processing The computation of the group-keyed MAC, using the group key, includes the ALC or NORM header (with the various header extensions) and the payload when applicable. The UDP/IP/MAC headers are not included. During this computation, the Weak group-keyed MAC field MUST be set to 0. Then the sender truncates the MAC output to keep the n_m most significant bits and stores the result in the group-keyed MAC Authentication header. Upon receiving this packet, the receiver computes the group-keyed MAC, using the group key, and compares it to the value carried in the packet. During this computation, the Group 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. 5.3.2. Anti-Replay Processing The anti-replay processing follows the principles described in Section 3.3.2. 5.4. In Practice Each packet sent MUST contain exactly one group-keyed MAC EXT_AUTH header extension. A receiver MUST drop packets that do not contain a group-keyed MAC EXT_AUTH header extension. All receivers MUST recognize EXT_AUTH but MAY not be able to parse its content, for instance because they do not support group-keyed MAC. In that case the group-keyed MAC EXT_AUTH extension is ignored. If the anti-replay mechanism is used, each packet sent MUST contain a valid sequence number. All the packets that fail to contain a valid sequence number MUST be immediately dropped. Roca Expires June 11, 2012 [Page 21] Internet-Draft Simple authentication for ALC and NORM December 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HET (=1) | HEL (=4) | ASID | 0 |0| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | group-keyed MAC (16 bytes) | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Example: Format of the group-keyed MAC EXT_AUTH header extension using HMAC-SHA-256, without any anti-replay protection. For instance Figure 5 shows the group-keyed MAC EXT_AUTH header extension when using HMAC-SHA-256. The group-keyed MAC EXT_AUTH header extension is then 16 byte long. Roca Expires June 11, 2012 [Page 22] Internet-Draft Simple authentication for ALC and NORM December 2011 6. Combined Use of the RSA/ECC Digital Signatures and group-keyed MAC Schemes 6.1. Authentication Header Extension Format The integration of combined RSA/ECC Digital Signature and group-keyed MAC is similar in ALC and NORM and relies on the header extension mechanism defined in both protocols. More precisely this document details the HET=1 (EXT_AUTH) header extension defined in [RFC5651]. Several fields are added in addition to the HET (Header Extension Type) and HEL (Header Extension Length) fields (Figure 6). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HET (=1) | HEL | ASID | rsvd|A| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | anti-replay Sequence Number (SN) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | Signature | + +-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | group-keyed MAC | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Format of the group-keyed MAC EXT_AUTH header extension. The fields of the group-keyed MAC EXT_AUTH header extension are: "ASID" (Authentication Scheme IDentifier) field (4 bits): The "ASID" identifies the source authentication scheme or protocol in use. The association between the "ASID" value and the actual authentication scheme is defined out-of-band, at session startup. "Reserved" field (3 bits): This is a reserved field that MUST be set to zero and ignored by receivers. "A" (Anti-replay) field (1 bit): Roca Expires June 11, 2012 [Page 23] Internet-Draft Simple authentication for ALC and NORM December 2011 The "AR" field MUST be set to 1 and it indicates that the anti- replay service is used (see Section 6.3). "SN" (Sequence Number) field (8 or 40 bits): The "SN" field contains a sequence number. Since AR=1, this is a 32+8=40 bit field and all of the 40 bits MUST be considered by the anti-replay mechanism. "Signature" field (variable size, multiple of 32 bits): The "Signature" field contains a digital signature of the message. If need be, this field is padded (with 0) up to a multiple of 32 bits. "group-keyed MAC" field (variable size, multiple of 32 bits, by default 32 bits): The "group-keyed MAC" field contains a truncated group-keyed MAC of the message. 6.2. Parameters Several parameters MUST be initialized by an out-of-band mechanism, as defined in Section 3.2, Section 4.2 and Section 5.2. 6.3. Processing In some situations, it can be interesting to use both authentication schemes. The goal of the group-keyed 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. 6.3.1. Signature Processing Before sending a message, the sender sets the Signature field and group-keyed MAC field to zero. Then the sender computes the Signature as detailed in Section 3.3 or in Section 4.3 and stores the value in the Signature field. Then the sender computes the group- keyed MAC as detailed in Section 5.3 and stores the value in the group-keyed MAC field. The (RSA or ECC) digital signature value is therefore protected by the group-keyed MAC, which avoids DoS attacks where the attacker corrupts the digital signature itself. Upon receiving the packet, the receiver first checks the group-keyed MAC, as detailed in Section 5.3. If the check fails, the packet MUST be immediately dropped. Otherwise the receiver checks the Digital Signature, as detailed in Section 3.3. If the check fails, the Roca Expires June 11, 2012 [Page 24] Internet-Draft Simple authentication for ALC and NORM December 2011 packet MUST be immediately dropped. This scheme features a few limits: o the group-keyed MAC is of no help if a group member (who knows the group key) impersonates the sender and sends forged messages to other receivers. DoS attacks are still feasible; o it requires an additional MAC computing for each packet, both at the sender and receiver sides; o it increases the size of the authentication headers. In order to limit this problem, the length of the truncated output of the MAC, n_m, SHOULD be kept small (see [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-keyed MAC check is only a pre-check that is followed by the standard signature authentication check, this is not considered to be an issue. For a given use-case, the benefits brought by the group-keyed MAC must be balanced against these limitations. 6.3.2. Anti-Replay Processing The anti-replay processing follows the principles described in Section 3.3.2. Here an anti-replay service MUST be used. Indeed, failing to enable anti-replay protection would facilitate DoS attacks, since all replayed (but otherwise valid) packets would pass the light authentication scheme and oblige a receiver to perform a complex signature verification. 6.4. In Practice Each packet sent MUST contain exactly one combined Digital Signature/ group-keyed MAC EXT_AUTH header extension. A receiver MUST drop packets that do not contain a combined Digital Signature/group-keyed MAC EXT_AUTH header extension. All receivers MUST recognize EXT_AUTH but MAY not be able to parse its content, for instance because they do not support combined Digital Signature/group-keyed MAC. In that case the combined Digital Signature/group-keyed MAC EXT_AUTH extension is ignored. Since the anti-replay mechanism MUST be used, each packet sent MUST contain a valid sequence number. All the packets that fail to Roca Expires June 11, 2012 [Page 25] Internet-Draft Simple authentication for ALC and NORM December 2011 contain a valid sequence number MUST be immediately dropped. It is RECOMMENDED that the n_m parameter of the group authentication scheme be small, and by default equal to 32 bits (Section 6.3). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HET (=1) | HEL (=35) | ASID | 0 |1| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | anti-replay Sequence Number (SN) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- | | ^ 1 + + | 2 | | | 8 . . | . Signature (128 bytes) . | b . . | y | | | t + + | e | | v s +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- | group-keyed MAC (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- Figure 7: Example: Format of the combined RSA Digital Signature/ group-keyed MAC EXT_AUTH header extension using 1024 bit signatures, with anti-replay protection. For instance Figure 7 shows the combined Digital Signature/ group-keyed MAC EXT_AUTH header extension when using 128 byte (1024 bit) key RSA digital signatures (which also means that the signature field is 128 byte long). The EXT_AUTH header extension is then 140 byte long. Roca Expires June 11, 2012 [Page 26] Internet-Draft Simple authentication for ALC and NORM December 2011 7. IANA Considerations This document does not require any IANA registration. Roca Expires June 11, 2012 [Page 27] Internet-Draft Simple authentication for ALC and NORM December 2011 8. Security Considerations 8.1. Dealing With DoS Attacks Let us consider packets secured through the use of a digital signature scheme first. Because faked packets are easy to create but checking them requires to compute a costly digital signature, this scheme introduces new opportunities for an attacker to mount DoS attacks. More precisely an attacker can easily saturate the processing capabilities of the receiver. In order to mitigate these attacks, it is RECOMMENDED to use the combined Digital Signature/group-keyed MAC scheme (Section 6.3). However, no mitigation is possible if a group member acts as an attacker. Additionally, even if checking a group-keyed MAC is significantly faster than checking a digital signature, there are practical limits on how many group-keyed MAC can be checked per time unit. Therefore it is RECOMMENDED to limit the number of authentication checks per time unit when the number of incoming packets that fail the authentication check exceeds a given threshold (i.e., in case of a DoS attack). The RECOMMENDATION to limit the number of checks per time unit under (presumed) attack situations can be extended to the other authentication schemes. 8.2. Dealing With Replay Attacks Replay attacks consist for an attacker to store a valid message and to replay it later on. It is RECOMMENDED to use the anti-replay service defined in this document with the signature and group-keyed MAC solutions, and this anti-replay service MUST be used in case of a combined use of signature and group-keyed MAC (see Section 6.3.2). The following section details some of the potential consequences of not using the anti-replay protection. 8.2.1. Impacts of Replay Attacks on the Simple Authentication Schemes Since all the above authentication schemes are stateless, replay attacks have no impact on these schemes. 8.2.2. Impacts of Replay Attacks on NORM We review here the potential impacts of a replay attack on the NORM component. Note that we do not consider here the protocols that could be used along with NORM, for instance the congestion control protocols. Roca Expires June 11, 2012 [Page 28] Internet-Draft Simple authentication for ALC and NORM December 2011 First, let us consider replay attacks within a given NORM session. NORM being a stateful protocol, replaying a packet may have consequences. NORM defines a "sequence" field that may be used to protect against replay attacks [RFC5740] within a given NORM session. This "sequence" field is a 16-bit value that is set by the message originator (sender or receiver) as a monotonically increasing number incremented with each NORM message transmitted. Using this field as an anti-replay protection would be possible if there is no wrapping to zero, i.e., would only be possible if at most 65535 packets are sent. This may be true for some use-cases but not for the general case. Using this field as an anti-replay protection would also be possible if the keying material is updated before wrapping to zero happens. This may be true for some use-cases but not for the general case. Now let us consider replay attacks across several NORM sessions. A host participation in a NORM session is uniquely identified by the {"source_id"; "instance_id"} tuple. Therefore, when a given host participates in several NORM sessions, it is RECOMMENDED that the "instance_id" be changed for each NORM instance. It is also RECOMMENDED, when the group-keyed 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. 8.2.3. Impacts of Replay Attacks on ALC We review here the potential impacts of a replay attack on the ALC component. Note that we do not consider here the protocols that could be used along with ALC, for instance the layered or wave based congestion control protocols. First, let us consider replay attacks within a given ALC session: o replayed encoding symbol: a replayed encoding symbol (coming from a replayed data packet) is detected thanks to the object/block/ symbol identifiers and is silently discarded. o replayed control information: more precisely: * At the end of the session, a "close session" (A flag) packet is sent. Replaying a packet containing this flag has no impact since the receivers already left. * Similarly, replaying a packet containing a "close object" (B flag) has no impact since this object is probably already Roca Expires June 11, 2012 [Page 29] Internet-Draft Simple authentication for ALC and NORM December 2011 marked as closed by the receiver. * Timing information sent as part of an LCT EXT_TIME header extension [RFC5651] may be more sensitive to replay attacks. For instance replaying a packet containing an ERT (Expected Residual Time) may mislead a receiver to believe an object transmission will continue for some time whereas the transmission of symbols for this object is about to stop. Replaying a packet containing a SCT (Sender Current Time) is easily identified if the receiver verifies that time progresses upon receiving such EXT_TIME header extensions. Replaying a packet containing a SLC (Session Last Changed) is easily identified if the receiver verifies the chronology upon receiving such EXT_TIME header extensions. This analysis shows that ALC might be, to a limited extent, sensitive to replay attacks within the same session if timing information is used. Otherwise ALC is robust in front of replay attacks within the same session. Now let us consider replay attacks across several ALC sessions. An ALC session is uniquely identified by the {sender's IP address; Transport Session Identifier (TSI)}. Therefore, when a given sender creates several sessions, the TSI MUST be changed for each ALC session, so that each TSI is unique among all active sessions of this sender and for a large period of time preceding and following when the session is active [RFC5651]. Therefore, ALC can be made robust in front of replay attacks across different sessions. Of course, when the group-keyed MAC authentication/integrity check scheme is used, the shared group key SHOULD be changed across sessions if the set of receivers changes. 8.3. Dealing With Attacks on the Parameters Sent Out-of-Band This specification requires several parameters to be communicated to the receiver(s) via an out-of-band mechanism that is out of the scope of this document. This is in particular the case for the mapping between an ASID value and the associated authentication scheme (Section 1). Since this mapping is critical, this information SHOULD be carried in a secure way from the sender to the receiver(s). Roca Expires June 11, 2012 [Page 30] Internet-Draft Simple authentication for ALC and NORM December 2011 9. Acknowledgments The author is grateful to the authors of [RFC4303], [RFC4359], [RFC4754] and [RFC5480] that inspired several sections of the present document. The author is also grateful to all the IESG members, and in particular to David Harrington, Stephen Farrell and Sean Turner for their very detailed reviews. Roca Expires June 11, 2012 [Page 31] Internet-Draft Simple authentication for ALC and NORM December 2011 10. References 10.1. Normative References [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding Transport (LCT) Building Block", RFC 5651, October 2009. [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, "NACK-Oriented Reliable Multicast (NORM) Transport Protocol", RFC 5740, November 2009. [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 5775, April 2010. 10.2. Informative References [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe, "Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction", RFC 4082, June 2005. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4359, January 2006. [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 4754, January 2007. Roca Expires June 11, 2012 [Page 32] Internet-Draft Simple authentication for ALC and NORM December 2011 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, March 2009. [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010. [RFC5776] Roca, V., Francillon, A., and S. Faurite, "Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols", RFC 5776, April 2010. [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, February 2011. [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms", RFC 6194, March 2011. [RMT-FLUTE] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, "FLUTE - File Delivery over Unidirectional Transport", Work in Progress, February 2011. Roca Expires June 11, 2012 [Page 33] Internet-Draft Simple authentication for ALC and NORM December 2011 Author's Address Vincent Roca INRIA 655, av. de l'Europe Inovallee; Montbonnot ST ISMIER cedex 38334 France Email: vincent.roca@inria.fr URI: http://planete.inrialpes.fr/people/roca/ Roca Expires June 11, 2012 [Page 34]