| < draft-ietf-msec-srtp-tesla-04.txt | draft-ietf-msec-srtp-tesla-05.txt > | |||
|---|---|---|---|---|
| Internet Engineering Task Force Baugher (Cisco) | Internet Engineering Task Force Baugher (Cisco) | |||
| MSEC Working Group Carrara (Ericsson) | MSEC Working Group Carrara (Ericsson) | |||
| INTERNET-DRAFT | INTERNET-DRAFT | |||
| EXPIRES: March 2006 September 2005 | EXPIRES: April 2006 October 2005 | |||
| The Use of TESLA in SRTP | The Use of TESLA in SRTP | |||
| <draft-ietf-msec-srtp-tesla-04.txt> | <draft-ietf-msec-srtp-tesla-05.txt> | |||
| Status of this memo | Status of this memo | |||
| By submitting this Internet-Draft, each author represents | By submitting this Internet-Draft, each author represents that any | |||
| that any applicable patent or other IPR claims of which he | applicable patent or other IPR claims of which he or she is aware | |||
| or she is aware have been or will be disclosed, and any of | have been or will be disclosed, and any of which he or she becomes | |||
| which he or she becomes aware will be disclosed, in | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
| accordance with Section 6 of BCP 79. | ||||
| By submitting this Internet-Draft, the authors accept the provisions | ||||
| of BCP 78. | ||||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
| other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
| Drafts. | Drafts. | |||
| Internet-Drafts are draft documents valid for a maximum of six | Internet-Drafts are draft documents valid for a maximum of six | |||
| months and may be updated, replaced, or obsoleted by other documents | months and may be updated, replaced, or obsoleted by other documents | |||
| at any time. It is inappropriate to use Internet-Drafts as | at any time. It is inappropriate to use Internet-Drafts as | |||
| reference material or cite them other than as "work in progress". | reference material or cite them other than as "work in progress". | |||
| skipping to change at page 2, line ? ¶ | skipping to change at page 2, line ? ¶ | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html | http://www.ietf.org/shadow.html | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (C) The Internet Society (2005). All Rights Reserved. | Copyright (C) The Internet Society (2005). All Rights Reserved. | |||
| Abstract | Abstract | |||
| This memo describes the use of the Timed Efficient Stream loss- | This memo describes the use of the Timed Efficient Stream Loss- | |||
| tolerant Authentication (TESLA) transform within the Secure Real- | tolerant Authentication (RFC4082) transform within the Secure Real- | |||
| time Transport Protocol (SRTP), to provide data origin | time Transport Protocol (SRTP), to provide data origin | |||
| authentication for multicast and broadcast data streams. | authentication for multicast and broadcast data streams. | |||
| TABLE OF CONTENTS | TABLE OF CONTENTS | |||
| 1. Introduction...................................................2 | 1. Introduction...................................................2 | |||
| 1.1. Notational Conventions.......................................3 | 1.1. Notational Conventions.......................................3 | |||
| 2. SRTP...........................................................3 | 2. SRTP...........................................................3 | |||
| 3. TESLA..........................................................4 | 3. TESLA..........................................................4 | |||
| 4. Usage of TESLA within SRTP.....................................4 | 4. Usage of TESLA within SRTP.....................................4 | |||
| 4.1. The TESLA extension..........................................4 | 4.1. The TESLA extension..........................................4 | |||
| 4.2. SRTP Packet Format...........................................5 | 4.2. SRTP Packet Format...........................................5 | |||
| 4.3. Extension of the SRTP Cryptographic Context..................7 | 4.3. Extension of the SRTP Cryptographic Context..................7 | |||
| 4.4. SRTP Processing..............................................8 | 4.4. SRTP Processing..............................................8 | |||
| 4.4.1 Sender Processing...........................................9 | 4.4.1 Sender Processing...........................................9 | |||
| 4.4.2 Receiver Processing.........................................9 | 4.4.2 Receiver Processing.........................................9 | |||
| 4.5. SRTCP Packet Format.........................................10 | 4.5. SRTCP Packet Format.........................................11 | |||
| 4.6. TESLA MAC...................................................12 | 4.6. TESLA MAC...................................................13 | |||
| 4.7. PRFs........................................................13 | 4.7. PRFs........................................................13 | |||
| 5. TESLA Bootstrapping and Cleanup...............................13 | 5. TESLA Bootstrapping and Cleanup...............................14 | |||
| 6. SRTP TESLA Default parameters.................................13 | 6. SRTP TESLA Default parameters.................................14 | |||
| 6.2 Transform-dependent Parameters for TESLA MAC.................14 | 7. Security Considerations.......................................15 | |||
| 7. Security Considerations.......................................15 | 8. IANA Considerations...........................................16 | |||
| 8. IANA Considerations...........................................16 | 9. Acknowledgements..............................................16 | |||
| 9. Acknowledgements..............................................16 | 10. Author's Addresses...........................................17 | |||
| 10. Author's Addresses...........................................16 | 11. References...................................................17 | |||
| 11. References...................................................16 | ||||
| 1. Introduction | 1. Introduction | |||
| Multicast and broadcast communications introduce some new security | Multicast and broadcast communications introduce some new security | |||
| challenges compared to unicast communication. Many multicast and | challenges compared to unicast communication. Many multicast and | |||
| broadcast applications need "data origin authentication" (DOA), or | broadcast applications need "data origin authentication" (DOA), or | |||
| "source authentication", in order to guarantee that a received | "source authentication", in order to guarantee that a received | |||
| message had originated from a given source, and was not manipulated | message had originated from a given source, and was not manipulated | |||
| during the transmission. In unicast communication, a pairwise | during the transmission. In unicast communication, a pairwise | |||
| security association between one sender and one receiver can provide | security association between one sender and one receiver can provide | |||
| data origin authentication using symmetric-key cryptography (such as | data origin authentication using symmetric-key cryptography (such as | |||
| a message authentication code, MAC). When the communication is | a message authentication code, MAC). When the communication is | |||
| strictly pairwise, the sender and receiver agree upon a key that is | strictly pairwise, the sender and receiver agree upon a key that is | |||
| known only to them. | known only to them. | |||
| In groups, however, a key is shared among more than two members, and | In groups, however, a key is shared among more than two members, and | |||
| this symmetric-key approach does not guarantee data origin | this symmetric-key approach does not guarantee data origin | |||
| authentication. When there is a group security association | authentication. When there is a group security association | |||
| [gkmarch] instead of a pairwise security association, any of the | [RFC4046] instead of a pairwise security association, any of the | |||
| members can alter the packet and impersonate any other member. The | members can alter the packet and impersonate any other member. The | |||
| MAC in this case only guarantees that the packet was not manipulated | MAC in this case only guarantees that the packet was not manipulated | |||
| by an attacker outside the group (and hence not in possession of the | by an attacker outside the group (and hence not in possession of the | |||
| group key), and that the packet was sent by a source within the | group key), and that the packet was sent by a source within the | |||
| group. | group. | |||
| Some applications cannot tolerate source ambiguity and must discern | Some applications cannot tolerate source ambiguity and need to | |||
| the true sender from any other group member. A common way to solve | identify the true sender from any other group member. A common way | |||
| the problem is by use of asymmetric cryptography, such as digital | to solve the problem is by use of asymmetric cryptography, such as | |||
| signatures. This method, unfortunately, suffers from high overhead, | digital signatures. This method, unfortunately, suffers from high | |||
| in terms of time (to sign and verify) and bandwidth (to convey the | overhead, in terms of time (to sign and verify) and bandwidth (to | |||
| signature in the packet). | convey the signature in the packet). | |||
| Several schemes have been proposed to provide efficient data origin | Several schemes have been proposed to provide efficient data origin | |||
| authentication in multicast and broadcast scenarios. The Timed | authentication in multicast and broadcast scenarios. The Timed | |||
| Efficient Stream loss-tolerant Authentication (TESLA) is one such | Efficient Stream Loss-tolerant Authentication (TESLA) is one such | |||
| scheme. | scheme. | |||
| This memo specifies TESLA authentication for SRTP. SRTP TESLA can | This memo specifies TESLA authentication for SRTP. SRTP TESLA can | |||
| provide data origin authentication to RTP applications that use | provide data origin authentication to RTP applications that use | |||
| group security associations (such as multicast RTP applications) so | group security associations (such as multicast RTP applications) so | |||
| long as receivers abide by the TESLA security invariants [TESLA]. | long as receivers abide by the TESLA security invariants [RFC4082]. | |||
| 1.1. Notational Conventions | 1.1. Notational Conventions | |||
| The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
| document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
| This specification assumes the reader familiar with both SRTP and | This specification assumes the reader is familiar with both SRTP and | |||
| TESLA. Few of their details are explained in this document, and the | TESLA. Few of their details are explained in this document, and the | |||
| reader can find them in their respective specifications, [RFC3711] | reader can find them in their respective specifications, [RFC3711] | |||
| and [TESLA]. This specification uses the same definitions as TESLA | and [RFC4082]. This specification uses the same definitions as | |||
| for common terms and assumes that the reader is familiar with the | TESLA for common terms and assumes that the reader is familiar with | |||
| TESLA algorithms and protocols [TESLA]. | the TESLA algorithms and protocols [RFC4082]. | |||
| 2. SRTP | 2. SRTP | |||
| The Secure Real-time Transport Protocol (SRTP) [RFC3711] is a | The Secure Real-time Transport Protocol (SRTP) [RFC3711] is a | |||
| profile of RTP, which can provide confidentiality, message | profile of RTP, which can provide confidentiality, message | |||
| authentication, and replay protection to the RTP traffic and to the | authentication, and replay protection to the RTP traffic and to the | |||
| RTP control protocol, the Real-time Transport Control Protocol | RTP control protocol, the Real-time Transport Control Protocol | |||
| (RTCP). Note, the term "SRTP" may often be used to indicate SRTCP | (RTCP). Note, the term "SRTP" may often be used to indicate SRTCP | |||
| as well. | as well. | |||
| SRTP is a framework that allows new security functions and new | SRTP is a framework that allows new security functions and new | |||
| transforms to be added. SRTP currently does not define any | transforms to be added. SRTP currently does not define any | |||
| mechanism to provide data origin authentication for group security | mechanism to provide data origin authentication for group security | |||
| associations. Fortunately, it is straightforward to add TESLA to | associations. Fortunately, it is straightforward to add TESLA to | |||
| the SRTP cryptographic framework. | the SRTP cryptographic framework. | |||
| The TESLA extension to SRTP is defined in this specification, which | The TESLA extension to SRTP is defined in this specification, which | |||
| assumes that the reader is familiar with the SRTP specification | assumes that the reader is familiar with the SRTP specification | |||
| [RFC3711], its packet structure, and processing rules. | [RFC3711], its packet structure, and processing rules. TESLA is an | |||
| alternative message-authentication algorithm that authenticates | ||||
| messages from the source when a key is shared among two or more | ||||
| receivers. | ||||
| 3. TESLA | 3. TESLA | |||
| TESLA provides delayed per-packet data authentication and is | TESLA provides delayed per-packet data authentication and is | |||
| specified in [TESLA]. | specified in [RFC4082]. | |||
| In addition to its SRTP data-packet definition given here, TESLA | In addition to its SRTP data-packet definition given here, TESLA | |||
| needs an initial synchronization protocol and initial bootstrapping | needs an initial synchronization protocol and initial bootstrapping | |||
| procedure. The synchronization protocol allows the sender and the | procedure. The synchronization protocol allows the sender and the | |||
| receiver to compare their clocks and determine an upper bound of the | receiver to compare their clocks and determine an upper bound of the | |||
| difference. The synchronization protocol is outside the scope of | difference. The synchronization protocol is outside the scope of | |||
| this document. | this document. | |||
| TESLA also requires an initial bootstrapping procedure to exchange | TESLA also requires an initial bootstrapping procedure to exchange | |||
| needed parameters and the initial commitment to the key chain | needed parameters and the initial commitment to the key chain | |||
| [TESLA]. For SRTP, it is assumed that the bootstrapping is | [RFC4082]. For SRTP, it is assumed that the bootstrapping is | |||
| performed out-of-band, possibly using the key management protocol | performed out-of-band, possibly using the key management protocol | |||
| that is exchanging the security parameters for SRTP, e.g. [GDOI, | that is exchanging the security parameters for SRTP, e.g. [RFC3547, | |||
| RFC3830]. Initial bootstrapping of TESLA is outside the scope of | RFC3830]. Initial bootstrapping of TESLA is outside the scope of | |||
| this document. | this document. | |||
| 4. Usage of TESLA within SRTP | 4. Usage of TESLA within SRTP | |||
| The present specification is an extension to the SRTP specification | The present specification is an extension to the SRTP specification | |||
| [RFC3711] and describes the use of TESLA with only a single key | [RFC3711] and describes the use of TESLA with only a single key | |||
| chain and delayed-authentication [TESLA]. | chain and delayed-authentication [RFC4082]. | |||
| 4.1. The TESLA extension | 4.1. The TESLA extension | |||
| TESLA is an OPTIONAL authentication transform for SRTP. When used, | TESLA is an OPTIONAL authentication transform for SRTP. When used, | |||
| TESLA adds the fields shown in Figure 1 per-packet. The fields | TESLA adds the fields shown in Figure 1 per-packet. The fields | |||
| added by TESLA are called "TESLA authentication extensions" | added by TESLA are called "TESLA authentication extensions," whereas | |||
| altogether, whereas "authentication tag" or "integrity protection | "authentication tag" or "integrity protection tag" indicate the | |||
| tag" indicate the normal SRTP integrity protection tag, when the | normal SRTP integrity protection tag, when the SRTP master key is | |||
| SRTP master key is shared by more than two endpoints [RFC3711]. | shared by more than two endpoints [RFC3711]. | |||
| 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 | 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 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | i | | | i | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| ~ Disclosed Key ~ | ~ Disclosed Key ~ | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| ~ TESLA MAC ~ | ~ TESLA MAC ~ | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 1: The "TESLA authentication extension". | Figure 1: The "TESLA authentication extension". | |||
| i: 32 bit, MANDATORY | i: 32 bit, MANDATORY | |||
| Identifier of the time interval i, corresponding to the key K_i | Identifier of the time interval i, corresponding to the key K_i | |||
| that is used to calculate the TESLA MAC of the current packet | that is used to calculate the TESLA MAC of the current packet | |||
| (and other packets sent in the current time interval i). | (and other packets sent in the current time interval i). | |||
| Disclosed Key: variable length, MANDATORY | Disclosed Key: variable length, MANDATORY | |||
| The disclosed key (K_(i-d)), that can be used to authenticate | The disclosed key (K_(i-d)), that can be used to authenticate | |||
| previous packets from earlier time intervals [TESLA]. | previous packets from earlier time intervals [RFC4082]. A | |||
| Section 4.3 parameter establishes the size of this field. | ||||
| TESLA MAC (Message Authentication Code): variable length, MANDATORY | TESLA MAC (Message Authentication Code): variable length, MANDATORY | |||
| The MAC computed using the key K'_i (derived from K_i) [TESLA], | The MAC computed using the key K'_i (derived from K_i) | |||
| which is disclosed in a subsequent packet (in the Disclosed Key | [RFC4082], which is disclosed in a subsequent packet (in the | |||
| field). The MAC coverage is defined in Section 4.6. | Disclosed Key field). The MAC coverage is defined in Section | |||
| 4.6. A Section 4.3 parameter establishes the size of this | ||||
| field. | ||||
| 4.2. SRTP Packet Format | 4.2. SRTP Packet Format | |||
| Figure 2 illustrates the format of the SRTP packet when TESLA is | Figure 2 illustrates the format of the SRTP packet when TESLA is | |||
| applied. When applied to RTP, the TESLA authentication extension | applied. When applied to RTP, the TESLA authentication extension | |||
| SHALL be inserted before the (optional) SRTP MKI and (recommended) | SHALL be inserted before the (optional) SRTP MKI and (recommended) | |||
| authentication tag (SRTP MAC). | authentication tag (SRTP MAC). | |||
| 0 1 2 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 | 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 | |||
| skipping to change at page 6, line 38 ¶ | skipping to change at page 6, line 38 ¶ | |||
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<|-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<|-+ | |||
| | ~ MKI ~ | | | | ~ MKI ~ | | | |||
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | |||
| | ~ MAC ~ | | | | ~ MAC ~ | | | |||
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | |||
| | | | | | | | | |||
| +- Encrypted Portion TESLA Authenticated Portion ---+ | | +- Encrypted Portion TESLA Authenticated Portion ---+ | | |||
| | | | | |||
| Authenticated Portion ---+ | Authenticated Portion ---+ | |||
| Figure 2. The format of the SRTP packet when TESLA is applied. Note | Figure 2. The format of the SRTP packet when TESLA is applied. | |||
| that it is OPTIONAL to apply TESLA, i.e. the TESLA fields are | ||||
| OPTIONAL. | ||||
| As in SRTP, the "Encrypted Portion" of an SRTP packet consists of | As in SRTP, the "Encrypted Portion" of an SRTP packet consists of | |||
| the encryption of the RTP payload (including RTP padding when | the encryption of the RTP payload (including RTP padding when | |||
| present) of the equivalent RTP packet. | present) of the equivalent RTP packet. | |||
| The "Authenticated Portion" of an SRTP packet consists of the RTP | The "Authenticated Portion" of an SRTP packet consists of the RTP | |||
| header, the Encrypted Portion of the SRTP packet, and the TESLA | header, the Encrypted Portion of the SRTP packet, and the TESLA | |||
| authentication extension. Note that the definition is extended from | authentication extension. Note that the definition is extended from | |||
| [RFC3711] by the inclusion of the TESLA authentication extension. | [RFC3711] by the inclusion of the TESLA authentication extension. | |||
| The "TESLA Authenticated Portion" of an SRTP packet consists of the | The "TESLA Authenticated Portion" of an SRTP packet consists of the | |||
| RTP header and the Encrypted Portion of the SRTP packet. As shown in | RTP header and the Encrypted Portion of the SRTP packet. As shown in | |||
| Figure 2, SRTP HMAC-SHA1 covers up to the MKI field but does not | Figure 2, SRTP HMAC-SHA1 covers up to the MKI field but does not | |||
| include MKI. SRTP does not cover the MKI field (because it does not | include the MKI. It is necessary for packet integrity that the | |||
| need to be covered for SRTP packet integrity). In order to make the | SRTP-TESLA tag be covered by the SRTP integrity check. SRTP does | |||
| two tags (SRTP-TESLA and SRTP-HMAC_SHA1) contiguous, we would need | not cover the MKI field (because it does not need to be covered for | |||
| to redefine the SRTP specification to include the MKI in HMAC-SHA1 | SRTP packet integrity). In order to make the two tags (SRTP-TESLA | |||
| coverage. This change is impossible and so the MKI field separates | and SRTP-HMAC_SHA1) contiguous, we would need to redefine the SRTP | |||
| the TESLA MAC from the SRTP MAC in the packet layout of Figure 2. | specification to include the MKI in HMAC-SHA1 coverage. This change | |||
| This change to the packet format presents no problem to an | is impossible and so the MKI field separates the TESLA MAC from the | |||
| implementation that supports the new SRTP-TESLA authentication | SRTP MAC in the packet layout of Figure 2. This change to the | |||
| transform. | packet format presents no problem to an implementation that supports | |||
| the new SRTP-TESLA authentication transform. | ||||
| The lengths of the Disclosed Key and TELSA MAC fields are Section | ||||
| 4.3 parameters. As in SRTP, fields that follow the packet payload | ||||
| are not necessarily aligned on 32-bit boundaries. | ||||
| 4.3. Extension of the SRTP Cryptographic Context | 4.3. Extension of the SRTP Cryptographic Context | |||
| When TESLA is used, the definition of cryptographic context in | When TESLA is used, the definition of cryptographic context in | |||
| Section 3.2 of SRTP SHALL include the following extensions. | Section 3.2 of SRTP SHALL include the following extensions. | |||
| Transform-dependent Parameters | Transform-dependent Parameters | |||
| 1. an identifier for the PRF, f, implementing the one-way function | 1. an identifier for the PRF, f, implementing the one-way function | |||
| F(x) in TESLA (to derive the keys in the chain), e.g. to | F(x) in TESLA (to derive the keys in the chain), e.g. to | |||
| indicate HMAC-SHA1, see Section 6.2 for the default value. | indicate HMAC-SHA1, see Section 6 for the default value. | |||
| 2. a non-negative integer n_p, determining the length of the F | 2. a non-negative integer n_p, determining the length of the F | |||
| output, i.e. the length of the keys in the chain (that is also | output, i.e. the length of the keys in the chain (that is also | |||
| the key disclosed in an SRTP packet), see Section 6.2 for the | the key disclosed in an SRTP packet), see Section 6 for the | |||
| default value. | default value. | |||
| 3. an identifier for the PRF, f', implementing the one-way | 3. an identifier for the PRF, f', implementing the one-way | |||
| function F'(x) in TESLA (to derive the keys for the TESLA MAC, | function F'(x) in TESLA (to derive the keys for the TESLA MAC, | |||
| from the keys in the chain), e.g. to indicate HMAC-SHA1, see | from the keys in the chain), e.g. to indicate HMAC-SHA1, see | |||
| Section 6.2 for the default value. | Section 6 for the default value. | |||
| 4. a non-negative integer n_f, determining the length of the | ||||
| output of F', i.e. of the key for the TESLA MAC, see Section | ||||
| 6.2 for the default value. | ||||
| 5. an identifier for the TESLA MAC, that accepts the output of | 4. a non-negative integer n_f, determining the length of the | |||
| F'(x) as its key, e.g. to indicate HMAC-SHA1, see Section 6.2 | output of F', i.e. of the key for the TESLA MAC, see Section 6 | |||
| for the default value. | for the default value. | |||
| 6. a non-negative integer n_m, determining the length of the | 5. an identifier for the TESLA MAC, that accepts the output of | |||
| output of the TESLA MAC, see Section 6.2 for the default value. | F'(x) as its key, e.g. to indicate HMAC-SHA1, see Section 6 for | |||
| the default value. | ||||
| 7. the beginning of the session T_0, | 6. a non-negative integer n_m, determining the length of the | |||
| 8. the interval duration T_int (in msec), | output of the TESLA MAC, see Section 6 for the default value. | |||
| 9. the key disclosure delay d (in number of intervals) | 7. the beginning of the session T_0, | |||
| 10. the upper bound D_t (in sec) on the lag of the receiver clock | 8. the interval duration T_int (in msec), | |||
| 9. the key disclosure delay d (in number of intervals) | ||||
| 10. the upper bound D_t (in sec) on the lag of the receiver clock | ||||
| relative to the sender clock (this quantity has to be | relative to the sender clock (this quantity has to be | |||
| calculated by the peers out-of-band) | calculated by the peers out-of-band) | |||
| 11. non-negative integer n_c, determining the length of the key | 11. non-negative integer n_c, determining the length of the key | |||
| chain, which is determined based upon the expected duration of | chain, K_0...K_n-1 of [RFC4082] (see also Section 6 of this | |||
| the stream. | document), which is determined based upon the expected duration | |||
| of the stream. | ||||
| 12. the initial key of the chain to which the sender has | 12. the initial key of the chain to which the sender has | |||
| committed himself. | committed himself. | |||
| F(x) is used to compute a keychain of keys in SRTP TESLA, as defined | F(x) is used to compute a keychain of keys in SRTP TESLA, as defined | |||
| in Section 6. Also according to TESLA, F'(x) computes a TESLA MAC | in Section 6. Also according to TESLA, F'(x) computes a TESLA MAC | |||
| key with inputs as defined in Section 6. | key with inputs as defined in Section 6. | |||
| Section 6 of this document defines the default values for the | Section 6 of this document defines the default values for the | |||
| transform-independent and transform-specific TESLA parameters. | transform-specific TESLA parameters. | |||
| 4.4. SRTP Processing | 4.4. SRTP Processing | |||
| The SRTP packet processing is described in Section 3.3 of the SRTP | The SRTP packet processing is described in Section 3.3 of the SRTP | |||
| specification [RFC3711]. The use of TESLA slightly changes the | specification [RFC3711]. The use of TESLA slightly changes the | |||
| processing, as the SRTP MAC is checked upon packet arrival for DoS | processing, as the SRTP MAC is checked upon packet arrival for DoS | |||
| prevention, but the current packet is not TESLA-authenticated. Each | prevention, but the current packet is not TESLA-authenticated. Each | |||
| packet is buffered until a subsequent packet discloses its TESLA | packet is buffered until a subsequent packet discloses its TESLA | |||
| key. The TESLA verification itself consists of some steps, such as | key. The TESLA verification itself consists of some steps, such as | |||
| tests of TESLA security invariants, that are described in Section | tests of TESLA security invariants, that are described in Section | |||
| 3.5-3.7 of [TESLA]. The words "TESLA computation" and "TESLA | 3.5-3.7 of [RFC4082]. The words "TESLA computation" and "TESLA | |||
| verification" hereby imply all those steps, which are not all | verification" hereby imply all those steps, which are not all | |||
| spelled out in the following. In particular, notice that the TESLA | spelled out in the following. In particular, notice that the TESLA | |||
| verification implies checking the safety condition (Section 3.5 of | verification implies checking the safety condition (Section 3.5 of | |||
| [TESLA]). | [RFC4082]). | |||
| As pointed out in [TESLA], if the packet is deemed "unsafe", then | As pointed out in [RFC4082], if the packet is deemed "unsafe", then | |||
| the receiver considers the packet unauthenticated. It should discard | the receiver considers the packet unauthenticated. It should discard | |||
| unsafe packets but, at its own risk, it may choose to use them | unsafe packets but, at its own risk, it may choose to use them | |||
| unverified. Hence, if the safe condition does not hold, it is | unverified. Hence, if the safe condition does not hold, it is | |||
| RECOMMENDED to discard the packet and log the event. | RECOMMENDED to discard the packet and log the event. | |||
| 4.4.1 Sender Processing | 4.4.1 Sender Processing | |||
| The sender processing is as described in Section 3.3 of [RFC3711], | The sender processing is as described in Section 3.3 of [RFC3711, up | |||
| up to step 5 included. After that the following process is | to step 5 inclusive. After that the following process is followed: | |||
| followed: | ||||
| 6. When TESLA is applied, identify the key in the TESLA chain to be | 6. When TESLA is applied, identify the key in the TESLA chain to be | |||
| used in the current time interval, and the TESLA MAC key derived | used in the current time interval, and the TESLA MAC key derived | |||
| from it. Execute the TESLA computation to obtain the TESLA | from it. Execute the TESLA computation to obtain the TESLA | |||
| authentication extension for the current packet, by appending the | authentication extension for the current packet, by appending the | |||
| current interval identifier (as i field), the disclosed key of the | current interval identifier (as i field), the disclosed key of the | |||
| chain for an earlier interval, and the TESLA MAC under the current | chain for the previous disclosure interval (i.e. the key for | |||
| key from the chain. This step uses the related TESLA parameters from | interval i is disclosed in interval i+d), and the TESLA MAC under | |||
| the crypto context as for Step 4. | the current key from the chain. This step uses the related TESLA | |||
| parameters from the crypto context as for Step 4. | ||||
| 7. If the MKI indicator in the SRTP crypto context is set to one, | 7. If the MKI indicator in the SRTP crypto context is set to one, | |||
| append the MKI to the packet. | append the MKI to the packet. | |||
| 8. When TESLA is applied, and if the SRTP authentication (external | 8. When TESLA is applied, and if the SRTP authentication (external | |||
| tag) is required (for DoS), compute the authentication tag as | tag) is required (for DoS), compute the authentication tag as | |||
| described in step 7 of Section 3.3 of the SRTP specification, but | described in step 7 of Section 3.3 of the SRTP specification, but | |||
| with coverage as defined in this specification (see Section 4.6). | with coverage as defined in this specification (see Section 4.6). | |||
| 9. If necessary, update the ROC (step 8 in Section 3.3 of | 9. If necessary, update the rollover counter (step 8 in Section 3.3 | |||
| [RFC3711]). | of [RFC3711]). | |||
| 4.4.2 Receiver Processing | 4.4.2 Receiver Processing | |||
| The receiver processing is as described in Section 3.3 of [RFC3711], | The receiver processing is as described in Section 3.3 of [RFC3711], | |||
| up to step 4 included. | up to step 4 inclusive. | |||
| To authenticate and replay-protect the current packet, the | To authenticate and replay-protect the current packet, the | |||
| processing is the following: | processing is as follows: | |||
| First check if the packet has been replayed (as for Section 3.3 of | First check if the packet has been replayed (as for Section 3.3 of | |||
| [RFC3711]). Note however, the SRTP replay list contains SRTP | [RFC3711]). Note however, the SRTP replay list contains SRTP | |||
| indices of recently received packets that have been authenticated | indices of recently received packets that have been authenticated | |||
| by TESLA (i.e. replay list updates MUST NOT be based on SRTP MAC). | by TESLA (i.e. replay list updates MUST NOT be based on SRTP MAC). | |||
| If the packet is judged to be replayed, then the packet MUST be | If the packet is judged to be replayed, then the packet MUST be | |||
| discarded, and the event SHOULD be logged. | discarded, and the event SHOULD be logged. | |||
| Next, perform verification of the SRTP integrity protection tag | Next, perform verification of the SRTP integrity protection tag | |||
| (note, not the TESLA MAC), if present, using the rollover counter | (note, not the TESLA MAC), if present, using the rollover counter | |||
| from the current packet, the authentication algorithm indicated in | from the current packet, the authentication algorithm indicated in | |||
| the cryptographic context, and the session authentication key. If | the cryptographic context, and the session authentication key. If | |||
| the verification is unsuccessful, the packet MUST be discarded | the verification is unsuccessful, the packet MUST be discarded | |||
| from further processing and the event SHOULD be logged. | from further processing and the event SHOULD be logged. | |||
| If the verification is successful, remove and store the MKI (if | If the verification is successful, remove and store the MKI (if | |||
| present) and authentication tag fields from the packet. The packet | present) and authentication tag fields from the packet. The packet | |||
| is buffered, awaiting disclosure of the TESLA key in a subsequent | is buffered, awaiting disclosure of the TESLA key in a subsequent | |||
| packet. | packet. | |||
| TESLA authentication is performed on a packet when the key is | TESLA authentication is performed on a packet when the key is | |||
| disclosed in a subsequent packet. When such key is disclosed, | disclosed in a subsequent packet. Recall that a key for interval i | |||
| perform the TESLA verification of the packet using the rollover | is disclosed during interval i+d, i.e. the same key is disclosed | |||
| counter from the packet, the TESLA security parameters from the | in packets sent over d intervals of length t_int. If the interval | |||
| cryptographic context, and the disclosed key. If the verification | identifier i from the packet (Section 4.1) has advanced more than | |||
| is unsuccessful, the packet MUST be discarded from further | d intervals from the highest value of i that has been received, | |||
| processing and the event SHOULD be logged. If the TESLA | then packets have been lost and one or more keys MUST be computed | |||
| verification is successful, remove the TESLA authentication | as described in Section 3.2, second paragraph, of the TESLA | |||
| extension from the packet. | specification [RFC4082]. The computation is performed recursively | |||
| for all disclosed keys that have been lost, from the newly- | ||||
| received interval to the last-received interval. | ||||
| When a newly-disclosed key is received or computed, perform the | ||||
| TESLA verification of the packet using the rollover counter from | ||||
| the packet, the TESLA security parameters from the cryptographic | ||||
| context, and the disclosed key. If the verification is | ||||
| unsuccessful, the packet MUST be discarded from further processing | ||||
| and the event SHOULD be logged. If the TESLA verification is | ||||
| successful, remove the TESLA authentication extension from the | ||||
| packet. | ||||
| To decrypt the current packet, the processing is the following: | To decrypt the current packet, the processing is the following: | |||
| Decrypt the Encrypted Portion of the packet, using the decryption | Decrypt the Encrypted Portion of the packet, using the decryption | |||
| algorithm indicated in the cryptographic context, the session | algorithm indicated in the cryptographic context, the session | |||
| encryption key and salt (if used) found in Step 4 with the index | encryption key and salt (if used) found in Step 4 with the index | |||
| from Step 2. | from Step 2. | |||
| (Note that the order of decryption and TESLA verification is not | (Note that the order of decryption and TESLA verification is not | |||
| mandated. It is RECOMMENDED to perform the TESLA verification | mandated. It is RECOMMENDED to perform the TESLA verification | |||
| skipping to change at page 11, line 4 ¶ | skipping to change at page 11, line 16 ¶ | |||
| Figure 3 illustrates the format of the SRTCP packet when TESLA is | Figure 3 illustrates the format of the SRTCP packet when TESLA is | |||
| applied. The TESLA authentication extension SHALL be inserted | applied. The TESLA authentication extension SHALL be inserted | |||
| before the MKI and authentication tag. Recall from [RFC3711] that | before the MKI and authentication tag. Recall from [RFC3711] that | |||
| in SRTCP the MKI is OPTIONAL, while the E-bit, the SRTCP index, and | in SRTCP the MKI is OPTIONAL, while the E-bit, the SRTCP index, and | |||
| the authentication tag are MANDATORY. This means that the SRTP | the authentication tag are MANDATORY. This means that the SRTP | |||
| (external) MAC is MANDATORY also when TESLA is used. | (external) MAC is MANDATORY also when TESLA is used. | |||
| As in SRTP, the "Encrypted Portion" of an SRTCP packet consists of | As in SRTP, the "Encrypted Portion" of an SRTCP packet consists of | |||
| the encryption of the RTCP payload of the equivalent compound RTCP | the encryption of the RTCP payload of the equivalent compound RTCP | |||
| packet, from the first RTCP packet, i.e., from the ninth (9) octet | packet, from the first RTCP packet, i.e., from the ninth (9) byte to | |||
| to the end of the compound packet. | the end of the compound packet. | |||
| The "Authenticated Portion" of an SRTCP packet consists of the | The "Authenticated Portion" of an SRTCP packet consists of the | |||
| entire equivalent (eventually compound) RTCP packet, the E flag, the | entire equivalent (eventually compound) RTCP packet, the E flag, the | |||
| SRTCP index (after any encryption has been applied to the payload), | SRTCP index (after any encryption has been applied to the payload), | |||
| and the TESLA extension. Note that the definition is extended from | and the TESLA extension. Note that the definition is extended from | |||
| [RFC3711] by the inclusion of the TESLA authentication extension. | [RFC3711] by the inclusion of the TESLA authentication extension. | |||
| We define the "TESLA Authenticated Portion" of an SRTCP packet as | We define the "TESLA Authenticated Portion" of an SRTCP packet as | |||
| consisting of the RTCP header (first 8 bytes) and the Encrypted | consisting of the RTCP header (first 8 bytes) and the Encrypted | |||
| Portion of the SRTCP packet. | Portion of the SRTCP packet. | |||
| skipping to change at page 12, line 15 ¶ | skipping to change at page 12, line 46 ¶ | |||
| | ~ SRTCP MKI ~ | | | | ~ SRTCP MKI ~ | | | |||
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | |||
| | : authentication tag : | | | | : authentication tag : | | | |||
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | |||
| | | | | | | | | |||
| +-- Encrypted Portion TESLA Authenticated Portion -----+ | | +-- Encrypted Portion TESLA Authenticated Portion -----+ | | |||
| | | | | |||
| Authenticated Portion -------+ | Authenticated Portion -------+ | |||
| Figure 3. The format of the SRTCP packet when TESLA is applied. | Figure 3. The format of the SRTCP packet when TESLA is applied. | |||
| Note that it is OPTIONAL to apply TESLA, i.e. the TESLA fields are | ||||
| OPTIONAL. | Note that when additional fields are added to a packet, it will | |||
| increase the packet size and thus the RTCP average packet size. | ||||
| 4.6. TESLA MAC | 4.6. TESLA MAC | |||
| Let M' denote packet data to be TESLA-authenticated. In the case of | Let M' denote packet data to be TESLA-authenticated. In the case of | |||
| SRTP, M' SHALL consist of the SRTP TESLA Authenticated Portion (RTP | SRTP, M' SHALL consist of the SRTP TESLA Authenticated Portion (RTP | |||
| header and SRTP Encrypted Portion, see Figure 2) of the packet | header and SRTP Encrypted Portion, see Figure 2) of the packet | |||
| concatenated with the ROC of the same packet: | concatenated with the rollover counter (ROC) of the same packet: | |||
| M' = ROC || TESLA Authenticated Portion. | M' = ROC || TESLA Authenticated Portion. | |||
| In the case of SRTCP, M' SHALL consist of the SRTCP TESLA | In the case of SRTCP, M' SHALL consist of the SRTCP TESLA | |||
| Authenticated Portion only (RTCP header and SRTCP Encrypted | Authenticated Portion only (RTCP header and SRTCP Encrypted | |||
| Portion). | Portion). | |||
| The normal authentication tag (OPTIONAL for SRTP, MANDATORY for | The normal authentication tag (OPTIONAL for SRTP, MANDATORY for | |||
| SRTCP) SHALL be applied with the same coverage as specified in | SRTCP) SHALL be applied with the same coverage as specified in | |||
| [RFC3711], i.e.: | [RFC3711], i.e.: | |||
| - for SRTP: Authenticated Portion || ROC (with the extended | - for SRTP: Authenticated Portion || ROC (with the extended | |||
| definition of SRTP Authentication Portion as for Section 4.2) | definition of SRTP Authentication Portion as in Section 4.2) | |||
| - for SRTCP: Authenticated Portion (with the extended definition of | - for SRTCP: Authenticated Portion (with the extended definition of | |||
| SRTCP Authentication Portion as for Section 4.2). | SRTCP Authentication Portion as in Section 4.2). | |||
| The pre-defined authentication transform in SRTP, HMAC-SHA1 | The pre-defined authentication transform in SRTP, HMAC-SHA1 | |||
| [RFC2104], is also used to generate the TESLA MAC. For SRTP | [RFC2104], is also used to generate the TESLA MAC. For SRTP | |||
| (respectively SRTCP), the HMAC SHALL be applied to the key in the | (respectively SRTCP), the HMAC SHALL be applied to the key in the | |||
| TESLA chain corresponding to a particular time interval, and M' as | TESLA chain corresponding to a particular time interval, and M' as | |||
| specified above. The HMAC output SHALL then be truncated to the n_m | specified above. The HMAC output SHALL then be truncated to the n_m | |||
| left-most bits. Default values are in Section 6.2. | left-most bits. Default values are in Section 6. | |||
| As with SRTP, the pre-defined HMAC-SHA1 authentication algorithm MAY | ||||
| be replaced with an alternative algorithm that is specified in a | ||||
| future Internet RFC. | ||||
| 4.7. PRFs | 4.7. PRFs | |||
| TESLA requires two pseudo-random functions (PRFs), f and f', to | TESLA requires two pseudo-random functions (PRFs), f and f', to | |||
| implement | implement | |||
| * one one-way function F(x) to derive the key chain, and | * one one-way function F(x) to derive the key chain, and | |||
| * one one-way function F'(x) to derive (from each key of the chain) | * one one-way function F'(x) to derive (from each key of the chain) | |||
| the key that is actually used to calculate the TESLA MAC. | the key that is actually used to calculate the TESLA MAC. | |||
| When TESLA is used within SRTP, the default choice of the two PRFs | When TESLA is used within SRTP, the default choice of the two PRFs | |||
| SHALL be HMAC-SHA1. Default values are in Section 6.2. | SHALL be HMAC-SHA1. Default values are in Section 6. | |||
| Other PRFs can be chosen, and their use SHALL follow the common | Other PRFs can be chosen, and their use SHALL follow the common | |||
| guidelines in [RFC3711] when adding new security parameters. | guidelines in [RFC3711] when adding new security parameters. | |||
| 5. TESLA Bootstrapping and Cleanup | 5. TESLA Bootstrapping and Cleanup | |||
| The extensions to the SRTP cryptographic context include a set of | The extensions to the SRTP cryptographic context include a set of | |||
| TESLA parameters that are listed in section 4.3 of this document. | TESLA parameters that are listed in section 4.3 of this document. | |||
| Furthermore, TESLA MUST be bootstrapped at session set-up (for the | Furthermore, TESLA MUST be bootstrapped at session set-up (for the | |||
| parameter exchange and the initial key commitment) through a regular | parameter exchange and the initial key commitment) through a regular | |||
| skipping to change at page 13, line 42 ¶ | skipping to change at page 14, line 27 ¶ | |||
| A critical factor for the security of TESLA is that the sender and | A critical factor for the security of TESLA is that the sender and | |||
| receiver need to be loosely synchronized. TESLA requires a bound on | receiver need to be loosely synchronized. TESLA requires a bound on | |||
| clock drift to be known (D_t). Use of TESLA in SRTP assumes that | clock drift to be known (D_t). Use of TESLA in SRTP assumes that | |||
| the time synchronization is guaranteed by out-of-band schemes (e.g. | the time synchronization is guaranteed by out-of-band schemes (e.g. | |||
| key management), i.e. it is not in the scope of SRTP. | key management), i.e. it is not in the scope of SRTP. | |||
| It also should be noted that TESLA has some reliability requirements | It also should be noted that TESLA has some reliability requirements | |||
| in that a key is disclosed for a packet in a subsequent packet, | in that a key is disclosed for a packet in a subsequent packet, | |||
| which can get lost. Since a key in a lost packet can be derived from | which can get lost. Since a key in a lost packet can be derived from | |||
| a future packet, TESLA is robust to packet loss. This repetition | a future packet, TESLA is robust to packet loss. This key stream | |||
| might abruptly stop, however, if the key-bearing packets stop | stops, however, when the key-bearing data stream packets stop at the | |||
| abruptly at the end of the stream. To avoid this nasty boundary | conclusion of the RTP session. To avoid this nasty boundary | |||
| condition, send null packets with TESLA keys for one entire interval | condition, send null packets with TESLA keys for one entire key- | |||
| following the interval in which the stream ceases. | disclosure period following the interval in which the stream ceases: | |||
| Null packets SHOULD be sent for d intervals of duration t_int (items | ||||
| 8 and 9 of Section 4.3). The rate of null packets SHOULD be the | ||||
| average rate of the session media stream. | ||||
| 6. SRTP TESLA Default parameters | 6. SRTP TESLA Default parameters | |||
| Key management procedures establish SRTP TESLA operating parameters, | Key management procedures establish SRTP TESLA operating parameters, | |||
| which are listed in section 4.3 of this document. The operating | which are listed in section 4.3 of this document. The operating | |||
| parameters appear in the SRTP cryptographic context and have the | parameters appear in the SRTP cryptographic context and have the | |||
| default values that are described in this section. In the future, | default values that are described in this section. In the future, | |||
| an Internet RFC MAY define alternative settings for SRTP TESLA that | an Internet RFC MAY define alternative settings for SRTP TESLA that | |||
| are different than those specified here. In particular, it should | are different than those specified here. In particular, it should | |||
| be noted that the settings defined in this memo can have a large | be noted that the settings defined in this memo can have a large | |||
| impact on bandwidth, as it adds 38 bytes to each packet (when the | impact on bandwidth, as it adds 38 bytes to each packet (when the | |||
| field length values are the default ones). For certain | field length values are the default ones). For certain | |||
| applications, this overhead may represent more than a 50% increase | applications, this overhead may represent more than a 50% increase | |||
| in packet size. Alternative settings might seek to reduce the | in packet size. Alternative settings might seek to reduce the | |||
| number and length of various TESLA fields and outputs. No such | number and length of various TESLA fields and outputs. No such | |||
| optimizations are considered in this memo. | optimizations are considered in this memo. | |||
| It is RECOMMENDED that the SRTP MAC be truncated to 32 bits since the | It is RECOMMENDED that the SRTP MAC be truncated to 32 bits since the | |||
| SRTP MAC provides only group authentication and serves only as | SRTP MAC provides only group authentication and serves only as | |||
| protection against external DoS. | protection against external DoS. | |||
| 6.1 Transform-independent Parameters | ||||
| The value of the flag indicating the use of TESLA in SRTP is by | ||||
| default zero (TESLA not used). | ||||
| 6.2 Transform-dependent Parameters for TESLA MAC | ||||
| The default values for the security parameters are listed in the | The default values for the security parameters are listed in the | |||
| following. "OWF" denotes a one-way function. | following. "OWF" denotes a one-way function. | |||
| Parameter Mandatory-to-support Default | Parameter Mandatory-to-support Default | |||
| --------- -------------------- ------- | --------- -------------------- ------- | |||
| TESLA KEYCHAIN OWF (F(x)) HMAC-SHA1 HMAC-SHA1 | TESLA KEYCHAIN OWF (F(x)) HMAC-SHA1 HMAC-SHA1 | |||
| OUTPUT LENGTH 160 160 | BIT-OUTPUT LENGTH n_p 160 160 | |||
| TESLA MAC KEY OWF (F'(F(x))) HMAC-SHA1 HMAC-SHA1 | TESLA MAC KEY OWF (F'(F(x))) HMAC-SHA1 HMAC-SHA1 | |||
| OUTPUT LENGTH n_f 160 160 | BIT-OUTPUT LENGTH n_f 160 160 | |||
| TESLA MAC HMAC-SHA1 HMAC-SHA1 | TESLA MAC HMAC-SHA1 HMAC-SHA1 | |||
| (TRUNCATED) OUTPUT LENGTH n_m 80 80 | (TRUNCATED) BIT-OUTPUT LENGTH n_m 80 80 | |||
| As shown above, TESLA implementations MUST support HMAC-SHA1 for the | As shown above, TESLA implementations MUST support HMAC-SHA1 | |||
| TESLA MAC, the MAC key generator, and the TESLA keychain generator | [RFC2104] for the TESLA MAC, the MAC key generator, and the TESLA | |||
| one-way function. The TESLA keychain generator is recursively | keychain generator one-way function. The TESLA keychain generator is | |||
| defined as follows [TESLA]. | recursively defined as follows [RFC4082]. | |||
| K_i=HMAC_SHA1(K_{i+1},0), i=0..N-1 | K_i=HMAC_SHA1(K_{i+1},0), i=0..N-1 | |||
| where N-1=n_c from the cryptographic context. | where N-1=n_c from the cryptographic context. | |||
| The TESLA MAC key generator is defined as follows [TESLA]. | The TESLA MAC key generator is defined as follows [RFC4082]. | |||
| K'_i=HMAC_SHA1(K_i,1) | K'_i=HMAC_SHA1(K_i,1) | |||
| The TESLA MAC uses a truncated output of ten bytes [RFC2104] and is | The TESLA MAC uses a truncated output of ten bytes [RFC2104] and is | |||
| defined as follows. | defined as follows. | |||
| HMAC_SHA1(K'_i, M') | HMAC_SHA1(K'_i, M') | |||
| where M' is as specified in Section 4.6. | where M' is as specified in Section 4.6. | |||
| 7. Security Considerations | 7. Security Considerations | |||
| Denial of Service (DoS) attacks on delayed authentication are | Denial of Service (DoS) attacks on delayed authentication are | |||
| discussed in [PCST]. TESLA requires receiver buffering before | discussed in [PCST]. TESLA requires receiver buffering before | |||
| authentication, therefore the receiver can suffer a denial of | authentication, therefore the receiver can suffer a denial of | |||
| service attack due to a flood of bogus packets. To address this | service attack due to a flood of bogus packets. To address this | |||
| problem, the external SRTP MAC, based on the group key, MAY be used | problem, the external SRTP MAC, based on the group key, MAY be used | |||
| in addition to the TESLA MAC. The short size of the SRTP MAC | in addition to the TESLA MAC. The short size of the SRTP MAC | |||
| (default 32 bits) is here motivated by the fact that that MAC serves | (default 32 bits) is motivated by the fact that that MAC is purely | |||
| purely for DoS prevention from attackers external to the group. | for DoS prevention from attackers external to the group. The shorter | |||
| [TESLA] describes other mechanisms that can be used to prevent DoS, | output tag means that an attacker has a better chance of getting a | |||
| in place of the external group-key MAC. If used, they need to be | forged packet accepted, which is about 2^31 attempts on average. As | |||
| added as processing steps (following the guidelines of [TESLA]). | a first line of defense against a denial of service attack, a short | |||
| tag is probably adequate; a victim will likely have ample evidence | ||||
| that it is under attack before accepting a forged packet, which will | ||||
| subsequently fail the TESLA check. [RFC4082] describes other | ||||
| mechanisms that can be used to prevent DoS, in place of the external | ||||
| group-key MAC. If used, they need to be added as processing steps | ||||
| (following the guidelines of [RFC4082]). | ||||
| The use of TESLA in SRTP defined in this specification is subject to | The use of TESLA in SRTP defined in this specification is subject to | |||
| the security considerations discussed in the SRTP specification | the security considerations discussed in the SRTP specification | |||
| [RFC3711] and in the TESLA specification [TESLA]. In particular, the | [RFC3711] and in the TESLA specification [RFC4082]. In particular, | |||
| TESLA security is dependent on the computation of the "safety | the TESLA security is dependent on the computation of the "safety | |||
| condition" as defined in Section 3.5 of [TESLA]. | condition" as defined in Section 3.5 of [RFC4082]. | |||
| SRTP TESLA depends on the effective security of the systems that | SRTP TESLA depends on the effective security of the systems that | |||
| perform bootstrapping (time synchronization) and key management. | perform bootstrapping (time synchronization) and key management. | |||
| These systems are external to SRTP and are not considered in this | These systems are external to SRTP and are not considered in this | |||
| specification. | specification. | |||
| The length of the TESLA MAC is by default 80 bits. RFC 2104 requires | The length of the TESLA MAC is by default 80 bits. RFC 2104 requires | |||
| the MAC length to be at least 80 bits and at least half the output | the MAC length to be at least 80 bits and at least half the output | |||
| size of the underlying hash function. The SHA-1 output size is 160 | size of the underlying hash function. The SHA-1 output size is 160 | |||
| bits, so both of these requirements are met with the 80 bit MAC | bits, so both of these requirements are met with the 80 bit MAC | |||
| specified in this document. Note that IPsec implementations tend to | specified in this document. Note that IPsec implementations tend to | |||
| use 96 bits for their MAC values to align the header with a 64 bit | use 96 bits for their MAC values to align the header with a 64 bit | |||
| boundary. Both MAC sizes are well beyond the reach of current | boundary. Both MAC sizes are well beyond the reach of current | |||
| cryptanalytic techniques. | cryptanalytic techniques. | |||
| 8. IANA Considerations | 8. IANA Considerations | |||
| No IANA registration is required. | No IANA registration is required. | |||
| Note that it is the task of each particular key management protocol | ||||
| to register the cryptographic transforms (here, TESLA, as value in | ||||
| the identifier for the message authentication algorithm in the SRTP | ||||
| crypto context) and related parameters. | ||||
| 9. Acknowledgements | 9. Acknowledgements | |||
| The authors would like to thanks Ran Canetti, Karl Norrman, Mats | The authors would like to thanks Ran Canetti, Karl Norrman, Mats | |||
| N„slund, Fredrik Lindholm, David McGrew, and Bob Briscoe for their | Naslund, Fredrik Lindholm, David McGrew, and Bob Briscoe for their | |||
| valuable help. | valuable help. | |||
| 10. Author's Addresses | 10. Author's Addresses | |||
| Questions and comments should be directed to the authors and | Questions and comments should be directed to the authors and | |||
| msec@ietf.org: | msec@ietf.org: | |||
| Mark Baugher | Mark Baugher | |||
| Cisco Systems, Inc. | Cisco Systems, Inc. | |||
| 5510 SW Orchid Street Phone: +1 408-853-4418 | 5510 SW Orchid Street Phone: +1 408-853-4418 | |||
| skipping to change at page 16, line 39 ¶ | skipping to change at page 17, line 24 ¶ | |||
| Elisabetta Carrara | Elisabetta Carrara | |||
| Ericsson | Ericsson | |||
| SE-16480 Stockholm Phone: +46 8 50877040 | SE-16480 Stockholm Phone: +46 8 50877040 | |||
| Sweden EMail: elisabetta.carrara@ericsson.com | Sweden EMail: elisabetta.carrara@ericsson.com | |||
| 11. References | 11. References | |||
| Normative | Normative | |||
| [PCST] Perrig, A., Canetti, R., Song, D., Tygar, D., "Efficient and | ||||
| Secure Source Authentication for Multicast", in Proc. of Network and | ||||
| Distributed System Security Symposium NDSS 2001, pp. 35-46, 2001. | ||||
| [RFC1305] Mills D., Network Time Protocol (Version 3) Specification, | [RFC1305] Mills D., Network Time Protocol (Version 3) Specification, | |||
| Implementation and Analysis, RFC 1305, March, 1992. | Implementation and Analysis, Internet Engineering Task Force, RFC | |||
| 1305, March, 1992. | ||||
| [RFC2104] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for | ||||
| Message Authentication," Internet Engineering Task Force, RFC 2104, | ||||
| February, 1997. | ||||
| [RFC2119] Bradner, Keywords to Use in RFCs to Indicate Requirement | ||||
| Levels, Internet Engineering Task Force, RFC 2119, March 1997. | ||||
| [RFC3711] Baugher, McGrew, Naslund, Carrara, Norrman, "The Secure | [RFC3711] Baugher, McGrew, Naslund, Carrara, Norrman, "The Secure | |||
| Real-time Transport Protocol", RFC 3711, March 2004. | Real-time Transport Protocol", Internet Engineering Task Force, RFC | |||
| 3711, March 2004. | ||||
| [TESLA] Perrig, Song, Canetti, Tygar, Briscoe, "TESLA: Multicast | [RFC4082] Perrig, Song, Canetti, Tygar, Briscoe, "TESLA: Multicast | |||
| Source Authentication Transform Introduction", RFC 4082, June 2005. | Source Authentication Transform Introduction", Internet Engineering | |||
| Task Force, RFC 4082, June 2005. | ||||
| Informative | Informative | |||
| [gkmarch] Baugher, Canetti, Dondeti, Lindholm, "MSEC Group Key | [PCST] Perrig, A., Canetti, R., Song, D., Tygar, D., "Efficient and | |||
| Management Architecture", May 2005, work in progress. | Secure Source Authentication for Multicast", in Proc. of Network and | |||
| Distributed System Security Symposium NDSS 2001, pp. 35-46, 2001. | ||||
| [GDOI] Baugher, Weis, Hardjono, Harney, "The Group Domain of | [RFC3547] Baugher, Weis, Hardjono, Harney, "The Group Domain of | |||
| Interpretation", RFC 3547, July 2003. | Interpretation", Internet Engineering Task Force, RFC 3547, July | |||
| 2003. | ||||
| [RFC3830] Arkko et al., "MIKEY: Multimedia Internet KEYing", | [RFC3830] Arkko et al., "MIKEY: Multimedia Internet KEYing", RFC | |||
| December 2003, RFC 3830, August 2004. | 3830, Internet Engineering Task Force, August 2004. | |||
| [RFC4046] Baugher, Canetti, Dondeti, Lindholm, "MSEC Group Key | ||||
| Management Architecture", Internet Engineering Task Force, April | ||||
| 2005. | ||||
| Copyright Notice | Copyright Notice | |||
| Copyright (C) The Internet Society (2005). This document is subject | Copyright (C) The Internet Society (2005). This document is subject | |||
| to the rights, licenses and restrictions contained in BCP 78, and | to the rights, licenses and restrictions contained in BCP 78, and | |||
| except as set forth therein, the authors retain all their rights. | except as set forth therein, the authors retain all their rights. | |||
| Disclaimer of Validity | Disclaimer of Validity | |||
| This document and the information contained herein are provided on | This document and the information contained herein are provided on | |||
| an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE | an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE | |||
| REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE | REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE | |||
| INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR | INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR | |||
| IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF | IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF | |||
| THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | |||
| WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |||
| This draft expires in March 2006. | This draft expires in April 2006. | |||
| End of changes. 74 change blocks. | ||||
| 175 lines changed or deleted | 213 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||