idnits 2.17.1 draft-noisternig-ipdvb-ulesec-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1778. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1755. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1762. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1768. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 14 instances of too long lines in the document, the longest one being 15 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 14, 2008) is 5765 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '31' on line 415 == Missing Reference: 'Rijndael' is mentioned on line 1394, but not defined == Missing Reference: 'ULEsec-Req' is mentioned on line 1153, but not defined == Missing Reference: 'ULEsec-CPI' is mentioned on line 1350, but not defined == Missing Reference: 'RIPEMD-160' is mentioned on line 1374, but not defined == Missing Reference: 'MD5-Attack' is mentioned on line 1379, but not defined == Missing Reference: 'Order-AE' is mentioned on line 1452, but not defined == Unused Reference: 'RFC4535' is defined on line 1588, but no explicit reference was found in the text == Unused Reference: 'RFC3547' is defined on line 1592, but no explicit reference was found in the text == Unused Reference: 'RFC3830' is defined on line 1595, but no explicit reference was found in the text == Unused Reference: 'GKDP' is defined on line 1599, but no explicit reference was found in the text == Unused Reference: 'FMKE' is defined on line 1603, but no explicit reference was found in the text == Unused Reference: 'DSS' is defined on line 1676, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'MPEG2' -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' -- Possible downref: Non-RFC (?) normative reference: ref. 'Modes' -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 3547 (Obsoleted by RFC 6407) Summary: 2 errors (**), 0 flaws (~~), 15 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ipdvb Working Group Michael Noisternig 2 Bernhard Collini-Nocker 3 Internet Draft University of Salzburg 4 July 14, 2008 5 Expires: January 2009 7 A lightweight security extension for the 8 Unidirectional Lightweight Encapsulation (ULE) protocol 9 draft-noisternig-ipdvb-ulesec-01 11 Status of this Document 13 By submitting this Internet-Draft, each author represents that 14 any applicable patent or other IPR claims of which he or she is 15 aware have been or will be disclosed, and any of which he or she 16 becomes aware will be disclosed, in accordance with Section 6 of 17 BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on January 14, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 The Unidirectional Lightweight Encapsulation (ULE) protocol is an 44 efficient and extensible transport mechanism for IP over MPEG-2 45 networks. Such networks are often operated on broadcast wireless 46 channels, and are thus specifically vulnerable to attacks. Passive 47 attacks, such as eaves-dropping, are simple to perform and emphasize 48 the importance of security support within ULE. 50 This document defines a mandatory security extension for the ULE 51 protocol that is designed with the aim of being conservative in 52 bandwidth consumption and lightweight in the sense that it allows for 53 implementation in low-cost, resource-scarce (mobile) receiver 54 devices. The extension may be easily adapted to the Generic Stream 55 Encapsulation (GSE) protocol, which uses the same extension header 56 mechanism. The document describes the format of the security 57 extension header, specifies default security algorithms to be used 58 with this extension, and gives detailed processing descriptions for 59 devices implementing the security extension. 61 Conventions used in this document 63 The following DVB specific terms are taken from [RFC4326] and 64 recapitulated here for easy lookup: 66 DVB: Digital Video Broadcast. A framework and set of associated 67 standards published by the European Telecommunications Standards 68 Institute (ETSI) for the transmission of video, audio, and data using 69 the ISO MPEG-2 standard [MPEG2]. 71 MPEG-2: A set of standards specified by the Motion Picture Experts 72 Group (MPEG) and standardized by the International Standards 73 Organization (ISO/IEC 13818-1) [MPEG2] and ITU-T [H222]. 75 NPA: Network Point of Attachment. In this document, refers to a 48- 76 bit destination address (resembling an IEEE MAC address) within the 77 MPEG-2 transmission network that is used to identify individual 78 receivers or groups of receivers. 80 PDU: Protocol Data Unit. Examples of a PDU include Ethernet frames, 81 IPv4 or IPv6 datagrams, and other network packets. 83 PID: Packet Identifier [MPEG2]. A 13-bit field carried in the header 84 of TS cells. This is used to identify the TS Logical Channel to 85 which a TS cell belongs [MPEG2]. 87 SNDU: SubNetwork Data Unit. An encapsulated PDU sent as an MPEG-2 88 payload unit. 90 TS: Transport Stream [MPEG2]. A method of transmission at the MPEG-2 91 level using TS cells; it represents layer 2 of the ISO/OSI reference 92 model. 94 TS Logical Channel: Transport Stream Logical Channel. In this 95 document, this term identifies a channel at the MPEG-2 level [MPEG2]. 96 All packets sent over a TS Logical Channel carry the same PID value. 98 ULE: Unidirectional Lightweight Encapsulation [RFC4326]. A protocol 99 that encapsulates PDUs into SNDUs that are sent in a series of TS 100 cells using a single TS Logical Channel. 102 Terms and abbreviations from cryptography are explained when they 103 first appear within this document. 105 All numbers encoded in protocols are to be interpreted in network 106 byte order. 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL", when 110 appearing within this document, are to be interpreted as described in 111 [RFC2119]. 113 Table of Contents 115 1. Introduction ................................................. 4 116 2. Format of the ULE Security Extension Header .................. 6 117 2.1. Type field .............................................. 7 118 2.2. VPN-ID field ............................................ 7 119 2.3. Key (K) bit ............................................. 7 120 2.4. Sequence Number.......................................... 8 121 2.5. Encrypted Destination Address field ..................... 8 122 2.6. PDU Type field .......................................... 8 123 2.7. MAC field ............................................... 8 124 3. Security Algorithms .......................................... 8 125 3.1. Key Derivation .......................................... 9 126 3.2. Encryption .............................................. 9 127 3.3. Identity Protection .................................... 10 128 3.4. Authentication and Integrity Protection ................ 11 129 3.5. Replay Protection ...................................... 12 130 4. Security Extension Header Processing ........................ 12 131 4.1. Preliminaries .......................................... 12 132 4.1.1. Security Policy Database (SPD) .................... 13 133 4.1.2. Security Association Database (SAD) ............... 14 134 4.2. Sender Processing ...................................... 16 135 4.2.1. General Activity Diagram .......................... 16 136 4.2.2. Detailed Processing Description ................... 16 137 4.3. Receiver Processing .................................... 20 138 4.3.1. General Activity Diagram .......................... 20 139 4.3.2. Detailed Processing Description ................... 21 140 5. Key Management Considerations ............................... 23 141 5.1. Unidirectional Key Management .......................... 24 142 5.2. Bidirectional Key Management ........................... 25 143 6. Security Considerations ..................................... 25 144 7. IANA Considerations ......................................... 26 145 8. Conclusions ................................................. 26 146 9. Acknowledgments ............................................. 27 147 APPENDIX A: Rationale for the Extension Header Format .......... 28 148 A.1. (16-bit) optional VPN-ID vs. (32-bit) SPI .............. 28 149 A.2. VPN-ID + K-Bit vs. SPI ................................. 28 150 A.3. 31-bit/63-bit Sequence Number .......................... 29 151 A.4. MAC field .............................................. 29 152 APPENDIX B: Rationale for the Default Security Algorithms ...... 30 153 B.1. Encryption ............................................. 30 154 B.2. Identity protection .................................... 31 155 B.3. Authentication ......................................... 32 156 B.4. Source Authentication .................................. 33 157 B.5. Combined Authentication and Encryption ................. 34 158 B.6. Replay Protection ...................................... 35 159 10. References ................................................. 36 160 10.1. Normative References .................................. 36 161 10.2. Informative References ................................ 36 162 Author's Addresses ............................................. 41 163 Intellectual Property Statement ................................ 41 164 Disclaimer of Validity ......................................... 42 166 1. Introduction 168 The Unidirectional Lightweight Encapsulation (ULE) protocol [RFC4326] 169 has been designed as an efficient and extensible encapsulation 170 mechanism of IPv4/IPv6 and other network layer packets over the ISO 171 MPEG-2 Transport Stream (TS) [MPEG2]. It has a simple base format, 172 but as such does not offer any security services; however, MPEG-2 173 networks are often operated on wireless channels, such as satellite 174 DVB-S [DVB-S] and terrestrial wireless DVB-T [DVB-T] and DVB-H [DVB- 175 H] links, and are thus specifically vulnerable to attacks [ULEsec- 176 Req]. Passive attacks, such as eavesdropping packet data or 177 monitoring the identities (addresses) of the communicating parties, 178 are easy to perform, and remain undetected. Low cost receiver devices 179 and the large coverage area of satellite senders add to the 180 likelihood of such events. Effective means to secure the ULE link are 181 therefore important. 183 One solution is to rely on end-to-end security, and on one hand, 184 reliable security can only be end-to-end. On the other hand, end-to- 185 end security may not be applicable: this is because both sides of a 186 communication must provide support for the same security mechanism, 187 which will not be realizable under many conditions where the two 188 sides are not under central control (e.g., when browsing a public web 189 site). One important security requirement cannot be attained by end- 190 to-end security at all: the protection of the end-point addresses 191 ("identities") of the communicating parties against eavesdropping 192 (subsequently referred to as "identity protection"). 194 By securing the ULE link only, solutions can be provided for these 195 problems. In addition, this has the benefit that the ULE broadcast 196 link becomes transparent for the user in the sense that he or she can 197 rely on security assumptions as of wired links [RFC3819]. The IPsec 198 [RFC4301] security protocols could be used in tunnel mode to create 199 such a secure link, but this will result in significant bandwidth 200 overhead on satellite links (due to the IP-in-IP encapsulation). 201 Current IPsec specifications only define pairwise tunnels between two 202 devices, thus this option is not applicable for multicast and 203 broadcast transmissions. Last but not least, the rather high 204 complexity of IPsec implementations might make its realization within 205 low-cost receiver devices difficult. 207 Implementing security at the ULE link layer addresses above problems. 208 A more detailed rationale for ULE link layer security and a 209 comparison of security at the various layers can be found in [ULEsec- 210 Req]. It also lists the security requirements for the ULE link. 212 This document defines a mandatory security extension for the ULE 213 protocol that is designed with the aim of being conservative in 214 bandwidth consumption and lightweight in the sense that it allows for 215 implementation in low-cost, resource-scarce (mobile) receiver 216 devices. The extension may be easily adapted to the second-generation 217 Generic Stream Encapsulation (GSE) protocol [GSE], which shares the 218 extension header mechanism with ULE. The format of the security 219 extension header is described in section 2, and default security 220 algorithms to be used with this extension are specified in section 3. 221 These algorithms should address the most important security 222 requirements for the ULE link: data confidentiality, identity 223 protection, integrity protection, data authentication, and replay 224 protection. Section 4 then gives detailed processing descriptions for 225 devices implementing the security extension. While not defining any 226 protocol for automated key management, some guidelines are given in 227 section 5. After security and IANA considerations in sections 6 and 228 7, conclusions are presented in section 8. At the end of this 229 document, two appendices support the reader with more insight and 230 rationale on the decisions taken within this specification. 232 2. Format of the ULE Security Extension Header 234 This section defines the format of the ULE security extension header, 235 ULEsec header in short. This format can be regarded as a framework 236 for a set of security transforms. While section 3 defines default 237 algorithms to be used within that framework, other security 238 transforms, especially making use of other cryptographic primitives, 239 modes, and key lengths, may be devised later and defined within 240 separate documents. 242 Figure 1 below shows an example format of a ULE SubNetwork Data Unit 243 (SNDU) containing a ULEsec header. In this example, the ULEsec 244 extension header directly follows the base header, and it is 245 RECOMMENDED that encapsulation devices always be configured that way. 246 Users not following this recommendation must clearly understand the 247 implications: first, extension headers preceding the ULEsec header 248 cannot be protected under the data confidentiality service; second, 249 when processing the security extension header, a receiver device may 250 decide to discard the SNDU, a point at which preceding headers will 251 already have been evaluated. 253 0 16 31 254 +-+-----------------------------+------------------------------+ 255 |D| Length | Type=ULEsec/ULEsec_ID | 256 +-+-----------------------------+------------------------------+ 257 | Destination Address (D=0) | 258 | +------------------------------+ 259 | | VPN-ID (Type=ULEsec_ID) | 260 +-+-----------------------------+------------------------------+ 261 |K| Sequence Number (31/63 bits) | 262 +-+-----------------------------+------------------------------+ 263 | Encrypted Destination Address (optional) | 264 | +------------------------------+ 265 | | (Encrypted) PDU Type | 266 +-------------------------------+------------------------------+ 267 | | 268 ~ (Encrypted) Payload Data ~ 269 | | 270 | | 271 +--------------------------------------------------------------+ 272 | | 273 ~ MAC (optional) ~ 274 | | 275 +--------------------------------------------------------------+ 276 | CRC-32 | 277 +--------------------------------------------------------------+ 278 Figure 1 Example ULE SNDU containing a security extension header 280 The following subsections describe the fields that are part of or 281 directly relevant to the ULEsec header. All encoded numbers are in 282 network byte order. 284 2.1. Type field 286 The 16-bit Type field of the ULE base header (or some other extension 287 header) indicates a security extension header following subsequently. 288 Two different type values are defined. The first one, denoted simply 289 ULEsec, SHOULD be used when receiver devices can uniquely identify 290 Security Associations (SAs) based on MPEG-2 TS Program Identifiers 291 (PIDs) and SNDU destination addresses solely. The second type, 292 denoted ULEsec_ID, MUST be used, when PIDs and destination addresses 293 alone are not sufficient to look up SAs. In this case, the VPN-ID 294 field will be present, which is described next. 296 2.2. VPN-ID field 298 This 16-bit field is present when the ULEsec_ID Type is chosen. It 299 can be viewed as a Security Parameter Index (SPI) as of IPsec 300 implementations [RFC4301], but more adequately simply represents a 301 Virtual Private Network (VPN) identifier. See above to decide when to 302 use this field. 304 2.3. Key (K) bit 306 This mandatory bit provides for an easy way of detecting a key 307 update. Whenever ULE sender (i.e., ULE encapsulator) devices switch 308 to new keys, they flip this bit. This enables receivers to find out 309 which of two concurrently defined set of keys (the current/old ones, 310 or the new ones) are to be used for decoding. 312 New keys will be issued within key management messages by a Group 313 Controller and Key Server (GCKS), which may or may not physically 314 reside with a ULE sender. After each key update, devices MUST wait 315 for a policy-defined amount of time before they permit switching to 316 new keys again. This is necessary to avoid collisions between 317 different keys on SNDUs sent with the same K bit. This can happen 318 either because a receiver still accepts old keys (see section 4.3), 319 or because a device has missed all key management messages during two 320 periods of key updates. To avoid the latter, a GCKS may periodically 321 send out key management messages with the key currently in use (see 322 section 5.1). 324 2.4. Sequence Number 326 The mandatory Sequence Number field serves two purposes. First, it is 327 part of the nonce required for the default encryption algorithm. 328 Second, it is used for the replay protection service. 330 The default size of the Sequence Number field is 31 bits. This MAY be 331 extended to 63 bits when configured as such by a Security Policy (SP) 332 or via negotiation within a key management protocol. The larger size 333 MUST be used when no automated key management is available. 335 2.5. Encrypted Destination Address field 337 This field is only present if the identity protection service is used 338 (determined by the SPs selected). In that case, SNDUs do not contain 339 a 48-bit NPA destination address in the ULE base header (i.e., they 340 have the D bit set to 1), but the address will appear in the security 341 extension header's Encrypted Destination Address field instead, where 342 it will be encrypted subsequently (along with the payload data). 344 2.6. PDU Type field 346 This mandatory 16-bit field designates the type of the PDU or the 347 next extension header in the header chain. 349 2.7. MAC field 351 The security extension header has an optional (SP-configured) trailer 352 that follows the PDU data and contains the Message Authentication 353 Code (MAC) of the SNDU. This MAC SHOULD have a default length of 12 354 octets. 356 3. Security Algorithms 358 This section specifies a set of mandatory default security algorithms 359 to be used in conjunction with the ULEsec header. These algorithms 360 are lightweight in the sense that the only cryptographic primitive 361 required is the Advanced Encryption Standard (AES) [AES] with a key 362 size of 128 bits, denoted AES-128 in short, and only its encryption 363 part is used. 365 Implementation of default security algorithms is REQUIRED. 367 Within the following subsections, AES_mk(value) means AES-128 368 encryption of the 128-bit value using the master key mk, value[x..y] 369 means taking value's bits x to y, || denotes concatenation, and x^y 370 means that bit x is to be repeated y times. All encoded numbers are 371 in network byte order. 373 3.1. Key Derivation 375 In order to minimize transmission overhead within a key management 376 protocol and to ease the setup of manual keys, separate encryption 377 and authentication keys are derived from a single master key. The 378 derived keys are computed as follows: 380 encr_key = AES_mk ( Salt || 0^64 ) 382 auth_key = AES_mk ( Salt || 0^63 || 1 ) 384 The Salt is a 64-bit value that MUST be an unpredictable value for 385 adversaries. It will be transmitted along with the master key either 386 explicitly or implicitly (e.g., derived from nonces used within the 387 key management protocol). Including the Salt in the key derivation 388 process preserves full security of the master key in case of 389 compromise of any derived key against an adversary using pre- 390 computation techniques. 392 3.2. Encryption 394 Using encryption spoils an adversary's attempt of finding out 395 information transmitted via eavesdropping. By encoding all data 396 following a security extension header's Sequence Number field up to 397 but not including the MAC field, confidentiality is provided for 398 SNDUs' payload data as well as any extension headers succeeding a 399 security header. 401 Encryption is performed by employing AES-128 in the Counter (CTR) 402 mode of operation, which is specified in [Modes], and using the 403 encr_key defined in subsection 3.1. 405 The CTR mode requires a Nonce as part of its input. It is a 128-bit 406 value and derived per packet from a 64-bit random value (Salt) that 407 is distributed along with the master key, the 13-bit Program 408 Identifier (PID) the underlying MPEG-2 TS cell originated from, and 409 the ULEsec header's K bit and Sequence Number as follows: 411 Nonce = Salt || K || Sequence Number || 0^3 || PID || 0^16. 413 When 63-bit sequence numbers are used, the Nonce is computed as such: 415 Nonce = Salt[63..32] || Salt[31] XOR K || Salt[30..0] XOR Sequence 416 Number[62..32] || Sequence Number[31..0] || 0^3 || PID || 0^16. 418 The Salt is the same as that of subsection 3.1, which primarily means 419 that it be an unpredictable value for adversaries. Again, its purpose 420 is to thwart pre-computation attacks. 422 Special care has to be taken when PID re-mapping can occur (typically 423 within a multiplexer on a DVB network boundary [MPEG2]), as a 424 receiver will not be able to decrypt the data successfully when using 425 a PID value different from the sender. For one-sender scenarios where 426 the sender also acts as the key server, a simple solution to inform 427 receivers about such PID re-mapping may be to include the originating 428 PID within the key management messages. 430 3.3. Identity Protection 432 For additional protection against traffic flow analysis, the ULE link 433 layer addresses may be hidden using the identity protection service. 434 For this, a sender omits the 48-bit NPA destination address from the 435 ULE base header, sets the D bit, and places the address into the 436 extension header's Encrypted Destination Address field instead, where 437 it will be encrypted subsequently (along with the payload data). A 438 receiver will detect an SNDU destined to it simply by probing (i.e., 439 trial-decryption). 441 Identity protection has the following properties: 443 o There is no need to store or transmit any additional information 444 (besides that the identity protection service is requested). 445 Particularly, there is no need for a central server to manage or 446 distribute addresses used specifically for this service. 448 o An adversary not in the know of a matching encryption key will not 449 be able to read an SNDU's NPA destination address. 451 o A legitimate receiver will correctly decode the address with very 452 high probability. In detail, the probability that an SNDU is 453 mistakenly accepted is given approximately by k*10^-14.4, where k 454 is the receiver's number of keys that do not match. Note that this 455 is close to typical packet-error ratios on the ULE link for small 456 k, which is between 10^-15.5 and 10^-16.8 on a quasi-error-free 457 channel. 459 o For even lower false-acceptance rates, the authentication 460 mechanism may be used. A MAC of size t bits will decrease the 461 probability of erroneously accepting a SNDU with a wrong key by 462 the factor 2^-t. 464 Two typical use cases for this service are sketched. In the first 465 one, each receiver device has one distinct key to protect its unicast 466 data. In this case, a receiver will not miss any data destined to it, 467 and will mistakenly accept other SNDUs with negligible probability 468 (k=1). 470 In the second case, all sender and receiver devices on a PID use a 471 single shared key to protect their data, forming a VPN. Within such 472 VPN, all devices can correctly decode all addresses (k=0). 474 Note that while identity protection could be used for unicast as well 475 as multicast settings, it is sensible only for unicast communication, 476 and as such - and in order to keep the number of mismatching keys low 477 - should not be used for multicast scenarios. 479 Identity Protection MUST NOT be used without the data confidentiality 480 service (section 3.2). 482 3.4. Authentication and Integrity Protection 484 As a mechanism against active attacks, SNDUs may carry a Message 485 Authentication Code (MAC). A MAC provides integrity protection and 486 source authentication for unicast connections as well as other 487 single-sender settings. When there is more than one sender, such as 488 in peer-to-peer settings, or when there is a possibility that a 489 receiver in the know of the shared key might act as a sender, this 490 mechanism gets reduced to group authentication. This is regarded 491 sufficient, however, as attacks are primarily expected from outside 492 (i.e., from adversaries not in the know of the right keys) [ULEsec- 493 Req]. 495 This construction of the MAC is based on the Cipher Block Chaining 496 (CBC) mode of operation [Modes], and is commonly known as a (plain) 497 CBC-MAC, which is computed as follows: 499 1. The SNDU, excluding the CRC and the MAC field, is first internally 500 right-padded with zeros to an integral multiple of the cipher's 501 block length (128 bits for AES), if necessary. 503 2. This padded data is then internally encrypted with AES-128 in CBC 504 mode using the auth_key defined in subsection 3.1, and an 505 Initialization Vector (IV) of 0. 507 3. The final output block of the encryption step resembles the full- 508 length MAC whose least-significant bits are then truncated to 509 receive the MAC of desired length. 511 The CBC-MAC based on AES is fully secure up to 98 bits, or about 12 512 octets, when used with the default sequence number space of 2^31. 12 513 octets is the "standard" authentication length for the IPsec 514 protocols, and should be used as a default for ULEsec, too. 516 When extended (63-bit) sequence numbers are used, a block cipher with 517 larger block size should be chosen. It is advised to take the 518 Rijndael algorithm [Rijndael] with a block size of 256 bits as a 519 superset of AES. 521 3.5. Replay Protection 523 Upon switching to a new set of keys, senders and receivers will set 524 its sequence numbers to be sent or accepted next for a Security 525 Association (SA) to the value 0. A sender will increment a sender- 526 side sequence number by 1 after each SNDU transmitted, independently 527 of whether replay protection is used or not. A receiver, using replay 528 protection, will only accept SNDUs with a receiver-side sequence 529 number higher than the last one accepted. Detailed processing 530 descriptions regarding this service are given in section 4. 532 Note that replay protection using sequence numbers only works for the 533 one-sender scenario due to the difficulty of synchronizing replay 534 state among multiple senders. As such, this service MUST NOT be used 535 when there is multiple legitimate senders or legitimate receivers 536 acting as senders for a SA. Also, it SHOULD NOT be used when keys are 537 set up manually, as a sender would have to remember its sequence 538 number state across reboots. 540 4. Security Extension Header Processing 542 4.1. Preliminaries 544 Within the next subsections, the following terms are used to simplify 545 wording: 547 o Basic (Policy) Selector: a pair of destination NPA address and PID 548 value. 550 o Receiver-Side (Policy) Selector: a Basic (Policy) Selector with 551 the optional VPN-ID value. 553 o Sender-Side (Policy) Selector: a Basic (Policy) Selector, 554 optionally extended by higher-layer selector data, such as IP 555 addresses, TCP ports, etc. 557 The term (Policy) Selector is used interchangeably for those above. 559 4.1.1. Security Policy Database (SPD) 561 Senders and receivers define policies describing the security 562 services required or permitted for outgoing and incoming data. The 563 collection of such Security Policies (SPs) is referred to as the 564 Security Policy Database (SPD). 566 For both outgoing and incoming data, a SPD contains an ordered list 567 of SPs. Each SP MUST contain the following information: 569 o A set of Sender-Side or Receiver-Side Policy Selectors (for 570 outgoing or incoming data respectively), defining the 571 applicability of this SP. To simplify parsing, this set MUST be 572 encoded as a single Selector together with a Selector Mask. 574 o Information about the SA(s) to be instantiated by this SP. This 575 contains: 577 o A set of subsets of above Policy Selectors, downgraded to Basic 578 Policy Selectors (i.e., only the address and PID are taken). 579 Each subset together with the optional VPN-ID value constitutes 580 a SA Selector, which is used for looking up or creating a 581 Security Association (SA) within the Security Association 582 Database (SAD) (see next section 4.1.2). To simplify parsing, a 583 single Basic Selector Mask MUST be stored, denoted SA Selector 584 Mask, from which the set of subsets is derived. 586 o An optional VPN-ID value, part of the SA Selector. If defined, 587 a sender MUST use this value within the VPN-ID field of the 588 ULEsec_ID extension header type. 590 o Optional Group Controller and Key Server (GCKS) data, specified 591 by an optional destination address and a (possibly empty set 592 of) PID(s). A device MAY use the PID(s) as a first check for 593 legitimacy of key management messages from a certain source. 594 When a destination address is defined, it MUST be used to 595 contact the GCKS for membership request on receiving a 596 protected SNDU for which this SP matches, and when the SP does 597 not contain default key data in its first set of Security 598 Parameters. 600 o An ordered list of Security Parameter sets used for 601 instantiating a SA, sorted according to preference. A Security 602 Parameter set MUST allow having no security services selected 603 at all, which MUST be interpreted as sending or receiving data 604 without protection (i.e., SNDUs without a security extension 605 header). A sender MUST default to the first entry in the list, 606 unless a key management protocol permits negotiation (e.g., for 607 unicast, bidirectional settings) and a receiver contacts the 608 GCKS to request another set of Security Parameters from the 609 list. Each set of Security Parameters MUST contain information 610 about: 612 o The cryptographic algorithms used. 614 o The cryptographic parameters required by these algorithms 615 (e.g., the MAC length). 617 o The length of the sequence number field. 619 o Optional key data for manual keying: a master key, and an 620 optional Salt. 622 SPs may be manually set up by the owner of the sender or receiver 623 equipment, or dynamically distributed via a GCKS (using a key 624 management protocol). While the resulting SPD may become complex by 625 containing separate SPs for each pair of PID and NPA address data may 626 be sent to or received from, in general it is expected to contain 627 just a few entries. 629 This document does not define how to store, manage, and look up SPs 630 within the SPD, as this is regarded implementation specific details. 632 4.1.2. Security Association Database (SAD) 634 A Security Association (SA) is an instantiation of a SP. It describes 635 the current state of a secure connection between two or more devices. 636 All devices sharing a SA are part of the same VPN. The set of SAs of 637 a device is aggregated in the Security Association Database (SAD). 639 A SA MUST contain the following information: 641 o The SA Selector derived from the instantiating SP. 643 o Any GCKS data defined by the SP and the GCKS. 645 o Static security parameters defined by the SP (cryptographic 646 algorithms, MAC length, Sequence Number length, etc.). 648 o Current and prospective dynamic security parameters (keys, Salt, 649 etc.), defined by the SP or the GCKS. 651 o The current sender-side K bit and sequence number for transmitting 652 data. 654 o The current receiver-side K bit for receiving data, and the 655 current receiver-side sequence number for receiving data with 656 replay protection. 658 o A flag defining whether prospective security parameters have been 659 received through a GCKS. 661 As with the SPD, this document does not define how to store, manage, 662 and look up SAs within the SAD. 664 4.2. Sender Processing 666 4.2.1. General Activity Diagram 668 +-----------------+ 669 | receive PDU | +-----------------+ 670 +---->|from upper layers|<-------------------| discard PDU | 671 | +-----------------+ +-----------------+ 672 | v ^ 673 | +-----------------+ not found? +-----------------+ 674 | | get SP |------------------->| log event |<-+ 675 | +-----------------+ +-----------------+ | 676 | v ^ failure? | 677 | +-----------------+ not found? +-----------------+ | 678 | +--| get SA |------------------->| create SA | | 679 | | +-----------------+ +-----------------+ | 680 | |w/o | | success? | 681 | |sec.ext. | +----------------+ | 682 | | v | | 683 | | +-----------------+ fresh key | +-----------------+ | 684 | | | check keys |------------------->| switch keys | | 685 | | +-----------------+ available? | +-----------------+ | 686 | | | | | | 687 | | v | +------------+ | 688 | | +-----------------+ seq.nr. | | | 689 | | | check seq.nr. |-----------------------------+-----------+ 690 | | +-----------------+ overflow? | | v 691 | | | expected | | +-----------------+ 692 | | +---------------------------->|get key from GCKS| 693 | | | seq.nr. overflow? | | +-----------------+ 694 | | v | | v failure? 695 | | +-----------------+ | | +-----------------+ 696 | +->| construct SNDU |<-----------+ | | log event | 697 | | & transmit |<---------------+ +-----------------+ 698 | +-----------------+ 699 | v 700 | +-----------------+ 701 | | update SA | 702 | +-----------------+ 703 | | 704 +--------------+ 706 4.2.2. Detailed Processing Description 708 The following list describes the processing steps for a ULE 709 encapsulator implementing the ULE security extension (ULEsec sender 710 in short): 712 1. Get SP: After receiving a PDU from upper layers for transmission 713 over the ULE link, a ULEsec sender MUST consult its SPD by 714 scanning the ordered list of outgoing SPs until it finds a 715 matching policy. That is, it looks for a SP for which 717 (SP's Sender-Side Selector AND SP's Selector Mask) 718 == (SNDU's Sender-Side Selector AND SP's Selector Mask) 720 is true. If no such policy can be found, the data MUST be 721 discarded, and this event SHOULD be logged as an invalid 722 transmission attempt. 724 2. Get SA: With a SP chosen, a SA Selector is constructed as a 725 triple: 727 SA Selector := (SNDU's Basic Selector AND SP's SA Selector Mask, 728 SP's SA Selector Mask, SP's VPN-ID value) 730 The VPN-ID value, if not defined by the SP, must be set to a 731 reserved "null" value (i.e., a fixed value not within the 16-bit 732 number range of the extension header's VPN-ID field). 734 The SA Selector is then used to look up a SA within the SAD. If no 735 SA is found, it must be set up as follows: If the SP's first 736 Security Parameter set either contains default key data (master 737 key, optional Salt, etc.) or defines data to be sent without 738 protection, the SA is immediately created and initialized 739 according to these settings. Otherwise, if the SP defines a GCKS 740 destination address, the server MUST be contacted for obtaining 741 key material. During that attempt the sender SHOULD postpone or 742 discard transmission of the data. Any case of failure MUST result 743 in the data being discarded, and this SHOULD be logged accordingly 744 (e.g., as a user authentication failure in case of membership 745 denial by the GCKS). 747 3. Check keys: Whenever a SA is provided with fresh key material, a 748 sender MUST switch to the new set of keys after a policy-defined 749 length or point of time, and prior to a sequence number overflow 750 (see next step). This is done by flipping the SA's sender-side K 751 bit and resetting the sender-side sequence number to 0, while 752 selecting the fresh key material as the new current one for 753 sending. Note that a SA that is also used for receiving SNDUs may 754 still require the older set of keys as a receiver-side K bit will 755 be flipped at a later (policy-defined) point of time. This is to 756 compensate differences in key update times of multiple senders, 757 which means there will be a period during which some devices will 758 already send with new keys while others will still use the old 759 ones. 761 4. Check sequence number: An implementation MUST NOT allow a SA's 762 sender-side sequence number to overflow. For a SA defining a GCKS 763 destination address, an implementation MUST contact the server for 764 obtaining fresh key material in anticipation of this event. When 765 keys are set up manually, the user SHOULD be warned about an 766 expected overflow. Should eventual transmission of an SNDU ever 767 result in the sequence number to overflow, the data MUST be 768 discarded instead, and this event SHOULD be logged as a sequence 769 number overflow event. 771 5. Construct SNDU: For a SA that allows passing data unprotected, the 772 SNDU is constructed as usual. Otherwise, it is built as follows: 774 a. First, the ULE base header and any extension headers preceding 775 the security extension header are written. If the SA requests 776 identity protection, the destination NPA address MUST be 777 omitted from the base header (with the D bit set to 1). If a 778 VPN-ID value is defined within the SA, the last extension 779 header's (or base header's) Type field MUST contain the value 780 for a ULEsec_ID extension header; otherwise, it contains the 781 ULEsec extension header value. 783 b. For the ULEsec_ID extension header, the 16-bit VPN-ID field is 784 written. 786 c. Next, the SA's sender-side K bit and sequence number are 787 filled into the extension header's mandatory K Bit and 788 Sequence Number fields. The length of the Sequence Number 789 field is defined by the SA. 791 d. For the identity protection service, the destination NPA is 792 encoded as defined by the SA, which means it will be encrypted 793 along with any subsequent extension headers and the payload 794 data for the default identity protection algorithm. 796 e. Subsequently, the mandatory (Encrypted) Type field, any other 797 extension headers, and the PDU are encoded as defined by the 798 encryption algorithm selected. 800 f. For authentication, a MAC of length as defined by the SA is 801 appended. The MAC is computed over all the data encoded so 802 far, which means, from the start of the SNDU to the end of the 803 payload data. 805 g. Finally, the CRC is calculated and appended, and the SNDU 806 further processed according to [RFC4326]. 808 6. Update SA: After processing a protected SNDU is completed, a 809 sender MUST increment the SA's sender-side sequence number by 1. 811 4.3. Receiver Processing 813 4.3.1. General Activity Diagram 815 +-----------------+ 816 | receive SNDU | +-----------------+ 817 +---->| from MPEG layer |<-------------------| discard SNDU | 818 | +-----------------+ +-----------------+ 819 | v ^ 820 | +-----------------+ decoding | 821 | |decode headers up| error? +-----------------+ 822 | |to security ext. |------------------->| log event |<-+ 823 | +-----------------+ +-----------------+ | 824 | | ^ ^ ^ ^ | 825 | | +-----------------------------+ | | | | 826 | v | not found/not permitted? | | | | 827 | +-----------------+ | | | | 828 | +--| get SP |<----------------------+ | | +-----+ | 829 | | +-----------------+ no match? | | | | | 830 | |permit. |permitted (SNDU w/o address)| | | | | 831 | |w/o |w/ | | | | | 832 | |sec. |sec. +-----------------------------|--+ | | | 833 | |ext. |ext. | id.prot. mismatch? | | | | 834 | | v | (SNDU w/ address) | |failure?| | 835 | | +-----------------+ +-----------------+ | | 836 | | | get SA(s) |---------------->| create SA | | | 837 | | +-----------------+ not found? +-----------------+ | | 838 | | | | success? | | 839 | | | +--------------------------------+ | | 840 | | v v | | 841 | | +-----------------+ not found? +-----------------+ | | 842 | | | select key |----------->|get key from GCKS|-------+ | 843 | | +-----------------+ +-----------------+ failure? | 844 | | | |success? | 845 | | | +---------------------------+ | 846 | | v v | 847 | | +-----------------+ | 848 | +->| decode SNDU | decoding/authentication/replay error? | 849 | | & pass to L3 |-----------------------------------------+ 850 | +-----------------+ 851 | v 852 | +-----------------+ 853 | | update SA | 854 | +-----------------+ 855 | | 856 +--------------+ 858 4.3.2. Detailed Processing Description 860 A receiver implementing the ULE security extension (ULEsec receiver 861 in short) must follow below procedure upon reception of a ULE SNDU: 863 1. Decode SNDU (1): The SNDU is checked for a correct CRC as 864 described in [RFC4326], after which the base header and the 865 extension headers up to either a security extension header or the 866 PDU are evaluated. From the base header, a Basic Policy Selector 867 is constructed. This one is extended to a Receiver-Side Policy 868 Selector by adding the VPN-ID field of a ULEsec_ID Type security 869 extension header, when encountered. 871 2. Get SP: After the SNDU passed the first filtering and evaluation 872 step, the SPD's ordered list of incoming policies is scanned for a 873 matching policy. 875 a. D=0: With the SNDU's D bit cleared, the following check must 876 be true for selecting a SP: 878 (SP's Receiver-Side Selector AND SP's Selector Mask) 879 == (SNDU's Receiver-Side Selector AND SP's Selector Mask). 881 If no matching policy can be found, the data MUST be discarded 882 immediately, and this event SHOULD be logged as reception of 883 an invalid SNDU. 885 b. D=1: When the D bit is set, above check is done as well, 886 except that the destination NPA address values are ignored. 888 If no matching policy can be found, the data MUST be discarded 889 immediately, and this event MAY be logged as reception of an 890 invalid SNDU. 892 If the SNDU is received without a security extension header but 893 the SP does not permit unprotected data to pass, the SNDU MUST be 894 discarded immediately, and this event SHOULD be logged as 895 reception of an invalid SNDU. Likewise, if there is a security 896 extension header but the policy allows only for unprotected data, 897 the SNDU MUST be discarded, and this event SHOULD be logged. 899 When permitted, an SNDU without a security extension header is 900 decoded as usually. For a protected SNDU, processing continues 901 with step 3. 903 3. Get SA: With a first match on a SP, a SA Selector is constructed 904 to find a SA within the SAD. 906 a. D=0: With a destination address present, the following SA 907 Selector is used to directly look up a SA within the SAD: 909 SA Selector := (SNDU's Basic Selector data AND SP's SA 910 Selector Mask, SP's SA Selector Mask, SNDU's VPN-ID value) 912 The VPN-ID value must be set to a reserved value if not 913 defined by a ULEsec_ID header. 915 If no SA is found, it must be tried to set it up as described 916 in step 2 of section 4.2, Sender Processing. If creation of a 917 SA fails, the SNDU MUST be discarded, and this SHOULD be 918 logged accordingly. 920 b. D=1: With the D bit set, a set of SAs is looked up by omitting 921 the destination address: 923 SA Selector := (SNDU's PID AND SP's SA Selector Mask's PID, 924 SP's SA Selector Mask, SNDU's VPN-ID value) 926 From the retrieved set, every SA not defining identity 927 protection is ignored. Assuming the remaining set is not 928 empty, the K Bit and Encrypted Destination Address field are 929 read ahead from the security extension header. The current 930 key, as defined by the K Bit (see next step), is then taken 931 from the first SA in the set to trial-decrypt the Encryption 932 Destination Address field (i.e., it is decrypted to a 933 temporary buffer). The decrypted address MUST be checked to 934 match both the SP selected as well as belong to the current 935 SA. Then, it MUST be compared with all destination NPA 936 addresses a receiver accepts to look for a match. If either a 937 SA does not contain the current key, or there is no match for 938 an address, the SA is removed from the retrieved set, and 939 probing is done with the next one. 941 If no SA matches, but the SP defines default key data as well 942 as the identity protection service for the first set of 943 Security Parameters, the encryption key derived from the 944 default key data is used for probing with the SNDU as 945 described in above paragraph. (Because of this, receiver-side 946 SPs containing default key material SHOULD already provide 947 derived keys for efficiency reasons.) If this test succeeds, a 948 SA is constructed using the SP's first Security Parameter set; 949 if SA creation fails (e.g., due to out-of-memory conditions), 950 the SNDU MUST be discarded, and this SHOULD be logged 951 accordingly. 953 When no matching SA can be found, the SP is assumed to be 954 selected mistakenly, and processing MUST continue at step 2.b 955 with the next SP in the list of incoming SPs. 957 4. Select key: Once a matching SA is found, proper keys must be 958 looked up. For this, the SNDU's K bit is compared with the SA's 959 receiver-side one. If they are equal, the SA's current keys are 960 taken for decoding. Otherwise, the SA's prospective keys must be 961 selected. If these are not defined, the SNDU MUST be discarded and 962 this event SHOULD be logged as reception of an invalid SNDU. A 963 receiver SA, when provided with prospective keys, must switch to 964 these after a policy-defined point or amount of time by flipping 965 its receiver-side K bit and replacing the current keys with the 966 fresh ones. 968 5. Decode SNDU (2): 970 a. Authenticate SNDU: For verifying authenticity and integrity, a 971 MAC is computed as defined for the sender side, and then 972 compared with the value of the SNDU's MAC field for equality. 973 If the two values differ, the SNDU MUST be discarded, and this 974 SHOULD be logged as a data authentication failure. 976 b. Replay Protection: To detect replays, the SNDU's Sequence 977 Number MUST be greater than or equal to the SA's receiver-side 978 sequence number; if this is not the case, the SNDU MUST be 979 discarded, and this event SHOULD be logged as a replay. 981 c. Decryption: If the data confidentiality service is used, all 982 data starting from the security extension header's Encrypted 983 Type field up to the end of the PDU data are decrypted. After 984 that, processing continues as normally (i.e., any other 985 extension headers are evaluated, and the PDU is finally passed 986 to upper protocol layers). 988 6. Update SA: Now that the SNDU has been accepted, a SA using replay 989 protection must be updated accordingly: If the K bits of step 4 990 were differing, keys are switched immediately as described in that 991 step; then, the SA's receiver-side sequence number is set to the 992 SNDU's Sequence Number value, and incremented by 1. 994 5. Key Management Considerations 996 Manual key setup is simple but practical only for small and 997 relatively static secure groups. When number of receivers gets high, 998 or users need to be added or excluded more frequently, automated key 999 management becomes necessary. A Group Controller and Key Server 1000 (GCKS) uses a key management protocol to automatically distribute key 1001 material to legitimate devices in the event of new membership, 1002 revoking of users, or key update (either periodically for increased 1003 security, or after a security breach). The definition or selection of 1004 any particular key management protocol is out of scope for this 1005 document as doing so has no influence on extension header format, 1006 security algorithms, or extension header processing. However, some 1007 important considerations are discussed next, and one must distinguish 1008 between the two different scenarios of unidirectional and 1009 bidirectional communication. 1011 5.1. Unidirectional Key Management 1013 In unidirectional settings, security parameters can merely be decided 1014 by the sender. Having no way for negotiation, this allows for a 1015 simpler protocol design in this regard. However, other issues arise. 1016 Senders must assure reliable delivery of information to all 1017 receivers. Doing so might require sending the same data multiple 1018 times. Receivers must be able to jump into a session at any time and 1019 without substantial delays, either when they are turned on, or after 1020 loss of synchronization. Replay attacks must be considered. They are 1021 best countered with timestamps; however, this requires sender and 1022 receivers to have synchronized clocks. 1024 The design of a unidirectional key management protocol should allow 1025 installing, updating, and revoking a number of different keys within 1026 receiver devices, with new keys encrypted with any other one. 1027 Different keys can correspond to individual, group, or global keys. 1028 This flexibility will allow the use of various broadcast encryption 1029 algorithms (such as the subset difference scheme [Subset]). 1031 It is further suggested that a unidirectional key management protocol 1032 uses the same format for re-key messages as for the initial key 1033 distribution. In other words, re-keys should provide all the 1034 information necessary to allow receivers to jump into the middle of a 1035 session, which shall result in great aid for connectivity. 1037 Existing mechanisms should be evaluated, such as [DVB-CA] and [ATSC- 1038 CA]. For example, [DVB-CA] defines unidirectional key management in 1039 the form of the entitlement checking and entitlement management 1040 messages. This offers a simple mechanism for securely establishing, 1041 updating, and revoking keys. A 3-level key hierarchy is used to 1042 provide for a better level of safety in case of key compromise. 1043 However, the single first-level key remains unchanged, constituting a 1044 weakness in this system; this could be mitigated in a protocol for 1045 the ULE security extension by either configuring receiver devices 1046 with unique sets of first level keys, thereby allowing true broadcast 1047 encryption algorithms such as [Subset], or by permitting operators of 1048 a VPN to update first level keys externally of the ULE network 1049 (either manually or automatically). 1051 5.2. Bidirectional Key Management 1053 The availability of a back channel allows devices not only to 1054 actively request group membership, revocation, and retransmission of 1055 keys after loss of synchronization. Negotiation of cryptographic 1056 algorithms and keys becomes possible, as well as enhanced security 1057 features such as perfect forward secrecy, mutual authentication, and 1058 identity protection when receivers are identified by other means than 1059 their NPA address. 1061 In contrast to unidirectional key management, numerous bidirectional 1062 protocols have been developed for various layers of the ISO/OSI 1063 reference model. Prominent examples include [DVB-RCS] (link layer), 1064 IKEv2/IPsec [RFC4306] (network layer), TLS [RFC4346] (transport 1065 layer) and SSH [RFC4253] (application layer). Naturally, they differ 1066 highly in purpose, functionality, and complexity. While existing link 1067 layer technology such as those within [DVB-RCS] is probably most 1068 directly usable for ULE, requirements for bidirectional key 1069 management must be clearly determined. 1071 Traditional key management protocols, including the ones cited above, 1072 are designed for unicast communication, only. ULE key management must 1073 support VPN-like settings with a potentially large number of 1074 receivers. One focus of the IETF MSEC working group is on developing 1075 and standardizing scalable solutions for key management within large 1076 groups, and several different protocols have been proposed [RFC4535, 1077 RFC3547, GKDP, FMKE, RFC3830]). Clearly, these must be considered 1078 when defining ULE key management. 1080 6. Security Considerations 1082 The security of cryptography-based systems depends in one part on the 1083 strength of the cryptographic algorithms chosen and the strength of 1084 the keys used with those algorithms. The algorithms identified in 1085 this document are not known to be broken at the current time, and 1086 research so far leads to believe that the combination of algorithms 1087 and key lengths specified within this document will likely remain 1088 secure into the foreseeable future. Considerations that relate to 1089 this aspect, including the correct use of algorithms, are addressed 1090 in their respective sections or the appendices of this document. 1092 There is a caveat regarding the security extension's Sequence Number 1093 field when a SA secures communication for a single receiver device 1094 (i.e. for unicast communication) and the identity protection service 1095 is used. A passive attacker may link SNDUs with increasing sequence 1096 number to the same SA, thereby increasing its chance of identifying a 1097 receiver and the amount and type of data transmitted to it. Future 1098 research will investigate on possible solutions for this problem. 1100 The security also depends on the engineering and administration of 1101 the protocols used by the system to ensure that there are no non- 1102 cryptographic ways to bypass security. When selecting a key 1103 management protocol, its security will be a pre-requirement for 1104 overall system security. 1106 ULE link layer security may not be treated as a replacement for end- 1107 to-end security. If reliable security is required, one MUST use end- 1108 to-end security protocols. However, ULE link layer security can 1109 complement end-to-end security as laid out in the conclusions in 1110 section 8. 1112 7. IANA Considerations 1114 This document requires two 16-bit Type codes to be registered by the 1115 IANA, namely one for the ULEsec security extension, and one for the 1116 ULEsec_ID extension header type. It is suggested that the two Type 1117 codes are allocated in a way that they differ only in their least- 1118 significant bit. This allows use of this bit as a flag for 1119 determining the presence of the VPN-ID field. (However, this is 1120 merely an optimization and no requirement.) 1122 8. Conclusions 1124 The solution presented within this document addresses many of the 1125 security requirements for the ULE protocol laid out in the separate 1126 security requirements document. Passive attacks, constituting the 1127 most important threats in the ULE network, are effectively defeated 1128 using the data confidentiality and identity protection service. To 1129 mitigate active attacks, MACs may be used to assure a receiver of the 1130 authenticity and integrity of the data received. While not providing 1131 source authentication for VPN-like settings with multiple senders, 1132 they still render outsider attacks futile. Sequence numbers within 1133 each SNDU allow for simple detection of replayed data on unicast 1134 connections, without any additional bandwidth overhead. 1136 The format of the security extension header generates minimal 1137 bandwidth overhead, is extensible, and acts as a framework for a set 1138 of security transforms that may be changed and updated independently 1139 of each other. Default algorithms are defined to be lightweight and 1140 allow implementation in low-cost devices. 1142 A key management protocol may be added later and independently of 1143 this specification. This will allow more flexibility and security in 1144 setting up secure connections and VPNs. Existing protocols such as 1145 those following the guidelines of [RFC4046] might be used. However, 1146 this will need careful assessment regarding the applicability for the 1147 ULE link. 1149 Note that the presented ULE security extension secures the ULE 1150 broadcast link, only, and as such may not be treated as a replacement 1151 for end-to-end security. In fact, ULE link layer security is an 1152 additional security mechanism that complements end-to-end security 1153 [ULEsec-Req]. Where end-to-end security is used, it can provide 1154 identity protection over the ULE link in addition. When the ULE link 1155 is used to directly connect two secure sites, ULEsec can be the sole 1156 provider of security. In the cases where end-to-end security is not 1157 applicable, the ULE security extension can be viewed as protecting 1158 the weakest link, and a user can rely on security assumptions as of 1159 wired links. 1161 9. Acknowledgments 1163 The document was prepared using 2-Word-v2.0.template.dot. 1165 APPENDIX A: Rationale for the Extension Header Format 1167 A.1. (16-bit) optional VPN-ID vs. (32-bit) SPI 1169 In order to identify which secure connection (represented by a SA) a 1170 secured packet belongs to, it is generally marked with a connection 1171 identifier. For the IPsec [RFC4301] security protocols, this 1172 identifier is known as the Security Parameter Index (SPI). It is 1173 selected by the receiver, only, in order to avoid collisions between 1174 different connections. This works because IPsec is designed for 1175 secure unicast communication only. For multicast settings, a manually 1176 assigned SPI together with manual keying can be used. The same 1177 principle of deriving a secure connection identifier can be used with 1178 the ULE security extension, too. Instead of an SPI, the ULE security 1179 extension provides the VPN-ID field, when the ULEsec_ID security 1180 extension header type is used. 1182 One difference between IPsec and ULEsec is that IPsec is an end-to- 1183 end security protocol. This means that on a single ULE link a ULE 1184 decapsulator will potentially accept data from many different (IPsec) 1185 end-to-end connections. In contrast, at the ULE link layer users are 1186 expected to establish just a single or otherwise so few secure L2 1187 connections that in many cases receivers can even identify 1188 connections based on ULE destination NPA addresses and MPEG-2 TS PID 1189 values alone. Therefore, a size of 16 bits has been chosen for the 1190 ULEsec VPN-ID field as opposed to 32 bits as used for the SPI of the 1191 IPsec security protocols. In addition, it is provided for a way to 1192 omit the VPN-ID field altogether (by selecting the ULEsec extension 1193 header type). 1195 A.2. VPN-ID + K-Bit vs. SPI 1197 The way re-keying works in the IPsec protocols is by creating a new 1198 SA (i.e., secure connection) for the new keys. The new SA will have a 1199 different SPI value than the old one, selected by the receiver again. 1200 This model does not work for ULE, however. A receiver that failed to 1201 receive key update messages will have no way of determining that the 1202 new data with a different secure connection identifier is to be 1203 received by him. This is not only an issue for multicast settings 1204 where scalability is a concern, but also for unidirectional links 1205 where there is no way for feedback. Instead, ULEsec uses the K Bit to 1206 signal when re-keying occurred, and keeps the VPN-ID value constant. 1207 Now a receiver will always know which data to accept, and it would 1208 have to lose key management messages during two periods of key 1209 updates for this model to fail. 1211 A.3. 31-bit/63-bit Sequence Number 1213 A 31-bit sequence number has been chosen as a default as it does not 1214 add too much overhead and is reasonably big for automated re-keying 1215 to happen infrequently. For example, when SNDUs are continuously sent 1216 on a link with an effective bit rate as high as 68 Mbit/s [DVB-S], 1217 protected under the same key, and contain only TCP/IP acknowledgments 1218 so the SNDU size is just 60 octets (20 octets ULE+ULEsec header, 20 1219 octets IP header, and 20 octets TCP header), then a key can still be 1220 used for more than four hours before the 31-bit sequence number space 1221 will be exhausted. 1223 For high-speed links, and when manual keying is used, the larger 63- 1224 bit sequence numbers are to be used. This pairs well with a key size 1225 of 128 bits for the encryption algorithm, where after 2^63 uses 1226 security will be about halved and new keys should be set up by then. 1228 While the Sequence Number field could be optional, too, its placement 1229 has been made mandatory in order to not unnecessarily complicate 1230 things, and since it is required virtually always, anyway. It could 1231 be replaced with a timestamp, though, but this is not defined within 1232 this specification. 1234 A.4. MAC field 1236 The MAC field is not a direct part of the security extension header, 1237 but defined as a trailer. This allows the MAC to be computed in an 1238 online way. For example, a sender can compute the MAC of an SNDU 1239 while it is already transmitting it, and when it has sent the last 1240 bit of the payload it can simply attach the MAC. 1242 For a similar reason, the CRC, which can be viewed as part of the ULE 1243 base header, is at the end of the SNDU. 1245 APPENDIX B: Rationale for the Default Security Algorithms 1247 B.1. Encryption 1249 The first question on the data confidentiality service is whether to 1250 use a block cipher or a stream cipher algorithm. Stream ciphers offer 1251 the benefit of allowing for very simple and fast implementations. One 1252 particular stream cipher is the Arcfour (or RC4) algorithm [Arcfour], 1253 and it can be regarded the de-facto standard among software based 1254 implementations. However, several weaknesses have been found so far, 1255 and while there are ways to circumvent some of them, they do not make 1256 Arcfour a favorable choice [Arcfour-Fix]. Unfortunately, other stream 1257 ciphers available are either not sufficiently analyzed, or are based 1258 on linear feedback shift registers, making them suitable for cheap 1259 hardware implementations but vulnerable to algebraic attacks. 1261 Among block ciphers, things are looking much better. The Advanced 1262 Encryption Standard (AES) [AES] has been quickly embraced as a 1263 secure, fast, and open encryption algorithm since its election within 1264 a competition held by the American NIST in the year 2000 to replace 1265 the aging DES. Despite algebraic structures found, AES is still 1266 considered secure. 1268 A mode of operation is required for a block cipher to allow it to be 1269 repeatedly used securely under the same key. NIST has standardized 1270 several such modes [Modes]. One particular mode is the Cipher Block 1271 Chaining (CBC) mode. It is well-understood and has good security 1272 properties. However, it operates on full blocks only, and data must 1273 therefore be padded to multiples of block lengths in general. In 1274 addition, the CBC mode requires an explicit (pseudo-)random 1275 Initialization Vector (IV) of the size of a cipher block for each 1276 packet. This is clearly wasteful for the ULE scenario, where this 1277 means additional average overhead of 24 octets per SNDU when used 1278 with AES. 1280 The Counter (CTR) mode in contrast effectively turns the block cipher 1281 into a stream cipher, so there is no need for padding. IVs for this 1282 mode come as nonces, so a simple counter may be used. A counter can 1283 not only be encoded in less space than the size of a cipher block, it 1284 may also serve as a mechanism for replay protection - in which case 1285 no space will be wasted at all. Some of the other advantages of the 1286 CTR mode are that only the encryption part of the block cipher 1287 algorithm is needed, and both encryption and decryption can be 1288 parallelized. 1290 Strong care must be taken for the nonces to never be used twice under 1291 the same key, or all security will be lost. Therefore, within the 1292 construction of the nonce, not only the SNDU's sequence number but 1293 also the MPEG-2 TS cell's PID value is included. This gives a 1294 guarantee for nonces to be unique when the encryption key is shared 1295 across more than one PID. One case is that of multiple senders (i.e. 1296 ULE encapsulators) using the same keys. It is assumed that there will 1297 be at most one sender per PID for technical reasons (this does not 1298 preclude the possibility of adversaries sending on the same PID). A 1299 similar scenario is where a sender spreads data over multiple PIDs. 1301 The last question is what key size to use. AES may be used with key 1302 sizes of 128, 192, or 256 bits. Of these, 128 bits are regarded to be 1303 sufficiently secure even for the foreseeable future, and any bigger 1304 size would merely result in increased key management overhead and 1305 computational effort [Standards]. 1307 B.2. Identity protection 1309 The presented solution for identity protection is simple, yet very 1310 effective. First, a receiver needs to probe only a very low number of 1311 keys with an SNDU. This is because in the vast majority of cases 1312 there is only a single or otherwise very few different keys a 1313 receiver associates with a PID or pair of PID and VPN-ID field: For 1314 an incoming ULEsec packet with a VPN-ID field present, the pair of 1315 PID and VPN-ID will most commonly denote a single VPN with a single 1316 shared key. Without a VPN-ID, the PID may represent a VPN with a 1317 single key, or the PID will probably contain several or many unicast 1318 or multicast connections of which the receiver accepts only a few, 1319 namely for its own unicast and a few (if any) multicast addresses. 1320 Each of these connections could utilize identity protection; however, 1321 this is sensible only for unicast communication. Assuming a device is 1322 not assigned more than one unicast address, there is only a single 1323 key left that has to be probed with. 1325 Second, by encrypting the address an adversary not in the know of a 1326 matching decryption key will not be able to read the packet's 1327 destination address. A legitimate receiver, in contrast, will 1328 correctly decode the address with very high probability. In detail, 1329 the chance that an SNDU is mistakenly accepted (assuming the 1330 encryption algorithm behaves as a pseudo-random function under 1331 different keys) is given approximately by k*10^-14.4, where k is the 1332 receiver's number of keys that do not match. This is close to typical 1333 packet-error ratios on the ULE link for small k, as this example 1334 shows: assuming a quasi-error free channel with a bit-error ratio of 1335 10^-10 [DVB-S], and - for simplicity assumed - a probability of 2^-32 1336 for the CRC-32 failing, the chance of receiving an erroneous SNDU 1337 undetected by the CRC ranges between approximately 10^-15.5 for a 1338 typical 1500-octet (file download) payload and 10^-16.8 for small 1339 (VoIP) data of 60 octets. 1341 Note that this method of identity protection requires to be combined 1342 with the data confidentiality service for two reasons: First, it 1343 protects only L2 addresses. Second, there is a requirement for the 1344 data a receiver assumes to be an encrypted destination address to be 1345 pseudo-random, or at least non-repeating (with high probability), 1346 otherwise above equations will not hold. 1348 This solution for identity protection is also superior to other 1349 suggestions such as the use of temporary destination addresses 1350 [ULEsec-CPI] for a variety of reasons. First, when creating temporary 1351 addresses it must somehow be assured that these do not and will not 1352 collide with real-world addresses, i.e. addresses that are in use or 1353 might be used in the future. Second, in order to assure these 1354 addresses to be unique a server must keep every one of them in a 1355 database. This is clearly a disadvantage for simple settings such as 1356 VPNs where otherwise only a single key must be stored. Third, such 1357 addresses compromise additional information that must be distributed 1358 in a reliable way, which is difficult for unidirectional links and 1359 does not scale well for multicast scenarios. Last but not least, even 1360 though these addresses are temporary, they remain constant for a 1361 period of time and as such may pose just another chance for an 1362 adversary to link packets with a receiver. 1364 B.3. Authentication 1366 By adding redundancy in the form of keyed cryptographic checksums to 1367 packets, legitimate receivers can verify both authenticity and 1368 integrity of the data. A Message Authentication Code (MAC) is the 1369 result of a symmetric checksum function, so both senders and 1370 receivers use the same key for authenticating and verifying. 1372 MAC algorithms typically build upon cryptographic hash functions 1373 (message digests), such as MD5 [RFC1321], SHA-1 and the SHA-2 family 1374 [SHA], and RIPEMD-160 [RIPEMD-160]. The HMAC [RFC2104] is a popular 1375 construction to turn a hash function into a MAC function. The 1376 advantage of using hash functions is their simple implementability, 1377 resulting in certain speed advantages. Despite a number of surprising 1378 and unexpected collision attacks on hash functions published lately 1379 [MD5-Attack, SHA-1-Attack], the HMAC construction is secure as long 1380 as no second pre-image attacks become practical, and the hash 1381 function's output cannot be distinguished from random data by an 1382 adversary [Preimages, HMAC2, Standards]. 1384 MAC constructions may also use block ciphers as building blocks. The 1385 main advantage of this approach is that an already existing block 1386 cipher implementation can be re-used. This makes the CBC-MAC (and its 1387 variants) still a very popular solution. The security of a CBC-MAC is 1388 directly dependent on that of the block cipher. Because of the 1389 birthday phenomenon, the upper limit of security is also determined 1390 by the block length of the underlying encryption algorithm, which 1391 degrades quadratically over time [CBCMAC1, CBCMAC2]. Therefore, when 1392 the same key is used for a long time (e.g., with extended sequence 1393 numbers for ULEsec), a cipher with a higher block length should be 1394 chosen, such as [Rijndael] with a block length of 256 bits. 1396 A plain CBC-MAC is not a generally secure construction. In detail, it 1397 is only secure for fixed-size or prefix-free messages [CBCMAC1]. 1398 However, ULE SNDUs are automatically prefix-free because of the 1399 inclusion of the length field in the base header. 1401 There are some interesting newer constructions based on Carter-Wegman 1402 universal hashing, such as the UMAC [RFC4418] and the [Poly1305-AES], 1403 both defined for use with the AES encryption algorithm. While having 1404 excellent security properties, allowing for parallelization, and 1405 achieving high throughputs on modern desktop processors, they are not 1406 suitable for small hardware devices because of performing complex 1407 operations such as multiplications in large size Galois fields and 1408 requiring a large amount of memory. 1410 Two surprisingly simple and parallelizable designs are presented in 1411 [XOR-MAC] and [PMAC]. When a block cipher is plugged into the pseudo- 1412 random function required, the complexity is similar to that of the 1413 CBC-MAC. Security is not affected by the birthday phenomenon, 1414 however. As both algorithms are covered by patents, they are not 1415 selected as default authentication algorithms. 1417 B.4. Source Authentication 1419 MAC algorithms are symmetrical functions, so anyone in the know of 1420 the right key could have been the author of an authenticated message. 1421 Consequently, MACs cannot provide source authentication when there is 1422 more than one legitimate sender, or receivers are able to act as 1423 senders. In order to guarantee data coming from the source as 1424 corroborated, some asymmetry must be introduced, either by using 1425 functions that are hard to invert (digital signatures), or by 1426 disclosing verification key material only after it has been used for 1427 authentication (e.g., TESLA [RFC4082]). 1429 Source authentication does not come for free, however. Digital 1430 signature algorithms are very computationally demanding, as time 1431 needed for signing and verification is still counted in milliseconds 1432 even on modern hardware. Additionally, bandwidth consumption is high 1433 with typical key sizes of 1024 bits and signature sizes of 320 bits 1434 for a level of security comparable to that of a 80-bit symmetric key 1435 [Recommendations]. A number of different solutions have been 1436 developed over time to overcome these shortcomings, most prominently 1437 TESLA; however, all of them have one or another drawback such as 1438 increased latency at the sender or receiver side, lack of re- 1439 synchronization ability in case of packet loss, or even higher 1440 bandwidth cost. 1442 Source Authentication for ULEsec may be devised independently of this 1443 specification, but it likely makes more sense for control messages 1444 (e.g., key management messages). 1446 B.5. Combined Authentication and Encryption 1448 While there had always been a lack of consensus in cryptography and 1449 security communities about the "right" way of combining 1450 authentication with encryption, it had not been know until recently 1451 that the only generally secure way of generic composition is Encrypt- 1452 then-Authenticate (EtA) [Order-AE]. By following that finding within 1453 this specification, encryption and authentication algorithms can be 1454 changed and updated independently of each other without compromising 1455 overall security; for example, the default CBC-MAC for authentication 1456 could safely be replaced with a MAC using a cryptographic hash 1457 function, or with an algorithm providing source authentication for 1458 multi-sender scenarios. 1460 Another recent development in cryptography are so-called 1461 Authenticated Encryption (AE) and Authenticated Encryption with 1462 Associated Data (AEAD) schemes. These can be viewed as modes of 1463 operation that integrate both authentication and encryption 1464 functionality. Excitement for these schemes can primarily be 1465 contributed to the development of encryption modes that provide 1466 authentication essentially for free (i.e., with negligible 1467 computational overhead) [IAPM, XCBC, OCB]. Unfortunately, all these 1468 so-called 1-pass schemes have patents filed on them, which is an 1469 issue for an open standard. This circumstance initiated the 1470 development of second-generation unpatented 2-pass schemes, most 1471 notably CCM [CCM]. Even though these modes provide a secure two-in- 1472 one solution (one key for both encryption and authentication), they 1473 have lost their predecessors' main advantage: they are, as their name 1474 says, 2-pass. As a result, they do not offer any real benefits over 1475 the more versatile AtE generic composition approach. 1477 B.6. Replay Protection 1479 The key idea in providing replay protection is to guarantee each 1480 packet to be unique under the same key. This is generally achieved by 1481 adding a monotonically increasing counter or a timestamp to the 1482 packet header. The in-order delivery of data on the ULE link then 1483 allows for easy detection of replays on the receiver side. 1485 A counter is simple to use, requires minimal connection state on each 1486 side, and is fully reliable for unicast connections and other one- 1487 sender scenarios. It cannot be used when a key is shared among 1488 multiple senders due to the difficulty of synchronizing replay state. 1490 A timestamp uses synchronized clocks for the replay state. A small 1491 window of accepted timestamps is required to compensate timing 1492 discrepancies. This way, timestamps can be used with any number of 1493 senders. However, this also means that they are not completely 1494 reliable; consequently, their use is not defined within that 1495 specification. 1497 10. References 1499 10.1. Normative References 1501 [RFC4326] G. Fairhurst, B. Collini-Nocker, "Unidirectional 1502 Lightweight Encapsulation (ULE) for Transmission of IP 1503 Datagrams over an MPEG-2 Transport Stream (TS)", IETF RFC 1504 4326, December 2005. 1506 [MPEG2] "Information technology - generic coding of moving pictures 1507 and associated audio information systems, Part I", ISO 1508 13818-1, International Standards Organization (ISO), 2000. 1510 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1511 Requirement Levels", BCP 14, IETF RFC 2119, March 1997. 1513 [AES] "Advanced Encryption Standard (AES)", FIPS PUB 197, 1514 National Institute of Standards and Technology (NIST), Nov. 1515 2001. 1517 [Modes] M. Dworkin, "Recommendation for Block Cipher Modes of 1518 Operation - Methods and Techniques", SP 800-38A, National 1519 Institute of Standards and Technology (NIST), Dec. 2001. 1521 10.2. Informative References 1523 [H222] "Information technology, Generic coding of moving pictures 1524 and associated audio information Systems", H.222.0, 1525 International Telecommunication Union (ITU-T), 1995. 1527 [DVB-S] "Digital Video Broadcasting (DVB); Framing structure, 1528 channel coding and modulation for 11/12 GHz satellite 1529 systems", ETSI EN 300 421, Aug. 1997. 1531 [DVB-T] "Digital Video Broadcasting (DVB); Framing structure, 1532 channel coding and modulation for digital terrestrial 1533 television", ETSI EN 300 744, June 2006. 1535 [DVB-H] "Digital Video Broadcasting (DVB); Transmission system for 1536 handheld terminals (DVB-H)", ETSI EN 302 304, Nov. 2004. 1538 [ULEsec-Req]H. Cruickshank, P. Pillai, M. Noisternig, S. Iyengar, 1539 "Security requirements for the Unidirectional Lightweight 1540 Encapsulation (ULE) protocol", draft-ietf-ipdvb-sec-req-08 1541 (work in progress), July 2008. 1543 [GSE] "Generic Stream Encapsulation (GSE) Protocol", DVB BlueBook 1544 A116, May 2007. 1546 [RFC4301] S. Kent, K. Seo, "Security Architecture for the Internet 1547 Protocol", IETF RFC 4301, Dec. 2005. 1549 [RFC4346] T. Dierks, E. Rescorla, "The Transport Layer Security (TLS) 1550 Protocol Version 1.1", IETF RFC 4346, April 2006. 1552 [RFC4253] T. Ylonen, C. Lonvick, "The Secure Shell (SSH) Transport 1553 Layer Protocol", IETF RFC 4253, Jan. 2006. 1555 [RFC3819] P. Karn, C. Bormann, G. Fairhurst, D. Grossman, R. Ludwig, 1556 J. Mahdavi, G. Montenegro, J. Touch, L. Wood, "Advice for 1557 Internet Subnetwork Designers", IETF RFC 3819, July 2004. 1559 [Rijndael]J. Daemen, V. Rijmen, "The Design of Rijndael: AES - The 1560 Advanced Encryption Standard", Springer Verlag, March 2002, 1561 pp. 238. 1563 [Subset] D. Naor, M. Naor, J. Lotspiech, "Revocation and Tracing 1564 Schemes for Stateless Receivers", Advances in Cryptology - 1565 CRYPTO 2001, 21st Annual International Cryptology 1566 Conference, Proceedings, August 2001, pp. 41-62. 1568 [DVB-CA] "Digital Video Broadcasting (DVB); Support for Use of 1569 Scrambling and Conditional Access (CA) within Digital 1570 Broadcasting Systems", ETSI ETR 289, Jan. 1996. 1572 [ATSC-CA] "Conditional Access System for Terrestrial Broadcast, 1573 Revision A, with Amendment No. 1", Doc. A/70A, Advanced 1574 Television Systems Committee, July 2004 (Sept. 2006 for 1575 Amendment No. 1). 1577 [DVB-RCS] "Digital Video Broadcasting (DVB); Interaction Channel for 1578 Satellite Distribution Systems", ETSI EN 301 790, Sept. 1579 2005. 1581 [RFC4306] C. Kaufman, "Internet Key Exchange (IKEv2) Protocol", IETF 1582 RFC 4306, Dec. 2005. 1584 [RFC4046] M. Baugher, R. Canetti, L. Dondeti, F. Lindholm, "Multicast 1585 Security (MSEC) Group Key Management Architecture", IETF 1586 RFC 4046, April 2005. 1588 [RFC4535] H. Harney, U. Meth, A. Colegrove, G. Gross, "GSAKMP: Group 1589 Secure Association Key Management Protocol", IETF RFC 4535, 1590 June 2006. 1592 [RFC3547] M. Baugher, B. Weis, T. Hardjono, H. Harney, "The Group 1593 Domain of Interpretation", IETF RFC 3547, July 2003. 1595 [RFC3830] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman, 1596 "MIKEY: Multimedia Internet KEYing", IETF RFC 3830, August 1597 2004. 1599 [GKDP] L. Dondetti, J. Xiang, S. Rowles, "GKDP: Group Key 1600 Distribution Protocol", IETF draft-ietf-msec-gkdp-01 1601 (expired), March 2006. 1603 [FMKE] L. Duquerroy, S. Josset, "The Flat Multicast Key Exchange 1604 protocol", draft-duquer-fmke-01 (expired), Sept. 2004. 1606 [RFC4082] A. Perrig, D. Song, R. Canetti, J. Tygar, B. Briscoe, 1607 "Timed Efficient Stream Loss-Tolerant Authentication 1608 (TESLA): Multicast Source Authentication Transform 1609 Introduction", IETF RFC 4082, June 2005. 1611 [RFC4082] A. Perrig, D. Song, R. Canetti, J. D. Tygar, B. Briscoe, 1612 "Timed Efficient Stream Loss-Tolerant Authentication 1613 (TESLA): Multicast Source Authentication Transform 1614 Introduction", IETF RFC 4082, June 2005. 1616 [Arcfour] B. Schneier, "Applied Cryptography Second Edition: 1617 protocols algorithms and source in code in C", John Wiley 1618 and Sons, New York, 1996. 1620 [Arcfour-Fix] B. Harris, "Improved Arcfour Modes for the Secure 1621 Shell (SSH) Transport Layer Protocol", IETF RFC 4345, Jan. 1622 2006. 1624 [Standards] B. Burr, "NIST Cryptographic Standards Status Report", 1625 PowerPoint presentation, National Institute of Standards 1626 and Technology (NIST), April 2006. 1628 [ULEsec-CPI]H. Cruickshank, P. Pillai, S. Iyengar, "Security 1629 Extension for Unidirectional Lightweight Encapsulation 1630 Protocol", draft-cruickshank-ipdvb-sec-03 (work in 1631 progress), July 2007. 1633 [RFC1321] R. Rivest, "The MD5 Message-Digest Algorithm", IETF RFC 1634 1321, April 1992. 1636 [SHA] "The Secure Hash Standard", FIPS 180-2 (+ change notice to 1637 include SHA-224), National Institute of Standards and 1638 Technology (NIST), August 2002. 1640 [RIPEMD-160]H. Dobbertin, A. Bosselaers, B. Preneel, "RIPEMD-160: A 1641 Strengthened Version of RIPEMD", 1642 http://homes.esat.kuleuven.be/~bosselae/ripemd160.html, 1643 April 1996. 1645 [RFC2104] H. Krawczyk, M. Bellare, M. and R. Canetti, "HMAC: Keyed- 1646 Hashing for Message Authentication", IETF RFC 2104, Feb. 1647 1997. 1649 [CBCMAC1] M. Bellare, J. Kilian, P. Rogaway, "The security of the 1650 cipher block chaining message authentication code", Journal 1651 of Computer and System Sciences, Vol. 61, No. 3, Dec. 2000, 1652 pp. 362-399. 1654 [CBCMAC2] B. Preneel, P. C. van Oorschot, "MDx-MAC and building fast 1655 MACs from hash functions", Proc. Crypto '95: 15th Annual 1656 International Cryptology Conference, Santa Barbara, Aug. 1657 1995. 1659 [RFC4418] T. Krovetz, "UMAC: Message Authentication Code using 1660 Universal Hashing", IETF RFC 4418, March 2006. 1662 [Poly1305-AES] D. Bernstein, "The Poly1305-AES Message-Authentication 1663 Code", Proceedings of Fast Software Encryption, Lecture 1664 Notes in Computer Science, Springer-Verlag, 2005. 1666 [XOR-MAC] M. Bellare, R. Guerin, P. Rogaway, "XOR MACs: New methods 1667 for message authentication using finite pseudorandom 1668 functions", Advances in Cryptology - Crypto 95 Proceedings, 1669 Lecture Notes in Computer Science, Springer-Verlag, 1995. 1671 [PMAC] J. Black, P. Rogaway, "A Block-Cipher Mode of Operation for 1672 Parallelizable Message Authentication", Advances in 1673 Cryptology - EUROCRYPT '02, Lecture Notes in Computer 1674 Science, Springer-Verlag, 2002. 1676 [DSS] "Digital Signature Standard (DSS)", FIPS PUB 186-2 (+ 1677 change notice), National Institute of Standards and 1678 Technology (NIST), Jan. 2000. 1680 [Order-AE]H. Krawczyk, "The order of encryption and authentication 1681 for protecting communications", Proc. Crypto 2001: 21st 1682 Annual International Cryptology Conference, Santa Barbara, 1683 Aug. 2001. 1685 [IAPM] C. Jutla, "Parallelizable Encryption Mode with Almost Free 1686 Message Integrity", NIST proposed mode. 1687 http://csrc.nist.gov/groups/ST/toolkit/BCM/modes_developmen 1688 t.html 1690 [XCBC] V. Gligor, P. Donescu, "Fast Encryption and Authentication: 1691 XCBC Encryption and XECB Authentication Modes", NIST 1692 proposed mode, April 2001. 1693 http://csrc.nist.gov/groups/ST/toolkit/BCM/modes_developmen 1694 t.html 1696 [OCB] P. Rogaway, M. Bellare, J. Black, T. Krovetz, "OCB: A 1697 Block-Cipher Based Mode of Operation for Efficient 1698 Authenticated Encryption", NIST proposed mode, August 2001. 1699 http://csrc.nist.gov/groups/ST/toolkit/BCM/modes_developmen 1700 t.html 1702 [CCM] D. Whiting, R. Housley, N. Ferguson, "AES Encryption & 1703 Authentication using CTR Mode & CBC-MAC", IEEE P802.11 1704 802.11-02/001r0, Jan. 2002. 1706 [MD5-Attack]X. Wang, D. Feng, X. Lai, H. Yu, "Collisions for Hash 1707 Functions MD4, MD5, HAVAL-128 and RIPEMD", Cryptology 1708 ePrint Archive: Report 2004/199, August 2004. 1710 [SHA-1-Attack] X. Wang, Y. Yin, H. Yu, "Finding Collisions in the 1711 Full SHA-1", Advances in Cryptology - Crypto 2005 1712 Proceedings, Lecture Notes in Computer Science, Springer- 1713 Verlag, Aug. 2005. 1715 [Preimages] J. Kelsey, B. Schneier, "Second Preimages on n-bit Hash 1716 Functions for Much Less than 2^n Work", Cryptology ePrint 1717 Archive: Report 2004/304, Nov. 2004. 1719 [HMAC2] M. Bellare, "New Proofs for NMAC and HMAC: Security without 1720 Collision-Resistance", Advances in Cryptology - Crypto 2006 1721 Proceedings, Lecture Notes in Computer Science Vol. 4117, 1722 Springer-Verlag, Sept. 2006. 1724 [Recommendations] "Recommendation for Key Management - Part 1: 1725 General (Revised)", SP 800-57, National Institute of 1726 Standards and Technology (NIST), May 2006. 1728 Author's Addresses 1730 Michael Noisternig 1731 University of Salzburg 1732 Jakob-Haringer-Str. 2 1733 5020 Salzburg 1734 Austria 1736 Email: mnoist@cosy.sbg.ac.at 1738 Bernhard Collini-Nocker 1739 University of Salzburg 1740 Jakob-Haringer-Str. 2 1741 5020 Salzburg 1742 Austria 1744 Email: bnocker@cosy.sbg.ac.at 1746 Intellectual Property Statement 1748 The IETF takes no position regarding the validity or scope of any 1749 Intellectual Property Rights or other rights that might be claimed to 1750 pertain to the implementation or use of the technology described in 1751 this document or the extent to which any license under such rights 1752 might or might not be available; nor does it represent that it has 1753 made any independent effort to identify any such rights. Information 1754 on the procedures with respect to rights in RFC documents can be 1755 found in BCP 78 and BCP 79. 1757 Copies of IPR disclosures made to the IETF Secretariat and any 1758 assurances of licenses to be made available, or the result of an 1759 attempt made to obtain a general license or permission for the use of 1760 such proprietary rights by implementers or users of this 1761 specification can be obtained from the IETF on-line IPR repository at 1762 http://www.ietf.org/ipr. 1764 The IETF invites any interested party to bring to its attention any 1765 copyrights, patents or patent applications, or other proprietary 1766 rights that may cover technology that may be required to implement 1767 this standard. Please address the information to the IETF at 1768 ietf-ipr@ietf.org. 1770 Disclaimer of Validity 1772 This document and the information contained herein are provided on an 1773 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1774 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1775 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1776 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1777 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1778 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1780 Copyright Statement 1782 Copyright (C) The IETF Trust (2008). 1784 This document is subject to the rights, licenses and restrictions 1785 contained in BCP 78, and except as set forth therein, the authors 1786 retain all their rights. 1788 Acknowledgment 1790 Funding for the RFC Editor function is currently provided by the 1791 Internet Society.