RFC 6584
Simple Authentication Schemes for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols
RFC 6584 🎀 Simple Authentication Schemes for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols
okay bestie, the title block tea ☕ this is RFC 6584, written by V. Roca from INRIA 🇫🇷. It's a Standards Track document, dated April 2012, with ISSN 2070-1721. The block doesn't list any RFC it obsoletes or updates, so there's no drama there 💅
Abstract ✨
so this doc introduces four schemes that give you per-packet authentication, integrity, and anti-replay protection for ALC and NORM 🔐. Scheme one uses RSA Digital Signatures. Scheme two uses ECDSA (Elliptic Curve Digital Signature Algorithm). Scheme three is a Group-keyed Message Authentication Code (MAC). Scheme four mashes the Digital Signature and group schemes together 🫶. Each one has its own target use case, and they don't all give you the same services, so pick wisely 🦋
Status of This Memo 📜
this is an Internet Standards Track document 🔥
it's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community 🌈 it got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 👑 if you want more info on Internet Standards, check Section 2 of RFC 5741 📖
for the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6584 💜
Copyright Notice ©️
Copyright (c) 2012 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) as they stand on the date of publication. please read these carefully, bestie, because they spell out your rights and restrictions for this document 🙈 any Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes ⭐
Table of Contents 🗺️
1. Introduction ....................................................4
1.1. Scope of This Document .....................................6
1.2. Terminology, Notations, and Definitions ....................6
2. Authentication Scheme Identification with the ASID Field ........7
3. RSA Digital Signature Scheme ....................................8
3.1. Authentication Header Extension Format .....................8
3.2. Parameters ................................................10
3.3. Processing ................................................11
3.3.1. Signature Processing ...............................11
3.3.2. Anti-Replay Processing .............................12
3.4. In Practice ...............................................13
4. Elliptic Curve Digital Signature Scheme ........................14
4.1. Authentication Header Extension Format ....................14
4.2. Parameters ................................................15
4.3. Processing ................................................15
4.3.1. Signature Processing ...............................15
4.3.2. Anti-Replay Processing .............................16
4.4. In Practice ...............................................16
5. Group-Keyed Message Authentication Code (MAC) Scheme ...........17
5.1. Authentication Header Extension Format ....................17
5.2. Parameters ................................................19
5.3. Processing ................................................20
5.3.1. Signature Processing ...............................20
5.3.2. Anti-Replay Processing .............................20
5.4. In Practice ...............................................20
6. Combined Use of the RSA/ECC Digital Signatures and
Group-Keyed MAC Schemes ........................................21
6.1. Authentication Header Extension Format ....................21
6.2. Parameters ................................................23
6.3. Processing ................................................23
6.3.1. Signature Processing ...............................23
6.3.2. Anti-Replay Processing .............................24
6.4. In Practice ...............................................24
7. Security Considerations ........................................25
7.1. Dealing with DoS Attacks ..................................25
7.2. Dealing with Replay Attacks ...............................26
7.2.1. Impacts of Replay Attacks on the Simple
Authentication Schemes .............................26
7.2.2. Impacts of Replay Attacks on NORM ..................26
7.2.3. Impacts of Replay Attacks on ALC ...................27
7.3. Dealing with Attacks on the Parameters Sent Out-of-Band ...28
8. Acknowledgments ................................................28
9. References .....................................................28
9.1. Normative References ......................................28
9.2. Informative References ....................................291. Introduction 🦋
okay so picture this: lots of apps using multicast and broadcast need every receiver to be able to check who sent each packet it gets, and whether it got messed with on the way 🕵️♀️ ALC [RFC5775] and NORM [RFC5740] are two Content Delivery Protocols (CDPs) built to reliably move objects, like files, from a session's sender to several receivers 📦
NORM is bidirectional. each receiver acknowledges the data it got or, when packets get erased, asks for retransmissions 🔁 ALC is the opposite, purely unidirectional. reliability comes from cyclic transmissions of the content in a carousel, from proactive Forward Error Correction (FEC) codes, or from using both together 🎠 because ALC is purely unidirectional, it's massively scalable, while NORM is intrinsically limited in how many receivers it can handle in one session 📈 both protocols work at the application level, on top of an erasure channel (like the Internet) where packets can get lost (erased) in transit 💀
here's the danger, babe 😱 an attacker could pretend to be the ALC or NORM session sender and inject forged packets into the receivers, corrupting the objects they rebuild. an attacker could also pretend to be a NORM session receiver and inject forged feedback packets to the NORM sender 👀
with group communications, a few solutions exist to give the receiver some guarantees about the integrity of the packets it gets and about who really sent them ✨ they all have different features, so they fit some use cases better than others:
- Digital Signatures [RFC4359] (see Sections 3 and 4 of this document): this one is a great fit for low data rate flows, when you need packet sender authentication and packet integrity 🫶 the catch is that RSA-based Digital Signatures are limited by high computational costs and high transmission overheads 😩 using ECC (Elliptic Curve Cryptography) [RFC6090] significantly relaxes those constraints ✨ for example, a 1024-bit RSA key gives equivalent security to a 160-bit ECC key, and a 2048-bit RSA key matches a 224-bit ECC key 🔑 RSA puts more load on the signer but much less on the verifier, while ECC puts a more similar load on both, so with many verifiers, more CPU gets used overall 🧮
- Group-keyed Message Authentication Codes (MACs) (see Section 5): this one is a dream for high data rate flows, when transmission overheads have to be minimized 🚀 but it can't protect against attacks from inside the group, where a group member impersonates the sender and sends forged messages to other receivers 🙅♀️
- TESLA (Timed Efficient Stream Loss-tolerant Authentication) [RFC4082] [RFC5776]: this one is also great for high data rate flows, when transmission overheads must be minimized, and when you need packet sender authentication and packet integrity 💖 the price is extra complexity, in particular the need to loosely synchronize the receivers and the sender 🕰️ you also have to wait for the key to be disclosed before you can authenticate a packet, so the authentication check gets delayed ⏳
here's a table summarizing the pros and cons of each authentication/integrity scheme used at the application/transport level (where "-" means con, "0" means neutral, and "+" means pro) 📊
+-----------------+-------------+-------------+-------------+-------+
| | RSA Digital | ECC Digital | Group-Keyed | TESLA |
| | Signature | Signature | MAC | |
+-----------------+-------------+-------------+-------------+-------+
| Sender auth and | Yes | Yes | No (group | Yes |
| packet | | | security) | |
| integrity | | | | |
| Non-delayed | Yes | Yes | Yes | No |
| authentication | | | | |
| Anti-replay | Opt | Opt | Opt | No |
| protection | | | | |
| Processing load | - | sender: -, | + | + |
| | | recv: 0 | | |
| Transmission | - | 0 | + | + |
| overhead | | | | |
| Complexity | + | + | + | - |
+-----------------+-------------+-------------+-------------+-------+so here's the tea 🫖 several authentication schemes MAY be used in the same ALC or NORM session, even on the same communication path 🌸 they're told apart by a dedicated identifier, the "ASID" (Authentication Scheme IDentifier), which is present in each HET=1 (EXT_AUTH) header extension and tells a receiver how to interpret that HET=1 header extension 🧚 Section 2 has the details 📖
all the apps built on top of ALC and NORM directly benefit from the source authentication and packet integrity services this doc defines 👑 for example, that's the case for the File Delivery over Unidirectional Transport (FLUTE) application [RMT-FLUTE], which is built on top of ALC 🎁
last thing, bestie: the current spec assumes that several parameters, like keying material, get communicated out-of-band between the sender and the receivers, sometimes securely 🔐 that's detailed in Sections 3.2, 4.2, 5.2, and 6.2 💅
(part 1 of 6, more coming soon 💖)
1.1. Scope of This Document ✨
okay so [RFC5776] is literally the one that explains how to use TESLA with ALC and NORM 🦋
this doc is about the Digital Signature based on RSA asymmetric crypto, the Elliptic Curve Digital Signature Algorithm (ECDSA), and Group-keyed MAC schemes 🔥 it also covers the joint use of Digital Signature and Group-keyed MAC schemes, which is so good 😭
unlike TESLA, this spec looks at the authentication/integrity of packets from the session's sender AND the ones from receivers (NORM) 💅 that's the whole main character moment
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 read as described in [RFC2119] 🌸
these are the notations and definitions used all through the doc 🧚
o MAC is the Message Authentication Code;
o HMAC is the Keyed-Hash Message Authentication Code;
o "sender" is 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 when we're talking about feedback traffic 💜
o "receiver" is 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 when it's feedback traffic 🫶
o "ASID" is the Authentication Scheme IDentifier 🍓
key definitions for Digital Signatures:
o the public key is what a receiver uses to check a packet's signature. this key MUST be communicated to all receivers before the session starts 🔑
o the private key is what a sender uses 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 Digital Signature Algorithm (DSA) signatures, key sizes strictly less than 1024 bits SHOULD NOT be used 💀 key sizes between 1024 and 2048 bits inclusive SHOULD be used ✨ key sizes strictly greater than 2048 bits MAY be used 🌈
key 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 the session starts 🎀
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 leftmost bits (most significant bits) of the MAC output are kept 🌸
- 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 which are specified in this document) use the same HET=1 (EXT_AUTH) Authentication Header extension mechanism defined in [RFC5651] 💖 so the same 4-bit ASID field has been reserved in all the specs (see Sections 3.1, 4.1, 5.1, and 6.1, as well as Section 5.1 of [RFC5776]) 🫶 for a given ALC or NORM session, the ASID value in an incoming packet lets a receiver tell what the HET=1 (EXT_AUTH) header extension contents are actually used for and how they're formatted ✨
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 session members through an out-of-band mechanism 🌈 this association is per ALC or NORM session, and different sessions MAY reuse the same ASID values for different authentication schemes 💅
with ALC, the ASID value is scoped by the {sender IP address; Transport Session Identifier (TSI)} tuple [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's no risk of confusion between different sessions 😭 this lines up with Section 7.2.3 🎀
with NORM, there's no session identifier inside NORM packets 💀 so depending on whether 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} tuple or the {source IP address; destination multicast address; destination port number} tuple, and those fully identify a NORM session [RFC5740] 🦋 care should be taken that these tuples stay unique, within a given scope and for a sufficient period before, during, and after the session is active, to avoid mixing up different sessions 🌸 but this is a recommendation for NORM sessions, not something specific to an authentication scheme 🧚 also, the ASID value is NOT scoped by the {source_id; instance_id} tuple, which identifies a host's participation in a NORM session rather than the session itself (Section 7.2.2) 💜
anyway, because the ASID field is 4 bits long, there's a max of 16 authentication schemes per ALC or NORM session 👑🫶
- 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 doc details the HET=1 (EXT_AUTH) header extension defined in [RFC5651] ✨
a few fields get added, on top of the HET (Header Extension Type) and HEL (Header Extension Length) fields (Figure 1) 💖
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (=1) | HEL | ASID | rsvd|A| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R+ +
~ anti-replay Sequence Number (SN) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| Signature |
+ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 1: Format of the Digital Signature EXT_AUTH Header Extension 🧚
the fields of the Digital Signature EXT_AUTH header extension are as follows 🫶
ASID (4 bits):
the ASID identifies the source authentication scheme or protocol in use. the association between the ASID value and the actual authentication scheme is defined out-of-band, at session startup 🍓
rsvd (Reserved) (3 bits):
this is a reserved field that MUST be set to zero and ignored by receivers 🔒
AR (anti-replay) (1 bit):
the AR field, when set to 0, means the anti-replay service is NOT used. when set to 1, it means the anti-replay service IS used 💅
SN (Sequence Number) (8 or 40 bits):
the SN field holds an optional Sequence Number. when AR = 0, it's an 8-bit field that MUST be set to zero, and no anti-replay mechanism is used in that case 😭 when AR = 1, it's a 40-bit field (32 bits + 8 bits), and ALL 40 bits MUST be considered by the anti-replay mechanism 🔥
Signature (variable size, multiple of 32 bits):
the Signature field contains a Digital Signature of the message 💜 if need be, this field gets 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 its public key, so each receiver can verify the signature of the packets it receives. for security reasons [RFC5751], using key sizes between 1024 and 2048 bits inclusive is RECOMMENDED 🎀 key sizes below 1024 bits SHOULD NOT be used 💀 key sizes above 2048 bits MAY be used 🌈 as a side effect, the receivers also know the key length and the signature length, since the two are equal 🦋
o MAY communicate a certificate (which also means a PKI has been set up), so each receiver can 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, which are usually used for that purpose 🧚
o MUST communicate the One-way Hash Function, for instance SHA-1, SHA-224, SHA-256, SHA-384, or SHA-512. because of security threats on SHA-1, using SHA-256 is RECOMMENDED [RFC6194] 💖
o MUST associate a value with the ASID field of the EXT_AUTH header extension (Section 3.1) 🍓
o MUST communicate whether or not the anti-replay service is used for this session 💜
these parameters MUST be communicated to all receivers before they can authenticate incoming packets 🎀 it can be done in the session description, initialized statically on the receivers, or communicated through an appropriate protocol 🦋 the details of this out-of-band mechanism are beyond the scope of this document, so we're not going into it here 🌸
3.3. Processing 🔥
3.3.1. Signature Processing 🔥
okay so when you compute the Digital Signature with the private key, the input MUST include the ALC or NORM header (with all the header extensions) and the payload when there is one. the UDP/IP/MAC headers MUST NOT be included 🙅♀️ and while all this is happening, the Signature field MUST be set to 0 ✨
there are a few signature-encoding algorithms you can pick from, like RSASSA-PKCS1-v1_5 and RSASSA-PSS. with either encoding you can use a bunch of one-way hash functions too, like SHA-256 🌸
first, let's look at the packet sender 💅 as noted in [RFC4359], Digital Signature generation is done as described in Section 8.2.1 of [RFC3447] (RSASSA-PKCS1-v1_5) and in Section 8.1.1 of [RFC3447] (RSASSA-PSS). the authenticated portion of the packet is used as the message M, which gets passed to the signature generation function, and the signer's RSA private key is passed as K. the short version (when SHA-256 is used): the process computes a SHA-256 hash of the authenticated packet bytes, signs that hash with the private key, and encodes the result with the specified RSA encoding type. the output is a value S, and that's the Digital Signature that goes in the packet 🎀
the signature size is equal to the "RSA modulus" with RSASSA-PKCS1-v1_5 and RSASSA-PSS, unless the RSA modulus isn't a multiple of 8 bits. in that case, the Digital Signature (also called the Integrity Check Value (ICV) in [RFC4359]) MUST be prepended with between 1 and 7 bits set to zero so it ends up 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 based on the maximum expected lifetime of the session. that choice is beyond the scope of this document 🦋
now the receiver 👀 as noted in [RFC4359], Digital Signature verification is done as described in Section 8.2.2 of [RFC3447] (RSASSA-PKCS1-v1_5) and Section 8.1.2 of [RFC3447] (RSASSA-PSS). when the packet shows up, the Digital Signature is passed to the verification function as S. the authenticated portion of the packet is the message M, and the RSA public key is passed as (n, e). the short version (when SHA-256 is used): the verification function computes a SHA-256 hash of the authenticated packet bytes, decrypts the SHA-256 hash that's in the packet using the sender's public key, and checks that the right encoding was applied. then the two SHA-256 hashes get compared, and if they match, validation is successful ✨💖
3.3.2. Anti-Replay Processing 🧚
so let's say the anti-replay service is being used. the vibes are similar to the Sequence Number mechanism in [RFC4303], except this document uses a 40-bit field that holds all the bits of the Sequence Number counter 🍓
on the sender's side (Section 2.2 of [RFC4303]), the Sequence Number counter starts at 0 when the session starts up. the sender bumps the counter for the session and drops the value into the SN field. so the very first packet sent has an SN of 1 🥹 the SN value of the Authentication Header extension MUST be initialized before the signature generation process, so the receiver can check the SN value during integrity verification 🔐
the sender SHOULD make sure the counter doesn't cycle before putting the new value in the SN field 🙈 if it does cycle, an attacker could replay a packet from the previous cycle, which means the anti-replay service would only cover a single SN cycle 😭 since the Sequence Number lives in a 40-bit field, cycling is expected to never happen in most situations. for example, on a 10-Gbps network with small packets (64 bytes long), cycling will happen after slightly more than 15 hours ⏳
on the receiver's side (Section 3.4.3 and Appendix A2 of [RFC4303]), every received packet MUST be checked to make sure its Sequence Number doesn't duplicate the Sequence Number of any other packet received during the session. if this preliminary check fails, the packet gets tossed, which means the receiver doesn't have to do any cryptographic operations on it 🗑️ if the preliminary check passes, the receiver still can't touch its local counter yet, because the Sequence Number's integrity hasn't been verified at that point 🔍
duplicates get rejected with a sliding receive window 🪟 the "right" edge of the window is the highest validated Sequence Number received on this session. packets with Sequence Numbers lower than the "left" edge get rejected. packets inside the window get checked against a list of received packets within the window (how that list is managed is a local, implementation-based decision). the window limits how far out of order a packet can be, compared to the packet with the highest Sequence Number authenticated so far 📏
if the received packet is inside the window and isn't a duplicate, or if it's to the right of the window, the receiver moves on to integrity verification. if the integrity check fails, the receiver MUST discard the received packet as invalid. otherwise, the receive window gets updated and packet processing keeps going 💜
3.4. In Practice 💅
every packet sent MUST contain exactly one Digital Signature EXT_AUTH header extension, and a receiver MUST drop all the packets that don't contain a Digital Signature EXT_AUTH header extension 🚫
all receivers MUST recognize EXT_AUTH, but they might not be able to parse its content (for example, because they don't support Digital Signatures). in that case, the Digital Signature EXT_AUTH header extension is ignored 🙃
if the anti-replay mechanism is used, each packet sent MUST contain a valid Sequence Number. all the packets that fail to contain a valid Sequence Number MUST be immediately dropped 🗑️💨
for example, Figure 2 shows the Digital Signature EXT_AUTH header extension when using 128-byte (1024-bit) key Digital Signatures (which also means the Signature field is 128 bytes long). the Digital Signature EXT_AUTH header extension is then 132 bytes long 🧁
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (=1) | HEL (=33) | ASID | 0 |0| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| | ^ 1
+ + | 2
| | | 8
. . |
. Signature (128 bytes) . | b
. . | y
| | | t
+ + | e
| | v s
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
Figure 2: Example: Format of the Digital Signature EXT_AUTH
Header Extension Using 1024-Bit Signatures,
without Any Anti-Replay Protection4. Elliptic Curve Digital Signature Scheme 🦋
this document is all about the Elliptic Curve Digital Signature Algorithm (ECDSA) 💖 [RFC6090] describes other elliptic curve techniques, like KT-I signatures. those alternatives aren't considered in this document, but they may be added in the future 🔮
4.1. Authentication Header Extension Format 🎀
the integration of ECC Digital Signatures is pretty similar to RSA Digital Signatures. a few fields get added alongside the HET and HEL fields, as shown in Figure 1 ✨
here's the rundown on the Digital Signature EXT_AUTH header extension fields:
ASID (4 bits):
the ASID identifies the source authentication scheme or protocol in use. the link between the ASID value and the actual authentication scheme is defined out-of-band, at session startup 🤝
rsvd (3 bits):
this is a reserved field that MUST be set to zero and ignored by receivers 🫶
AR (1 bit):
when the AR field is set to 0, it means the anti-replay service is not used. when it's set to 1, the anti-replay service is used 🔁
SN (8 or 40 bits):
the SN field holds an optional Sequence Number. when AR = 0, it's an 8-bit field that MUST be set to zero, and no anti-replay mechanism is used in that case. when AR = 1, it's a 40-bit field (32 bits + 8 bits), and all of the 40 bits MUST be considered by the anti-replay mechanism 🍓
Signature (variable size, multiple of 32 bits):
the Signature field holds a Digital Signature of the message. if need be, this field is padded (with 0) up to a multiple of 32 bits 🌈
4.2. Parameters 🧚
several parameters MUST be initialized by an out-of-band mechanism. the sender or group controller:
- MUST communicate its public key, so each receiver can verify the signature of the packets it receives. as a side effect, receivers also know the key length and the signature length, since those two parameters are equal ✔️
- MAY communicate a certificate (which also means a PKI has been set up), so each receiver can check the sender's public key 🔏
- MUST communicate the message digest algorithm 🧮
- MUST communicate the elliptic curve 📈
- MUST associate a value to the ASID field of the EXT_AUTH header extension (Section 3.1) 🪪
- MUST communicate whether or not the anti-replay service is used for this session 🔁
these parameters MUST be communicated to all receivers before they can authenticate the incoming packets 🚀 for example, they can be sent in the session description, set up statically on the receivers, or shared through an appropriate protocol. the details of this out-of-band mechanism are beyond the scope of this document 🙌
4.3. Processing 💫
4.3.1. Signature Processing ✨
okay so computing the ECC Digital Signature with 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 🙅♀️. and during this computation the Signature field MUST be set to 0, so zero it out first, bestie 💅
several elliptic curve groups can be used, plus several hash algorithms 🌈. in practice these two choices are linked, and there's a minimum hash algorithm size for any key length. using a bigger hash and then truncating the output is also doable, but it eats more processing power than you need 🫠. to keep everyone interoperable, [RFC4754] and [RFC5480] list a bunch of possible choices (see the table below) 🎀
+---------------------------+--------+------------------+-----------+
| 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 |
+---------------------------+--------+------------------+-----------+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, using 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 might not be able to parse its content, for instance because they don't 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 💀
for instance, Figure 3 shows the Digital Signature EXT_AUTH header extension when using ECDSA-256 (256-bit) ECC Digital Signatures. the ECC Digital Signature EXT_AUTH header extension is then 36 bytes long 🦋
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (=1) | HEL (=9) | ASID | 0 |0| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| | ^ 3
+ + | 2
. . |
. Signature (32 bytes) . | b
. . | y
| | | t
+ + | e
| | v s
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
Figure 3: Example: Format of the ECC Digital Signature EXT_AUTH
Header Extension Using ECDSA-256 Signatures,
without Any Anti-Replay Protection5. 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 it 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, on top of the HET and HEL fields (Figure 4) ✨
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (=1) | HEL | ASID | rsvd|A| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R+ +
~ anti-replay Sequence Number (SN) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| Group-keyed MAC |
+ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Format of the Group-Keyed MAC EXT_AUTH Header Extensionthe fields of the Group-keyed MAC EXT_AUTH header extension are as follows 📝
ASID (4 bits):
The ASID identifies the source authentication scheme or protocol in use. the association between the ASID value and the actual authentication scheme is defined out-of-band, at session startup 🤝
rsvd (3 bits):
This is a reserved field that MUST be set to zero and ignored by receivers 🧊
AR (1 bit):
The AR field, when set to 0, indicates that the anti-replay service is not used. when set to 1, it indicates that the anti-replay service is used 🔄
SN (8 or 40 bits):
The SN field contains an optional Sequence Number. when AR = 0, this is an 8-bit field that MUST be set to zero. no anti-replay mechanism is used in that case. when AR = 1, this is a 40-bit field (32 bits + 8 bits), and all of the 40 bits MUST be considered by the anti-replay mechanism 🔢
Group-keyed MAC (variable size, multiple of 32 bits):
The Group-keyed MAC field contains a truncated Group-keyed MAC of the message. if need be, this field is padded (with 0) up to a multiple of 32 bits 🧁
5.2. Parameters 🗝️
several parameters MUST be initialized by an out-of-band mechanism. The sender or group controller:
- MUST communicate the Cryptographic MAC Function -- for instance,
HMAC-SHA-1,HMAC-SHA-224,HMAC-SHA-256,HMAC-SHA-384, orHMAC-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 ofHMAC-SHA-256is RECOMMENDED [RFC6194]; - MUST communicate the length of the truncated output of the MAC,
n_m, which depends on the Cryptographic MAC Function chosen. only then_mleftmost bits (most significant bits) of the MAC output are kept. of course,n_mMUST be less than or equal to the key length; - MUST communicate the group key to the receivers, confidentially, before starting the session. this key might have to be periodically refreshed for improved robustness;
- MUST associate a value to the ASID field of the EXT_AUTH header extension (Section 5.1);
- MUST communicate whether or not the anti-replay service is used for this session.
these parameters MUST be communicated to all receivers before they can authenticate the incoming packets. for instance, they can be communicated in the session description, or initialized in a static way on the receivers, or communicated by means of an appropriate protocol (this will often be the case when periodic re-keying is required). the details of this out-of-band mechanism are beyond the scope of this document 🌷
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-keyed 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 beyond 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 might not be able to parse its content, for instance because they don't 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 💀
for instance, Figure 5 shows the Group-keyed MAC EXT_AUTH header extension when using HMAC-SHA-256. the Group-keyed MAC EXT_AUTH header extension is then 16 bytes long 🦋
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (=1) | HEL (=4) | ASID | 0 |0| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Group-keyed MAC (16 bytes) |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Example: Format of the Group-Keyed MAC EXT_AUTH Header
Extension Using HMAC-SHA-256, without Any Anti-Replay Protection6. Combined Use of the RSA/ECC Digital Signatures and Group-Keyed MAC Schemes 🧩
6.1. Authentication Header Extension Format ✨
okay so combining RSA/ECC Digital Signatures with Group-keyed MAC schemes works pretty much the same way in ALC and NORM 🫶 both protocols use the header extension mechanism, and this doc focuses on the HET=1 (EXT_AUTH) header extension from [RFC5651] 🎀
a few fields get added on top of HET and HEL 💅
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (=1) | HEL | ASID | rsvd|A| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R+ +
| anti-replay Sequence Number (SN) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| Signature |
+ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group-keyed MAC |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 6: Format of the Group-Keyed MAC EXT_AUTH Header Extension
here's what each field in the Group-keyed MAC EXT_AUTH header extension does 👑
ASID(4 bits): this one tells you which source authentication scheme or protocol is in use 🦋 the mapping between the ASID value and the actual scheme gets set up out-of-band, at session startup.rsvd(3 bits): this is a reserved field that MUST be set to zero and ignored by receivers 🌸AR(1 bit): the AR field MUST be set to 1, which means the anti-replay service is being used (see Section 6.3) 🔥SN(8 or 40 bits): this is the Sequence Number. Since AR = 1, it's a 40-bit field (32 bits + 8 bits), and all 40 bits MUST be considered by the anti-replay mechanism 💜Signature(variable size, multiple of 32 bits): this holds a Digital Signature of the message. If need be, it gets padded (with 0) up to a multiple of 32 bits 🧚Group-keyed MAC(variable size, multiple of 32 bits, by default 32 bits): this holds 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 Sections 3.2, 4.2, and 5.2 🎀
6.3. Processing
sometimes it's actually useful to run both authentication schemes together ✨ the whole point of the Group-keyed MAC is to help with denial-of-service (DoS) attacks coming from attackers who aren't group members [RFC4082], by putting a light authentication scheme in front as a bouncer 💅
6.3.1. Signature Processing
before sending a message, the sender sets the Signature field and the Group-keyed MAC field to zero 🫶 then the sender computes the signature like Section 3.3 or Section 4.3 describes and stores it in the Signature field 💖 next, the sender computes the Group-keyed MAC as detailed in Section 5.3 and stores that in the Group-keyed MAC field. so the (RSA or ECC) Digital Signature value is protected by the Group-keyed MAC, which stops DoS attacks where an attacker messes with the Digital Signature itself 🛡️✨
when a packet shows up, the receiver checks the Group-keyed MAC first, as detailed in Section 5.3. if that check fails, the packet MUST be immediately dropped. otherwise, the receiver checks the Digital Signature, as detailed in Section 3.3. if that check fails too, the packet MUST be immediately dropped 🔥
this scheme comes with a few limits, bestie 🥺
- 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 💀
- It requires an additional MAC computation for each packet, on both the sender and receiver sides 🙈
- It increases the size of the Authentication Headers. To keep this problem in check, the length of the truncated output of the MAC,
n_m, SHOULD be kept small (see Section 9.5 of [RFC3711]). In the current specification,n_mMUST be a multiple of 32 bits, and the default value is 32 bits. As a side effect, withn_m= 32 bits, the authentication service is significantly weakened, since the probability that any packet would be successfully forged is one in 2^32. Since the Group-keyed MAC check is only a pre-check that's followed by the standard signature authentication check, this is not considered to be an issue 🌈
for any 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 🎀 and honestly, not enabling anti-replay protection would make DoS attacks way easier 😭 because all replayed (but otherwise valid) packets would slide right past the light authentication scheme and force a receiver to do 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 they might not be able to parse its content, for instance because they don't 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. every packet that fails to 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) 🍓
for example, 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 the Signature field is 128 bytes long). the EXT_AUTH header extension is then 140 bytes long 🧚
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (=1) | HEL (=35) | ASID | 0 |1| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| anti-replay Sequence Number (SN) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| | ^ 1
+ + | 2
| | | 8
. . |
. Signature (128 bytes) . | b
. . | y
| | | t
+ + | e
| | v s
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| Group-keyed MAC (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---Figure 7: Example: Format of the Combined RSA Digital Signature/ Group-Keyed MAC EXT_AUTH Header Extension Using 1024-Bit Signatures, with Anti-Replay Protection
7. Security Considerations 🛡️
7.1. Dealing with DoS Attacks
okay let's start with packets secured using a Digital Signature scheme 👀 faking packets is super easy, but checking them means running a costly Digital Signature computation. so this scheme opens up new chances for an attacker to pull off DoS attacks. basically, an attacker can easily saturate the receiver's processing capabilities 😭
to fight these attacks, it is RECOMMENDED that the combined Digital Signature/Group-keyed MAC scheme (Section 6.3) be used. however, no mitigation is possible if a group member is the one acting as the attacker 💀 and even though checking a Group-keyed MAC is way faster than checking a Digital Signature, there are practical limits on how many Group-keyed MACs can be checked per time unit. so it is RECOMMENDED that the number of authentication checks per time unit get limited when the number of incoming packets failing the authentication check goes over a given threshold (i.e., in the case of a DoS attack) 🔥
that RECOMMENDED move of limiting checks per time unit under (presumed) attack can be extended to the other authentication schemes too 🌸
7.2. Dealing with Replay Attacks
replay attacks are when an attacker stores a valid message and replays it later 👻 it is RECOMMENDED that the anti-replay service defined in this document be used with the signature and Group-keyed MAC solutions, and this anti-replay service MUST be used when combining signatures and Group-keyed MAC schemes (see Section 6.3.2) 🫶
the next section walks through some of the potential consequences of not using anti-replay protection 🧐
7.2.1. Impacts of Replay Attacks on the Simple Authentication Schemes
since all of the above authentication schemes are stateless, replay attacks have no impact on these schemes 💖
7.2.2. Impacts of Replay Attacks on NORM 🌊
okay so in this bit we check out what a replay attack could do to the NORM component 👀 quick heads up: we are NOT looking at other protocols you might run alongside NORM, like congestion control stuff 💅
first up, replay attacks inside one NORM session 🎀 NORM is stateful, so replaying a packet can actually have consequences. not nothing, ngl 🙈
NORM has a sequence field that can help protect against replay attacks [RFC5740] within a given NORM session. it's a 16-bit value that the message originator (sender or receiver) sets as a monotonically increasing number, bumped with every NORM message transmitted. using it for anti-replay only works if there's no wrap back to zero, which means at most 65535 packets get sent. that could be true for some use cases, but not the general case 😭 it also works if the keying material gets updated before the wrap to zero happens. same deal: maybe for some use cases, not the general one ✨
now, replay attacks across several NORM sessions 🦋 a host taking part in a NORM session is uniquely identified by the {source_id; instance_id} tuple. so when one host is in several NORM sessions, it is RECOMMENDED that instance_id be changed for each NORM instance. it is also RECOMMENDED, when the Group-keyed MAC authentication/integrity check scheme is used, that the shared group key be changed across sessions. with both of those in place, NORM can be made robust against replay attacks across different sessions 👑
7.2.3. Impacts of Replay Attacks on ALC 🧚
okay now the ALC component 💖 same idea: we're skipping the protocols that could run alongside ALC, like layered or wave-based congestion control 🌸
first, replay attacks inside one ALC session:
- Replayed encoding symbol: a replayed encoding symbol (coming from a replayed data packet) gets detected, thanks to the object/block/symbol identifiers, and is silently discarded. ✨
- Replayed control information:
- at the end of the session, a "close session" (A flag) packet is sent. replaying a packet with this flag has no impact, since the receivers have already left the session 🙌
- similarly, replaying a packet containing a "close object" (B flag) has no impact, since this object is probably already marked as closed by the receiver 💅
- timing information sent as part of a Layered Coding Transport (LCT) EXT_TIME header extension [RFC5651] may be more sensitive to replay attacks. for example, replaying a packet containing an ERT (Expected Residual Time) could mislead a receiver into thinking an object transmission will keep going for a while, when symbols for that object are actually about to stop 😬 replaying a packet with a Sender Current Time (SCT) is easy to spot if the receiver checks that time moves forward when it gets these EXT_TIME header extensions. replaying a packet with a Session Last Changed (SLC) is also easy to spot if the receiver checks the chronology when it gets these 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 against replay attacks within the same session 🫶
now replay attacks across several ALC sessions 🌈 an ALC session is uniquely identified by the {sender IP address; TSI} tuple. so when one sender creates several sessions, the TSI MUST be changed for each ALC session, so that each TSI is unique among all active sessions of this sender and for a long period of time before and after the session is active [RFC5651]. with that, ALC can be made robust against replay attacks across different sessions. and 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 🔥
7.3. Dealing with Attacks on the Parameters Sent Out-of-Band 📦
this specification requires that several parameters be communicated to the receiver(s) through an out-of-band mechanism that is beyond the scope of this document. the big one is the mapping between an ASID value and its 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) 🔐
8. Acknowledgments 🫶
the author is so grateful to the authors of [RFC4303], [RFC4359], [RFC4754], and [RFC5480]. their documents inspired several sections of this one 💜 the author is also grateful to all the IESG members, and especially David Harrington, Stephen Farrell, and Sean Turner for their super detailed reviews 🙏
9. References 📚
9.1. Normative References
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding
Transport (LCT) Building Block", RFC 5651, October 2009.
[RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker,
"NACK-Oriented Reliable Multicast (NORM) Transport
Protocol", RFC 5740, November 2009.
[RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous
Layered Coding (ALC) Protocol Instantiation", RFC 5775,
April 2010.9.2. Informative References
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and
K. Norrman, "The Secure Real-time Transport Protocol
(SRTP)", RFC 3711, March 2004.
[RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B.
Briscoe, "Timed Efficient Stream Loss-Tolerant
Authentication (TESLA): Multicast Source Authentication
Transform Introduction", RFC 4082, June 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within
Encapsulating Security Payload (ESP) and Authentication
Header (AH)", RFC 4359, January 2006.
[RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication
Using the Elliptic Curve Digital Signature Algorithm
(ECDSA)", RFC 4754, January 2007.
[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, March 2012.Author's Address 💌
Vincent Roca
INRIA
655, av. de l'Europe
Inovallee; Montbonnot
ST ISMIER cedex 38334
France
EMail: vincent.roca@inria.fr
URI: http://planete.inrialpes.fr/people/roca/📦 where this page comes from
- ietf: rfc6584 2012-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms